Английская версия

Раздумываю над тем, что бы завести английскую версию блога... Причины две:

1. Хочу попрактиковаться в английском.


2. Интересно стать участником интернационального сообщества разработчиков. Интересно познакомиться ближе с их культурой и менталитетом. Можно конечно и без блога вливаться, но с блогом интереснее.

Если бы у этого блога были читатели, то я бы сросил у них, "Что думаете про ихние сообщества и блоги на английском, которые ведут не native-speakers? Может у кого-то уже есть опыт?" Но, судя по статистике, пока сюда заходят только поисковые боты. Сейчас они индексируют этот текст, и им точно не до моих проблем.

Как быстро вставлять часто используемые блоки кода

К примеру, часто при создании ASP.NET контролов я создаю свойство, которое хранит значение во ViewState. Код всегда выглядит примерно одинаково:

   14     public int ShowsCount

   15     {

   16         get

   17         {

   18             return ViewState["ShowsCount"] == null ? 0 : (int) ViewState["ShowsCount"];

   19         }

   20         set

   21         {

   22             ViewState["ShowsCount"] = value;

   23         }

   24     }

и отличается обычно только типом и названием свойства. Полез копаться в Visual Studio Code Snippets, но почему-то в моей "студии" никак не могу найти пункт меню Tools/Code Snippets Manager. Так же оказалось, что ReSharper'овский IntelliSense не поддерживает стандартные Code Snippets, он их просто не показывает в списке. Зато у него имеется собственный аналог - Live Template.

Новый Live Template создается за минуту. Достаточно выделить нужный кусок кода (тот что показан выше) и выбрать пункт меню ReSharper/Code/Live Template from Selection... В диалоге вводим абревиатуру ("propvs"), описание ("public свойство, использующее ViewState"). Потом в поле с кодом, заменяем тип, имя и значение по умолчанию на макросы $type$, $name$, $defaultvalue$ соответственно. Жмем Finish.

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

 

Update: разобрался как показать пункт меню Tools/Code Snippets Manager. Нужно воспользоваться командой Tools/Customize, Rearrange Commands...

Using Settings in C#

Прочитал про "Using Settings in C#". Отметил два важных момента:

• разница между Application и User Scope Settings: Application Scope Settings - это настройки приложения, которые только считываются приложением, но не изменяются ним. User Scope Settings - менее критические настройки пользователя, значения которых приложение может изменять в runtime.
• Описанный механизм поддерживается только для Windows Forms приложений, для ASP.NET надо в ручную редактировать секцию appSettings в web.config файле для добавления application scope settings и использовать ASP.NET Profiles для работы с user scope settings.

Plug-in для вставки исходного кода на форумах и блогах

CopySourceAsHtml - plug-in для Visual Studio 2005. Добавляет в контекстное меню новый пункт "Copy As HTML...". Цвета будут именно те, какие настроены в "студии". Результат выглядит так:

   10         public void RunTest()

   11         {

   12             ServiceConfig config = new ServiceConfig();

   13             config.Transaction = TransactionOption.RequiresNew;

   14             ServiceDomain.Enter(config);

   15 

   16             DoJob();

   17 

   18             if(ContextUtil.IsInTransaction)

   19             {

   20                 ContextUtil.SetAbort();

   21             }

   22 

   23             ServiceDomain.Leave();

   24         }

 

P. S. не учитывает дополнительную посдветку, которую добавляет ReSharper.

Зачем нужен метод Control.ResolveClientUrl?

Часто встречал ошибку в ASP.NET коде, когда путь к какому нибудь файлу (например картинке или JavaScript'у) хардкодом забит в темплейт контрола. Что-то вроде такого:

...

<img src="../images/arrow.gif">

...

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

Проблема легко решается использованием метода ResolveUrl. Но пост не об этом. Пост о новом (ASP.NET 2.0) методе ResolveClientUrl. В чем его отличие от старого метода я уже понял. Но зачем он нужен и в каких случаях надо использовать именно его я не понимаю.

По этому поводу завел тему на форуме GotDotNet.ru, может умные люди подскажут.

Подсчет количества строк кода

Как-то захотелось мне подсчитать количество строк кода в приложении над которым я работаю. Намечается рефакторинг приложения и хотелось бы знать, хотя бы приблизительно, на какие части сколько человек надо. Приложение большое, solution состоит больше чем из 30 проектов (плоды работы целой команды), так что "на глаз" прикинуть тяжело.

Нашел подходящую утилиту на CodeProject. Легко и быстро, даже график показывает :)

Data Access и Business Logic Layer для небольших приложений

Последнее время для разработки Data Access Layer использую provider pattern, а в Business Logic Layer создаю кучу entity-объектов. Все это вроде бы правильно, но для простых data-driven приложений такой подход за частую превращается в пустую трату времени, потому что эти навороты остаются не востребованными и только увеличивают количество строк кода (и, потенциально, количество ошибок).

Две статьи Creating a Data Access Layer и Creating a Business Logic Layer как раз россказывают о простейшем способе реализации этих layer'ов с использованием типизированного DataSet. В этом случае практически весь data access код будет сгенерирован мастерами. А благодаря тому что все сгенерированные классы имеют модификатор "partial", в них можно добавлять дополнительные business свойства и методы. Вместо entity-объектов я использую сгенерированные xxxRow классы.

Таким образом весь "каркас" генерится автоматически и мне только надо расширить его логикой приложения. Получается быстренько и расширяемо. Еще не пробовал, но мне кажется что потом, если нужно будет, то совсем не тяжело перейти, например, на provider-model.

 

P.S. конечно, объектная модель не выглядит такой элегантной как в случае если эти layer'ы разрабатываются в ручную, но для многих задач это и не надо.