пятница, 28 января 2011 г.

Dependency Injection в SharePoint

Сегодня потребовалось внедрить в проект по SharePoint управление зависимостями.
В качестве инструмента IoC был выбран Ninject.
Внедрение зависимостей в SharePoint дело не простое. Там нет удобной так называемой единой точки входа, которую мы имеем в любом другом решение, которое пишем с нуля (например, ASP.NET-проект, где в нашем распоряжении есть файл global.asax). Кое-какие идеи по внедрению конечно были, но чтобы не изобретать велосипед, решил вначале в интернете посмотреть как люди решают подобную проблему.
Практически сразу наткнулся на статью. Почитал её. На мой взгляд, там нет ничего криминального для SharePoint. Да и к тому же увидел, что человек применил некоторые из моих идей, которые я хотел попробовать. Спасибо ему, что сэкономил моё время.
Попробую на продакшине. Должно работать как часы.
А вы что думаете?

четверг, 27 января 2011 г.

Установка Timeout в сгенерированных DataSet

Добрый день!
В одном из рабочих проектов используем сгенерированные DataSet через XSD-схему, на которую переносятся хранимые процедуры из БД. Как говорится, программа работала отлично до поры до времени. Объем данных вырос и отчеты, использующие эти хранимые процедуры, стали долго строиться (используем ReportViewer) и в конечном итоге вылетать по тайм-ауту. Ясно дело, что надо устанавливать Timeout у SqlConnection. Но лесть в сгенерированный код не хочется, но и не нужно.
Натолкнулся на статью с примером функции расширения:
public static void TableAdapterCommandTimeout(this T TableAdapter, 
        int CommandTimeout) where T : global::System.ComponentModel.Component
{                
    foreach (var c in typeof(T).GetProperty("CommandCollection", System.Reflection.BindingFlags.NonPublic | 
                         System.Reflection.BindingFlags.GetProperty | 
                         System.Reflection.BindingFlags.Instance).GetValue(TableAdapter, null) as 
                         System.Data.SqlClient.SqlCommand[])
        c.CommandTimeout = CommandTimeout;

}
Теперь можно её использовать, например так:
this.FooTableAdapter.TableAdapterCommandTimeout(60);
Медленно конечно будет работать, т.к. через рефлексию сделано, но нам быстро и не надо, т.к. отчеты относительно редко используемые. Да и рефлексия в сравнении со временем, которое нужно для построения отчетов, занимает не так уж много времени.

вторник, 25 января 2011 г.

Явное и неявное преобразование в строку

Тут что-то подумалось. Почему люди так любят вызывать метод ToString() в случаях подобном этому:
int x = 10; 
string str = "Значение = " + x.ToString();
Лично я предпочитаю следующую запись:
string str = "Значение = " + x;
Это удобно для меня во многих случаях. Самый яркий пример: есть коллекция и я пытаюсь получить оттуда значение:
IList<string, int> list = new List<string, int>();
list.Add("key", 10);
string str = "Значение = " + list["key2"]; //Напишет "Значение = "
Если попробовать применить ф-ю list["key2"].ToString(), то получим исключение. Чтобы не было исключений, надо проверять возвращаемое значение из коллекции.
Лично мне кажется это неудобным и поэтому я использую комбинацию:
  • list["key2"] + ""
  • Последующая проверка на string.IsNullOrEmpty(), если нужно.
А вы что думаете?

понедельник, 3 января 2011 г.

Протоколирование. Часть 1.

Всех с наступившим 2011 годом!!! Начнем цикл статей... 

Введение
Этот цикл статей родился не просто так. Тема протоколирования широкая (это демонстрирует объем прочитанных статей в интернете, на основе которых вкупе со своим опытом и создан этот материал), и каждый программист решает, как ему удобно отлаживать свои программы. Т.о. количество средств протоколирования растет очень быстро, т.к. постоянно изобретаются велосипеды. Вред подобного «велосипедостроительства» рано или поздно становится понятен каждому разработчику. К сожалению, я не стал исключением, реализовав свою систему протоколирования в нескольких проектах. Цель этого цикла статей – дать разработчику информацию о существующих системах протоколирования. И пусть каждый разработчик сам выбирает готовый инструмент в зависимости от своих потребностей. Если появятся интересы, то можно будет провести тестирования средств и понять, какое из них нам все же по душе.

Так же стоит понимать, что ни одно из средств не может быть панацеей от всех бед. Т.е. скорее всего, для каждого отдельно взятого случая подойдет та или иная система протоколирования.

Еще статьи

2leep.com