Сначала опишу задачу, которую мы решали в нашем проекте. У нас есть 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."

Следующий код выводит на экран список избранных ссылок в консоль. Код достаточно прост. Привожу здесь, чтобы иногда ссылаться с форумов, бывает всплывают подобные вопросы.

const string urlConst = "URL=";

// Путь до папки "избранное"

string pathFavorites = Environment.GetFolderPath(Environment.SpecialFolder.Favorites);

// Получаем список всех файлов, включая файлы в подпапках

foreach (String favorite in Directory.GetFiles(pathFavorites, "*", SearchOption.AllDirectories)) 

{

    using(StreamReader file = new StreamReader(favorite))

    {

        while (!file.EndOfStream)

        {

            string line = file.ReadLine();

            if (line.StartsWith(urlConst))

            {

                string url = line.Substring(urlConst.Length);

                string name = Path.GetFileNameWithoutExtension(favorite);

                Console.WriteLine("NAME='{0}', URL = '{1}'", name, url);

                break;

            }

        }

    }

}

Console.ReadKey();

Предположим у нас есть задание: написать систему логирования, которая в реальном времени отсылает логи слушателям, причем информация может быть конфиденциальная и нужно избежать возможности кражи информации.

В продолжение темы про NHibernate: xorets сделал мне дельное замечание по поводу того, что неуместно наследоваться от класса Configuration без необходимости: а сделал я это не просто так, а потому что была у нас задача создавать маппинг наших объектов в NHibernate при помощи наших собственных методанных, а так как некоторые необходимые методы были protected в классе Configuration мне и пришлось от него унаследоваться (пример, кстати, я взял откуда то). Хотел вам рассказать как реализовать автоматический маппинг, но вспомнил про FluentnHibernate и остановился. Это в нашем случае он не подходил, так как у нас были свои метаданные, а в обычном случае метаданными могут являться сами типы объектов и при помощи reflection можно получить достаточную информацию, чтобы замапить тип на таблицу, такое и предоставляет FluentnHibernate - Auto mapping. Вообще, если вы все же столкнетесь с такой задачей, как автоматический маппинг из своих методанных – то рекомендую не терять время на разбор кода NHibernate, а делать следующее – создавать по методанным обычные xml маппинги NHibernate и их уже подсовывать конфигурации (Так собственно и работают Fluent и ActiveRecord, если я ничего не путаю). Синтаксис xml маппинга и все подводные камни уже хорошо везде описаны, потому я и считаю это лучшим способом.