Пару недель назад мне в руки попала бумажная копия книги Pablo Cibraro, Kurt Claeys, Fabio Cozzolino, Johann Grabner - Professional WCF 4: Windows Communication Foundation with .NET 4. По объему данная книга получилась не очень большая – около 400 страниц, честно говоря, уже забыл, когда видел такие “тоненькие” книжки по технологиям. Книга по объему не большая, но охвачено там достаточно интересных тем.

Первая глава – это паттерны и принципы создания SOA-приложений. Это, конечно же, лучшая глава в данной книге, видно, что у авторов есть опыт создания приложений типа Service-oriented architecture. Авторы описали всевозможные архитектурные принципы, по которым можно создать SOA-приложения. Причем они не опирались только на WCF, а постарались описать все принципе вообще, которые можно реализовать при помощи WCF, и для которых WCF не совсем предназначен. В общем, эта глава must read для всех, независимо от того, какие технологии вы используете. И по счастливому случаю wrox предоставил данную главу для ознакомления с книгой в свободном доступе на своем сайте Design Principles and Patterns. Всего 30 страничек, не поленитесь прочитать.

Вопрос, какую директорию создаст этот код?

string sole = DateTime.Today.ToString("yyyy/MM/dd");

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, sole);

if (!Directory.Exists(path))

    Directory.CreateDirectory(path);

Для логгирования приложений, написанных под .NET большинство разработчиков используют log4net (а другие разработчики используют log4 под другие платформы). Но так, к сожалению, бывает не везде. Так, например, в нашем проекте до сегодняшнего дня мы использовали свою самописную библиотеку для логгирования. Была она, видимо, написана давно нашим team leader, но так как нас сейчас покидает текущий team leader, мы решили так же распрощаться с некоторым legacy кодом, который был дорог нашему лидеру, но который не особо то мы хотим поддерживать. Сразу уточню, что код написан отлично, и наш team leader – отличный кодер, но log4net имеет больше преимуществ, а текущий логгер нам приходится частенько дописывать функционалом, который уже давно есть в log4net.

Сначала опишу задачу, которую мы решали в нашем проекте. У нас есть Silverlight клиентская часть и серверная часть, состоящая из набора WCF сервисов. Причем задумка у нас такая, что изначально мы разрабатываем эти сервисы с возможностью хостинга их вне веб-сервера, потому ASP.NET Compatible mode у нас отключен (зачем я так и не понял, ведь реально инсталлируем всегда на веб-сервер, ну усложнили себе жизнь - пускай). Следовательно, до значения HttpContext.Current нам никак не добраться из методов WCF сервисов. Один из WCF сервисов – это RESTful сервис, который отдает файлы (отчеты), то есть умеет обрабатывать GET запросы, все по стандартному...

Стал я счастливым обладателем такой вот замечательной книжки C# IN A NUTSHELL 4th edition. Это уже четвертая редакция этой книги. На руках я видел когда-то третью редакцию, которую мы подарили на одном из мероприятий в ЯрГУ, и книжка 3-й редакции была на русском, а все русские книги печатают на (как бы по мягче выразиться) не очень качественной бумаге. В общем, признаюсь честно книгу до конца пока не дочитал, но уже на данном этапе у меня огромное удивление. Почему? Почему так много говорят о книге Рихтера - CLR via C# (англоязычная версия 3-й редакции у меня так же на полке ждет моего внимания), но так мало о книге C# IN A NUTSHELL, по крайней мере, это так в моем кругу. Про нее я слышал только один отзыв в одном из Подкастов Петербургской Группы Alt.Net, да и то как всегда в разрезе Рихтер - это круто, а C# IN A NUTSHELL - это хороший справочник. Мое мнение - Рихтер нужен для того, чтобы научиться разрабатывать на .NET. А вот чтобы научится программировать на C# то это вам к C# IN A NUTSHELL.

Экспорт табличной части в Excel из приложения достаточно распространенная задача, и решать ее можно по разному. Конечно решение зависит от того, что за приложение вы разрабатываете. Если это приложение разрабатываемое для автоматизации бизнес процессов, и оно предназначено для установки в несколько контор, то скорее всего вы можете диктовать условия (рекомендации по использованию), необходимые для вашего приложения. Либо заказчик выставит требования, под которые вы будете его разрабатывать. В этом случае, экспорт проще всего реализовывать через COM, используя инфраструктуру Excel (либо OpenOffice), тогда и реализовать данную задачу при помощи данного подхода будет просто, и это даст вам наибольшую гибкость и возможность использовать всю мощь таблиц Excel. Об этом вариант и пойдет разговор ниже. Другой вариант – ваше приложение предназначено для домашних пользователей, в этом случае диктовать обязательную установку MS Office или OpenOffice не очень хорошо, потому лучше не завязываться на них, а использовать либо сторонние компоненты для создания документов, либо экспортировать в xml/html формат, который понимает MS Office (так делает, например, JIRA). Правда в этом случае будет тяжело удовлетворить просьбы клиентов, вроде: сделать так, чтобы экспортируемый документ был подготовлен для печати в альбомном виде с необходимыми полями, хотя может быть и возможно.

В добавление к записи Дмитрия Нестерука - Паттерны методов расширения хотел бы добавить еще один метод расширение “Приведение типов”, без которого мне уже сложно обходиться. Автор идеи этого подхода работает сейчас в фирме, где я работал раньше.

Нам часто приходится писать, примерно, такой код:

int intValue;

if (obj == null || !int.TryParse(obj.ToString(), out intValue))

    intValue = 0;

Это способ безопасного приведения к типу int. Напрашивается сразу же какой либо унифицированный метод для безопасного приведения типов.

Мне нравится подход вынесения преобразования в extension method и использовать его затем следующим образом:

int i;

i = "1".To<int>();

// i == 1

i = "1a".To<int>();

// i == 0 (default value of int)

i = "1a".To(10);

// i == 10 (set as default value 10)

i = "1".To(10);

// i == 1

// ********** Nullable sample **************

int? j;

j = "1".To<int?>();

// j == 1

j = "1a".To<int?>();

// j == null

j = "1a".To<int?>(10);

// j == 10

j = "1".To<int?>(10);

// j == 1

Признаюсь, я фанат регулярных выражений. Всегда, когда я вижу задачу, которую можно решить при помощи RegEx, я загораюсь и бегу писать тест под новенькое Regex условие. Раньше даже специально держал установленный SharpDeveloper, так как там была удобная тулза для проверки RegEx выражений, сейчас же я немного поумнел и для каждого RegEx пишу просто отдельный тест и в нем же и тестирую. Вообще, нужно стараться находить те задачи, которые предназначены для решения их через регулярные выражения. Мне сложно помнить синтаксис регулярных выражений, точнее приходится их писать не так уж и часто, потому из головы постоянно вылетает: какой символ отвечает за начало строки и т.п. Для освежения я постоянно пользуюсь очень легкой статьей Регулярные выражения на RSDN.

На сайте http://techdays.ru опубликовали мой доклад на тему Prism: Composite Application Guidance for WPF and Silverlight

Когда подключаетесь по HTTPS (SSL) к веб-ресурсу – можно получить такую ошибку:

"The underlying connection was closed: Could not establish trust relationship with remote server."