handcode

Hello world для ATmega328 + avr-gcc + avrdude (USBasp)

noreply@blogger.com (Илья Дубаденко) — Sun, 18 Jan 2015 21:07:00 +0000

Хочу поделиться своим опытом знакомства с микроконтроллером ATmega328. Но сначала небольшое отступление.

Наверное уже все читали или уж точно слышали про Arduino. На мой взгляд, Arduino хорошая платформа для ознакомления с миром микроконтроллеров. Низкий порог вхождения и богатый набор различных библиотек, несомненно, является ключевым достоинством этой платформы. Под словом платформа я понимаю само устройство и штатная IDE с набором библиотек. Но к сожалению, ради обеспечения низкого порога вхождения штатная IDE вынуждена многое делать неявно для программиста. Например, процесс компиляции и прошивки, или даже формирование конечного main-файла с подключением всех include. Именно эти неявные действия и создают пробелы в знаниях при изучении платформы.

Итак, наши цели:

Написать программку на чистом C, которая будет мигать светодиодом (aka "Hello world!" только для МК)
Собрать прошивку для МК
Настроить fuses bits нашего МК
Прошить МК

Естественно все действия постараемся проделать из-под консоли.

Начнем с железной части.

МК ATmega328 (тот самый, что используется и в Arduino)
Кварц на 16Mhz и два конденсатора на 22пФ
Светодиод
Резисторы 1кОм и 10кОм
Программатор USBasp (как устройство)
Источник питания на 5В.

Все это необходимо будет подключить по схеме:

Подготовка программной среды.

Компилятор avr-gcc
Программатор avrdude (как софт)

Для ОС Windows все придется скачать и установить самому руками.
Для ОС Ubuntu процесс намного проще:

sudo apt-get install gcc-avr avr-libc binutils-avr
sudo apt-get install avrdude

Весь наш код будет состоять из одного main.c файла:
Теперь необходимо собрать нашу программу:

avr-gcc -Wall -Os -mmcu=atmega328p main.c -o main.o

После чего необходимо подготовить HEX-образ для загрузки его в МК:

avr-objcopy -j .text -j .data -O ihex main.o main.hex

Перед тем как загрузить HEX-образ, МК необходимо настроить, делается это выставлением fuse bits. Установка fuse bits одна из самых ответственных частей. Собственно при неправильных настройках можно случайно заблокировать свой МК, так что будьте особо внимательны! К счастью, выставление fuse bits редкая операция, и требуется обычно лишь один раз.
Для подбора значений fuse bits я воспользовался калькулятором. Для нашего случая команда конфигурации выглядит так (16Мгц должно хватить, чтобы помигать светодиодом :)):

avrdude -c usbasp -p atmega328p -U lfuse:w:0xff:m -U hfuse:w:0xda:m -U efuse:w:0x05:m

Собственно загрузка HEX-образа в МК:

avrdude -p atmega328p -c usbasp -U flash:w:main.hex:i

Если все шаги были пройдены успешно, то после включения МК мы увидим мигающий светодиод.

PS: Код проекта выложил на github, в который включил makefile для удобства сборки и прошивки.
Советую обратить внимание на команду:

avr-objdump -h -S main.o > main.lss

Инфраструктурный код

noreply@blogger.com (Илья Дубаденко) — Tue, 23 Oct 2012 20:14:00 +0000

Не секрет, что в процессе разработки многие программисты стараются разделять свой код на две категории: бизнес код и инфраструктурный код. Из названий категорий очевидно следует, что бизнес код должен решать задачи поставленные Вам от бизнеса, и именно этот код приносит потребительскую ценность Вашего ПО как продукта. И инфраструктурный, берущий на себя технические детали реализации не относящиеся к бизнесу, и позволяя Вам в большей степени сосредоточиться на бизнес цели.

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

Чтобы лучше понять, что я имел в виду приведу простой пример из практики.

Пример:
Имеется система обмена сообщениями стандарта JMS и пусть каждое сообщение имеет тело сообщения (body), тип (type), имя очереди для ответа (replyTo) и имя отправителя (application name). Разработчику предлагается предложить техническую реализацию структуры сообщения.

Неправильный путь начинается с того, что разработчик придумывает свой envelop, со своим header и body секциями для хранения соответствующих полей сообщения. Продолжается написанием сложных алгоритмов анализа своего envelop'а, фактически изобретая инфраструктуру над инфраструктурой. И заканчивается все legacy кодом.

Правильным решением здесь будет воспользоваться уже готовой инфраструктурой: поля type и replyTo положить в стандартные jmsType и jmsReplyTo соответственно. С appName немного сложнее, так как для него нет стандартного jms заголовка, поэтому appName следует поместить в свойство сообщения, опять же стандартное средство инфраструктуры. С body все понятно, тут сложно промахнуться.

Аналогичный пример можно привести и для SOAP сообщений. На самом деле примеров игнорирования возможностей инфраструктуры море.

Итак, если у Вас имеется некая инфраструктура, изучите ее возможности. Большинство "велосипедов" получается из-за незнания возможностей инфраструктуры. Если так получается, что возможностей инфраструктуры недостаточно для решения конкретной задачи, то у Вас есть несколько путей решения этой проблемы:

Выбрать другую инфраструктуру. Это довольно радикальное решение, но все же.
Найти готовый framework под текущую инфраструктуру, реализующий недостающую функциональность (например NServiceBus позволяет реализовать функционал выполнения долгих бизнес процессов (известных как SAGA) в инфраструктуре MSMQ, в которой понятие SAGA отсутствует)
Реализовать самому.

Семантическое версионирование в DVCS Mercurial

noreply@blogger.com (Илья Дубаденко) — Wed, 28 Mar 2012 07:06:00 +0000

Эта статья о том, как я наладил семантическое версионирование (semantic versioning) в своем проекте на базе DVCS Mercurial (можно читать как Git). На хабре есть отличный перевод про Семантическое управление версиями, советую начать с него.

В качестве хранилища кода, я выбрал mercurial. Помимо функции хранилища кода, mercurial будет выступать еще и как провайдер версий, это означает, что запрашивать текущую семантическую версию (Major.Minor.Patch) мы будем именно у него.

Итак, рассмотрим пару Major.Minor. Обычно эта пара всегда задается вручную в момент релиза, и самый простой способ это сделать - пометить руками нужный сhangeset тегом, содержащим версию релиза (например: 1.4, или v1.4, но не 1.4.3, так как path мы договоримся вычислять).

С Patch все намного сложнее. Наша цель, добиться чтобы при каждой фиксации(commit) изменений кодовой базы автоматически бы инкрементировался path-номер. Это примерно означало бы, что path будет равен числу фиксаций в текущем релизе (например: 1.4.17 - 17-ая фиксация в релизе 1.4, но в то же время 1.5.0 уже новый релиз, с новой path-нумерацией). Но здесь не стоит забывать один факт: мы ведь работаем с DVCS и у нас нет единого "брокера" path-номеров...

В интернете я нашел несколько вариантов решения этой задачи (SO, RSDN), где в основном предлагалось использовать число, полученное как {latesttagdistance}, но можно заметить, что {latesttagdistance} перестает работать в общем случае, когда тег может содержать произвольный текст. Но эта идея мне очень понравилась, и я начал искать универсальное решение. И вскоре решение было найдено.

Я предлагаю в качестве path-номера брать разницу между номером ревизии текущего changeset-а (замечу, что это не всегда tip) и номером ревизии changeset-а, имеющего тэг с релизной версией и являющегося ближайшим предком по отношению к текущему changeset-у.

На текущий момент, при таком подходе мне удалось достичь желаемого семантического версионирования своих проектов.

Теперь осталось все это как-то оформить. В конечном же счете, я преследовал цель автоматической генерации файла AssemblyInfo.cs на основе номера версии полученной от mercurial до начала сборки проекта, и с последующей сборкой. Очевидным решением здесь было сделать Custom MSBuild Task/Target, и в итоге появился проект Devme.MSBuildTasks.

Коротко о Devme.MSBuildTasks (текущая версия 0.3.0)

Q: Какие системы контроля версий поддерживает библиотека?

A: Пока только для mercurial.

Q: Как я могу начать использовать это в своем проекте?

A: Необходимо выполнить 3 простых шага:

Шаг 1. Используя Nuget, установить/скачать библиотеку к себе в проект.

Шаг 2. Создать в каталоге Properties (если использовали nuget, то файл шаблон будет создан автоматически) файл шаблон следующего содержания (за основу можно взять Ваш текущий файл AssemblyInfo.cs):

using System.Reflection;
 
[assembly: AssemblyTitle("todo")]
[assembly: AssemblyDescription("todo")]
[assembly: AssemblyCompany("todo")]
[assembly: AssemblyProduct("todo")]
[assembly: AssemblyCopyright("Copyright © todo")]
 
[assembly: AssemblyVersion("${major}.${minor}.${path}")]
[assembly: AssemblyFileVersion("${major}.${minor}.${path}")]
[assembly: AssemblyInformationalVersionAttribute("${major}.${minor}.${path}-${branch} ${hash|short}")]

Формат шаблона думаю Вам понятен, здесь в качестве ${some} будут подставлены соответствующие значения взятые из mercurial (см wiki). У себя я называю этот файл AssemblyInfo.cs.template.

Шаг 3. Открыть в блокноте файл проекта (*.csproj) и добавить в самом конце пару тэгов (или расширить существующую цель BeforeBuild), указав правильный путь к Devme.MSBuildTasks.dll:

<UsingTask 
    TaskName="SemanticVersioningTask" 
    AssemblyFile="ПУТЬ К ФАЙЛУ Devme.MSBuildTasks.dll" />
<Target Name="BeforeBuild">
    <semanticversioningtask 
        TemplateFilePath="Properties/AssemblyInfo.cs.template" 
        OutputFilePath="Properties/AssemblyInfo.cs" />
</Target>

Все готово!

Заключение

Следует помнить, что каждый раз, во время сборки проекта, файл AssemblyInfo.cs будет генерироваться автоматически, поэтому его можно(надо) исключить из кодовой базы добавив в .hgignore.
Так же не рекомендуется вносить в файл AssemblyInfo.cs любые изменения. Все изменения надо делать в шаблоне AssemblyInfo.cs.template.
Исходники
Wiki

Ссылки:

Всем приятного использования!

Stopwatch. Новые идеи.

noreply@blogger.com (Илья Дубаденко) — Tue, 13 Mar 2012 08:36:00 +0000

Как-то давно я написал статью "Пишем обертку для Stopwatch", в которой рассказал как удобно было бы использовать стандартный класс Stopwatch из System.Diagnostics, сделав для него IDisposable обертку. И вот наконец, у меня появились новые идеи и свободное время и я решил вернуться к этой теме и немного ее доработать.

1. API. Я решил сделать единую точку входа - статический класс StopwatchManager со статическим методом Start. Все очень просто и понятно:

using (StopwatchManager.Start(elapsed => Console.WriteLine("Elapsed: {0}", elapsed)))
{
Thread.Sleep(2345);
}

2. Регионы (new!). Как часто Вам требовалось узнать не только текущее время выполнения блока, а например, еще и общее или суммарное время выполнения, либо узнать сколько раз блок выполнился, либо узнать минимальное, максимальное или среднее время выполнения? Теперь это стало проще благодаря именованным регионам:

using (StopwatchManager.Start("region", elapsed => 
Console.WriteLine("Third. " +
"Elapsed: {0}, " +
"Total: {1}, " +
"Count: {2}, " +
"Min: {3}, " +
"Max: {4}, " +
"Avg: {5}",
elapsed.Current,
elapsed.Total,
elapsed.Count,
elapsed.Min,
elapsed.Max,
elapsed.Avg
)))
{
Thread.Sleep(500);
}

Здесь “region” это идентификатор региона, задав его мы указываем, что хотим собирать статистику для помеченного блока кода. В статистику входят: Current – текущее, Avg - среднее, Min – минимальное, Max – максимальное, Total – общее время выполнения, Count – количество прогонов.

3. NuGet package (new!). Для удобства использования, я собрал все это в NuGet пакет, который можно скачать здесь, или через консоль:

PM> Install-Package Devme.Diagnostics

Исходники
Wiki

Всем приятного использования!

Adapter pattern. Понимание важности.

noreply@blogger.com (Илья Дубаденко) — Tue, 22 Nov 2011 21:05:00 +0000

Перед большинством проектов рано или поздно встает главный вопрос: "Использовать стороннюю компоненту или реализовать свою?", и как это часто бывает, по причине того что использовать уже существующее гораздо проще, чем создавать это заново мы выбираем уже готовое решение.

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

Итак, пришло время вспомнить о существовании такого шаблона проектирования как "Адаптер" (Adapter pattern). Я не буду здесь рассказывать про этот шаблон проектирования, а просто постараюсь выделить главную идею:

Всегда оборачивайте стороннюю компоненту своим интерфейсом и адаптируйте ее под себя.

Первая причина, почему это стоит делать очевидна - это устранение жестких зависимостей на стороннюю компоненту, а учитывая, что у зависимостей есть один неприятный момент: с ростом проекта они тоже разрастаются и чем дальше тем сложнее от них избавиться, и в конце концов можно стать "заложником" сторонней компоненты. Казалось бы простое правило, но на практике периодически сталкиваешься с обратным, да и сам порой забываешь обернуть, например, какой-нибудь logger, serializer(json, xml, yaml) или DI/IoC-контейнер, в надежде, что этот инструмент ты не сменишь никогда в проекте.

Вторая причина - это адаптация компоненты "под себя". Адаптируете компоненту таким образом, чтобы Вам было удобно ее использовать.

Один из примеров из личного опыта.
Не так давно, я занимался проектированием и реализацией сервиса получения финансовой информации в режиме реального времени с фондовых бирж (РТС и ММВБ). В качестве протокола взаимодействия с серверами бирж использовался стандартный (Financial Information eXchange или FIX/FAST).

Изучив спецификацию протокола FIX (и его оптимизацию FAST), было принято решение не писать свой парсер сообщений, а использовать уже готовую библиотеку, реализующую FIX/FAST в полной мере. На рынке (да и в opensource) тогда было несколько предложений", но вот времени чтобы изучить и выбрать подходящую библиотеку (быстродействие/поддержка/удобство использования) у меня тогда не было (выпуск первого рабочего прототипа поджимал все сроки). Тогда я выбрал одну из библиотек; выделил общие требования к библиотеке в виде нескольких интерфейсов: IFixMessage, IFixGroup, IFixSession, IFixEngine, IFixMessageReader, IFixMessageWriter, IFixMessageBuilder; реализовал адаптер. Важно отметить тот факт, что на практике в 80% случаев Вам потребуется лишь 20% функционала, который предлагает сама библиотека, и в этом случае Ваши интерфейсы получаются легкими (ничего "лишнего").

Когда прототип был готов и запущен в тестовом режиме, оказалось, что библиотека не удовлетворяет нас по критерию быстродействия. Естественно было принято решение отказаться от данной библиотеки и выбирать другую, для которой мне вновь пришлось написать обертку. Да, я потратил время на написание новой обертки, но зато я сэкономил значительно больше времени не переписывая весь сервис под новое API новой библиотеки, тем более, что остальная часть сервиса была отлажена и работала.

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

Mock для ICloneable типов

noreply@blogger.com (Илья Дубаденко) — Wed, 31 Aug 2011 16:11:00 +0000

Буквально недавно я столкнулся с задачей, суть которой заключалась в том, чтобы создать mock объект реализующий интерфейс ICloneable, например средствами Moq.
В моей ситуации, было все просто: метод Clone должен возвращать объект (которого на самом деле нет), с наперед известными данными (которые не подлежали бы изменениям). Для наглядности лучше привести исходный код.
Пусть это будет следующий интерфейс:

public interface ISome : ICloneable

{

// некое бизнес-поле

int Value { get; }

}

И для этого интерфейса, построим mock объект реализующий его.
Итак, тесты вперед, поэтому напишем простой unit-test для метода Clone:

[TestMethod]

public void CloneTest()

{

var original = MakeMockCloneableSome();

// покажем, что и у клонированого объекта

// метод Clone работает как надо

var clone = (ISome)((ISome)((ISome)original.Clone()).Clone()).Clone();

// проверим, что бизнес поле совпадает

Assert.AreEqual(original.Value, clone.Value);

// проверим, что это 2 отдельных объекта

Assert.IsFalse(Object.ReferenceEquals(original, clone));

}

В тесте я трижды вызывают метод Clone для того, чтобы продемонстрировать, что и у клонированного объекта метод Clone тоже работает, это важно.
Осталось реализовать метод MakeMockCloneableSome():

ISome MakeMockCloneableSome()

{

var mock = new Mock<ISome>();

// Здесь привычный нам mock бизнес логики...

mock

.Setup(c => c.Value)

.Returns(123);

// Искомый mock метода ICloneable.Clone()

mock

.Setup(c => c.Clone())

.Returns(MakeMockCloneableSome);

return mock.Object;

}

Проверяем входные данные

noreply@blogger.com (Илья Дубаденко) — Thu, 12 May 2011 14:13:00 +0000

Все программисты знают, что пришедшие из внешнего источника данные всегда надо проверять. Например в качестве входного параметра для метода (свойства, конструктора), может приходить ссылка, которую нужно проверить на null, число, которое должно быть из определенного диапазона, или определенного вида строка. Несмотря на то, что по этому поводу даже существует методика разработки через Code Contracts, по-прежнему, с высокой вероятностью в проекте можно встретить код проверки на null аналогичный следующему:

class Bar {}

class Foo

{

Bar _bar;

public Foo(Bar bar)

{

// bar может быть null

if (bar == null)

throw new ArgumentNullException("bar");

_bar = bar;

}

С ростом проекта, подобных мест становиться все больше, и контроллировать создание исключений стоновиться сложнее. Одно из решений проблемы (для тех, кто пока еще не перешел на Code Contracts), сделать процесс создания исключений более централизованным, а именно в определенном классе - Guard (я остановился на названии Guard, но встречаются еще Assert, Check (проект KIGG CheckArgument.cs)):

public static class Guard

{

public static T AssertNotNull<T>(T paramValue, string paramName) where T : class

{

if (paramValue == null)

{

throw new ArgumentNullException(paramName);

}

return paramValue;

}

Принцип работы Guard следующий: если входной параметр удовлетворяет некому условию, то Guard пропускает параметр дальше, если нет, то будет сгенерированно исключение:

class Foo

{

Bar _bar;

public Foo(Bar bar)

{

// bar может быть null

_bar = Guard.AssertNotNull(bar, "bar");

}

Итак, за проверку входных параметров у нас отвечает Guard, поэтому вся логика проверки (в том числе более и сложная) не будет присутствовать в основном классе, а будет вынесена в Guard, что сохраняет компактность кода.
Во-вторых, мы получили удобный механизм контроля создания исключения, например мы легко сможем добавлять свои типы исключений или менять текст исключений и прочее.
И в-третьих, можно сделать так, чтобы Guard сам отдельно сообщал об исключениях (нарушение контракта):

public static class Guard

{

public static T AssertNotNull<T>(T paramValue, string paramName) where T : class

{

if (paramValue == null)

{

ArgumentNullException ex = new ArgumentNullException(paramName);

OnAlert(ex); // сообщим об исключении, например сделаем запись во внутренний лог.

throw ex;

}

return paramValue;

}

Так же иногда бывает удобно пометить Assert методы специальным атрибутом:

[DebuggerStepThrough]

public static T AssertNotNull<T>(T paramValue, string paramName) where T : class

{

//...

}

PS: Топик навеян статьей habrahabr: Концепция баррикады.

AOP средствами Unity 2.0

noreply@blogger.com (Илья Дубаденко) — Thu, 14 Apr 2011 08:34:00 +0000

В этой статье рассмотрим простой пример реализации AOP (Aspect-Oriented Programming) средствами Unity 2.0. Итак, Unity представляет собой DI/IoC контейнер, с возможностью вносить в него новую функциональность или поведение через стандартные или пользовательские расширения (Extentions).Благодаря этой возможности Unity, мы можем написать свое или воспользоваться уже готовым расширением и реализовать AOP в нашем .NET приложении. Стандартный подход при реализации AOP средствами Unity является использование перехватчика (Microsoft.Practices.Unity.Interception) вызова.
Unity 2.0 предоставляет нам три вида перехвата:

InterfaceInterceptor для перехвата методов интерфейса
VirtualMethodInterceptor для перехвата виртуальных методов
TransparentProxyInterceptor для перехвата методов у объектов типа MarshalByRefObject

Принцип работы перехватчика очень простой. Когда мы делаем resolve-запрос к Unity контейнеру мы получаем динамически сгенерированный прокси-объект, делегирующий искомый тип. Функционально прокси устроен следующим образом: ПЕРЕД тем и ПОСЛЕ того, как прокси передаст вызов на искомый объект, он выполнит код перехватчика (на практике обычно это pipe из нескольких обработчиков, реализующих интерфейс ICallHandler), передав ему все необходимые параметры вызова. Этого вполне достаточно для реализации AOP поведения.

Для простоты продемонстрирую это на примере: предположим нам необходимо реализовать транзакционный метод (метод помеченный атрибутом [TransactionMethod] будет автоматически выполняться в транзакции, см атрибут [Transaction] в Spring.NET).
Рассмотрим интерфейс и его имплементацию. В интерфейсе у нас имеется метод, декларативно(!) помеченный как транзакционный. Имплементация по сути не важна.

public interface IAccountService

{

// Хотим чтобы метод Withdraw выполнялся под транзакцией,

// поэтому пометим его специальным атрибутом.

[TransactionMethod()]

void Withdraw(decimal amount);

}

public class AccountService : IAccountService

{

public void Withdraw(decimal amount)

{

if (amount < 0 || amount > 1000)

throw new ArgumentOutOfRangeException("amount");

}

Собственно атрибут. Видно, что он наследуется от HandlerAttribute, именно атрибуты такого типа по-умолчанию и обрабатываются перехватчиком.

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]

public class TransactionMethodAttribute : HandlerAttribute

{

public override ICallHandler CreateHandler(IUnityContainer container)

{

// Перехватчик для каждого атрибута HandlerAttribute,

// вызывает метод CreateHandler, который возвращает

// конкретный обработчик ICallHandler.

return new TransactionMethodCallHandler();

}

Вся логика сосредоточена в обработчике вызова ICallHandler.Invoke:

public class TransactionMethodCallHandler : ICallHandler

{

// Главный метод обработчика ICallHandler.

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)

{

IMethodReturn result;

// открываем транзакцию

using (TransactionScope transaction = new TransactionScope())

{

result = getNext()(input, getNext);

if (result.Exception == null)

{

// исключений не возникло, завершим транзакцию

transaction.Complete();

}

return result;

}

public int Order { get; set; }

}

Продемонстрируем наш пример:

static void Main(string[] args)

{

IUnityContainer container = new UnityContainer();

// Настроим контейнер.

UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

section.Configure(container);

// Запросим у контейнера IAccountService.

IAccountService service = container.Resolve<IAccountService>();

// Полученный service - прокси-класс делегирующий AccountService.

// Если мы попробуем узнать тип объекта service, то мы получим нечто вида:

// DynamicModule.ns.Wrapped_IAccountService_af75f3474a9d4de2b1fe6aa1d26a8e36

service.Withdraw(33); // транзакция пройдет успешно

service.Withdraw(-6); // транзакция откатится

}

Чтобы все это заработало, осталось настроить Unity контейнер через config файл. Укажем правило разрешения типа (mapping) и тип перехвата InterfaceInterceptor:

<?xml version="1.0" encoding="utf-8" ?>

</register>

</container>

</unity>

PS: Пример можно доработать, добавив дополнительные параметры настройки транзакции, например:

[TransactionMethod(TransactionScopeOption.Suppress)]

Ссылки:

Hello, Entity Framework "Code-First"

noreply@blogger.com (Илья Дубаденко) — Fri, 08 Apr 2011 10:38:00 +0000

В этой статье рассмотрим простой пример, демонстрирующий новый способ разработки через "Code-first" для Entity Framework 4. В первую очередь, Entity Framework 4 Code-First нацелен на разработчиков, сфокусированных на Domain-driven design (DDD).
Предположим у нас имеется электронный магазин, в котором ведется два списка: список покупателей (Customers) и список заказов (Orders), которые храняться в базе данных ShopDb. Необходимо реализовать CRUD доступ над указанными сущностями в базе данных, используя весь потенциал Entity Framework 4.
Итак, в лучших традициях DDD начнем нашу работу с описания предметной области, для этого добавим в наш Solution проект (назовем его Domain), в который добавим два POCO (plain old CLR objects) класса Customer и Order, связанных отношением один-ко-многим:

public class Customer

{

public int CustomerId { get; set; }

public string ContactName { get; set; }

public virtual ICollection<Order> Orders { get; set; }

}

public class Order

{

public int OrderId { get; set; }

public string Description { get; set; }

public Customer Customer { get; set; }

}

Важно отметить тот факт, что наша модель не реализует сторонних интерфейсов, не наследуется от сторонних классов (например от EntityObject, как это было в предыдущей версии EF) и доступна для редактирования и полностью располагается в отдельной сборке (и мы можем легко экспортировать ее как часть в другой проект) и никаких auto-generated моделей и partial-классов, никаких T4 преобразований. Мы сосредоточились на предметной области и реализовали чистую модель и ничего лишнего.
Приступим ко второй части статьи: реализации CRUD функционала над предметной областью используя Entity Framework с новой возможностью code-first. Для этого добавим в solution новый проект со сылкой на наш Domain и System.Data.Entity (стандартное пространство имен для EF), в который добавим класс ShopDbContext:

public class ShopDbContext : DbContext

{

public DbSet<Customer> Customers { get; set; }

public DbSet<Order> Orders { get; set; }

}

Классы DbContext и DbSet это новые классы, добавленные в Entity Framework Code-first. Если проводить аналогию, то DbContext это аналог ObjectContext, контейнер наших сущностей, а DbSet аналог ObjectSet, черз который мы будем осуществлять все наши запросы. Если заглянуть глубже, то можно увидеть, что DbContext реалиует интерфейс IObjectContextAdapter, который содержит ссылку на уже знакомый нам ObjectContext.
EF уже содержит в себе все необходимые настройки по-умолчанию, и чтобы начать его использовать вам остается только указать строку соединения к базе данных:

<?xml version="1.0" encoding="utf-8" ?>

</connectionStrings>

</configuration>

По-умолчанию, контекст EF выбирает ту строку соединения, имя которой совпадает с названием самого контекста, в нашем случае это ShopDbContext. И если мы запустим приложение, EF по-умолчанию выбирает стандартный маппинг и автоматически создает структуру базы, если такова отсутствует. В нашем случае будет создана новая база ShopDb, содержащая три таблицы: Customers, Orders и служебную EdmMetadata (таблица для идентификации текущего контекста).
Таблица EdmMetadata содержит хэш код от текущей EF модели, и если мы изменим модель, например добавим поле Address в Customer, то при следующем запуске приложения получим исключение:
The model backing the 'ShopDbContext' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data..
В исключении сказано, что EF-модель была обновлена, и текущая схема базы данных перестала соответствовать предметной области и ее необходимо пересоздать либо обновить.
По-умолчанию EF не знает, как выполнить подобный upgrade нашей БД, но мы можем ей это указать, передав в процедуру Database.SetInitializer(.) перед стартом приложения свой IDatabaseInitializer, или например воспользоваться уже готовым DropCreateDatabaseIfModelChanges.
Например, если мы хотим очищать базу каждый раз при обновлении модели:

Database.SetInitializer<ShopDbContext>(new DropCreateDatabaseIfModelChanges<ShopDbContext>());

Caching в WCF сервисе

noreply@blogger.com (Илья Дубаденко) — Thu, 10 Mar 2011 13:41:00 +0000

Кэширование данных неотъемлемая часть высоконагруженных и ресурсоемких проектов. В этой статье я опишу процесс организации оптимального механизма кэширования в WCF сервисе. Сформулирую задачу: имея WCF сервис, нужно организовать кеширование результатов работы любого сервис-метода в зависимости от входных параметров (Caching Support for WCF Services). Существует множество решений поставленной задачи, и самое простое и очевидное, это организовать кэширование прямо в сервис-методе:

public DateTime GetDate()

{

ICache cache = ...; // получим экземпляр кэша

string key = "somekey";

object value;

// Попробуем достать данные из кэша

if (!cache.TryGet(key, out value))

{

// Данные в кэше отсутствуют,

// получим новые данные

value = DateTime.Now;

// и поместим их в кэш на 5 секунд

cache.Add(key, value, TimeSpan.FromSeconds(5));

}

return (DateTime)value;

}

Из примера видно, что сервис-метод GetDate перегружен логикой кэширования, и с появлением еще одного аналогичного сервис-метода, логика кэширования будет просто скопирована в него. Очевидно, что такой подход приведет к тому, что со временем такой код станет труднее поддерживать при изменении схемы кэширования, и естественно возникает вопрос об организации функционала сквозного кэширования. Организовать такую функциональность можно через AOP или в случае с WCF можно воспользоваться стандартным механизмом перехвата вызова через специальные интерфейсы (WCF Interceptor Interfaces), а точнее через интерфейс IOperationInvoker.
И, предже чем приступить к реализации наметим основные шаги:

Для начала создадим простой WCF сервис
Объявим интерфейс кэша ICache
Реализуем свой перехватчик (IOperationInvoker)
И закончим реализацией IOperationBehavior атрибута для нашего перехватчика

Шаг 1. Создадим новый WCF проект, назовем его MyService, с контрактом в виде интерфейса:

[ServiceContract]

public interface IMyService

{

[OperationContract]

DateTime GetDate();

}

Сервис метод GetDate() будет возвращать текущее время на сервере (этот метод и будем кэшировать).

public class MyService : IMyService

{

public DateTime GetDate()

{

return DateTime.Now;

}

Шаг 2. Наш WCF сервис будет работать с кэшем, но пока у нас нет конкретной реализации кэша, поэтому определим только интерфейс:

public interface ICache

{

bool TryGet(string key, out object value);

void Add(string key, object value, TimeSpan timeout);

}

Для простоты, в интерфейсе только два метода, для извлечения из кэша (TryGet) и помещение в кэш (Add).
Шаг 3. Теперь самое интересное. Когда мы делаем вызов любого сервис-метода из клиентского приложения, мы посылаем WCF сервису сообщение (SOAP), которое содержит: название метода, входные параметры для метода и прочее. Далее WCF сервис, получив запрос от клиента в виде сообщения (SOAP), наравляет его на обработку в свой Dispatcher - некий конвеер по обработке запроса, который можно разбить на два последовательных участка: DispatchRuntime и DispatchOperation. Нас будет интересовать последний, так как именно там (а более точнее в экземпляре объекта типа IOperationInvoker) происходит непосредственный вызов сервис метода с передачей ему уже десериализованных входных параметров и получение результатов выполнения, которые мы и собираемся кэшировать. Стандартный IOperationInvoker не умеет кэшировать, поэтому придется написать свой:

public class CacheOperationInvoker : IOperationInvoker

{

IOperationInvoker _invoker;

ICache _cache;

TimeSpan _timeout;

public CacheOperationInvoker(IOperationInvoker invoker, ICache cache, TimeSpan timeout)

{

_invoker = invoker; // стандартный OperationInvoker

_cache = cache; // наш объект кэша

_timeout = timeout; // как долго объект будет находиться в кэше

}

public object Invoke(object instance, object[] inputs, out object[] outputs)

{

// Хэш ключ.

// Разумно вычислять его на основе

// входных параметров и названия кешируемого метода.

// Но мы для простоты обойдемся константой.

string key = "somekey";

Tuple<object, object[]> result;

object cacheItem;

// Попробуем достать данные из кэша

if (!_cache.TryGet(key, out cacheItem))

{

// Данные в кэше отсутствуют,

// получим новые данные, вызовем базовый Invoke

object returnValue = _invoker.Invoke(instance, inputs, out outputs);

// Подготовим новый элемент кэша (упакуем returnValue и outputs)

result = Tuple.Create<object, object[]>(returnValue, outputs);

// Выполним кэширование на указанный timeout

_cache.Add(key, result, _timeout);

}

else

{

// Данные нашлись в кэше

result = cacheItem as Tuple<object, object[]>;

}

outputs = result.Item2;

return result.Item1;

}

public object[] AllocateInputs()

{

// просто пробрасываем вызов

return _invoker.AllocateInputs();

}

public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)

{

// просто пробрасываем вызов

return _invoker.InvokeBegin(instance, inputs, callback, state);

}

public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)

{

// просто пробрасываем вызов

return _invoker.InvokeEnd(instance, out outputs, result);

}

public bool IsSynchronous

{

// просто пробрасываем вызов

get { return _invoker.IsSynchronous; }

}

Шаг 4. Вся основная работа уже сделана, осталось как то наделить наш севис метод данным поведением. Для этого надо реализовать атрибут, который к тому же еще и IOperationBehavior:

public class CacheBehaviorAttribute : Attribute, IOperationBehavior

{

TimeSpan _timeout;

public CacheBehaviorAttribute(int seconds)

{

_timeout = TimeSpan.FromSeconds(seconds);

}

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

// Стандартный OperationInvoker

IOperationInvoker invoker = dispatchOperation.Invoker;

// Наш кэш, разумно сделать его singleton

// и получать из DI/IoC-контейнера

ICache cache = new MyCache();

// Подменим стандартный OperationInvoker расширенным.

dispatchOperation.Invoker = new CacheOperationInvoker(invoker, cache, _timeout);

}

public void Validate(OperationDescription operationDescription)

{

}

public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)

{

}

public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

{

}

и не забываем пометить этим атрибутом севис-метод в сервис-интерфейсе:

[ServiceContract]

public interface IMyService

{

[OperationContract]

[CacheBehavior(5)] // Кэшируем результат на 5 секунд

DateTime GetDate();

}

PS: Если Вы реализуете кэширование для WCF Web HTTP Services, то нужно использовать стандартный механизм кэширования ASP.net. Пример, приведенный в статье, демонстрирует общий подход к решению проблемы.

Ссылки:

Extending WCF with Custom Behaviors

IoC/DI в WCF на примере Unity 2.0

noreply@blogger.com (Илья Дубаденко) — Thu, 20 Jan 2011 09:08:00 +0000

В этой статье я продемонстрирую процесс внедрения IoC/DI контейнера (на примере Unity 2.0) в WCF сервис. В примере я выбрал Unity 2.0, но на самом деле это не существенно, и по желанию можно легко адаптировать код под другой IoC/DI контейнер. Для тех кто не знаком еще с данным контейнером, рекомендую глянуть вводную статью. Существуют несколько путей внедрения IoC/DI контейнера в WCF сервис, рассмотрим один из них*.
Итак, предже чем приступить к реализации наметим основные шаги:

Для начала создадим простой WCF сервис
Реализуем свой IInstanceProvider
Далее опишем собственную реализацию IServiceBehavior
Определим BehaviorExtensionElement
И закончим, добавив необходимые настройки в web.config

*На самом деле это не единственный способ внедрения контейнера, существуют варианты с использованием ServiceHostBase и ServiceHostFactoryBase

Шаг 1.Создадим новый WCF проект, назовем его WcfService, с контрактом в виде интерфейса:

[ServiceContract]

public interface IHelloService

{

[OperationContract]

string Say(string name);

}

Реализуем данный интерфейс в виде класса, с осуществлением инъекции (injection) в виде типа IEnveloper в конструктор:

public class HelloService : IHelloService

{

IEnveloper _enveloper;

// Инъекция типа IEnveloper в конструктор

public HelloService(IEnveloper enveloper)

{

_enveloper = enveloper;

}

public string Say(string name)

{

string data = string.Format("Hello, {0}", name);

return _enveloper.Envelop(data);

}

Шаг 2.За создание экземпляра IHelloService отвечает IInstanceProvider, но стандартный IInstanceProvider не умеет делать инъекции, поэтому необходимо реализовать свой, для этого добавляем следующий класс:

public class UnityInstanceProvider : IInstanceProvider

{

IUnityContainer _container;

Type _serviceType;

public UnityInstanceProvider(IUnityContainer container, Type serviceType)

{

_serviceType = serviceType;

_container = container;

}

public object GetInstance(InstanceContext instanceContext, Message message)

{

// Я не использую здесь информацию message, хотя можно

// разрешать типы на основе полей (или заголовков)

// содержащиеся в message.

return GetInstance(instanceContext);

}

public object GetInstance(InstanceContext instanceContext)

{

// Здесь происходит разрешение типа, со всеми инъекциями.

return _container.Resolve(_serviceType);

}

public void ReleaseInstance(InstanceContext instanceContext, object instance)

{

// Так как тип породил контейнер, он же его и разрушает.

_container.Teardown(instance);

}

Шаг 3.UnityInstanceProvider готов, но стандартное поведение(behavior) использует страндартный InstanceProvider, и для того чтобы сообщить среде, что надо использовать наш UnityInstanceProvider нужно реализовать свое поведение (behavior):

public class UnityServiceBehavior : IServiceBehavior

{

IUnityContainer _container;

public UnityServiceBehavior(IUnityContainer container)

{

_container = container;

}

public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)

{

}

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)

{

foreach (var cdb in serviceHostBase.ChannelDispatchers)

{

ChannelDispatcher cd = cdb as ChannelDispatcher;

if (cd != null)

{

foreach (var ed in cd.Endpoints)

{

// Тип нашего сервиса

Type serviceType = serviceDescription.ServiceType;

// Подготовим провайдер.

// Хотя провайдер сам бы мог строить контейнер в себе,

// но лучше иметь один контейнер на всех.

IInstanceProvider provider = new UnityInstanceProvider(_container, serviceType);

// Укажем среде использовать наш провайдер.

ed.DispatchRuntime.InstanceProvider = provider;

}

public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)

{

}

Шаг 4.Осталось наделить наш новый WCF сервис нашим новым поведением UnityServiceBehavior. Это можно сделать как и в коде, так и через web.config (что удобнее). Так как UnityServiceBehavior является по сути расширением, и чтобы опледелить его в настройках (web.config) необходимо определить для него элемент конфигурации:

public class UnityServiceBehaviorExtensionElement : BehaviorExtensionElement

{

public override Type BehaviorType

{

get { return typeof(UnityServiceBehavior); }

}

protected override object CreateBehavior()

{

IUnityContainer container = new UnityContainer();

// Настраивать конечно лучше в конфигурационном

// файле, но так будет быстрее и надежнее.

container.RegisterType<IEnveloper, XmlEnveloper>();

return new UnityServiceBehavior(container);

}

где XmlEnveloper одна из возможных реализаций IEnveloper:

public class XmlEnveloper : IEnveloper

{

public string Envelop(string data)

{

return string.Format("<result>{0}</result>", data);

}

Шаг 4.Наделяем наш WCF сервис новым поведением, делается это просто в web.config.
Регистрируем расширение в секции extensions:

</behaviorExtensions>

</extensions>

Добавляем поведение serviceInjection в секцию behavior:

</behavior>

</serviceBehaviors>

</behaviors>

Сервис готов!

Строим идентификатор для множества

noreply@blogger.com (Илья Дубаденко) — Thu, 30 Dec 2010 17:26:00 +0000

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

Сформулируем требование следующим образом: найти такой оператор F, что для любого набора (u, v, ...) будет выполнено:
F(u, v, ...)= F(v, u, ...)=F(всевозможные перестановки) (условие коммутативности), причем не существует любого другого элемента z != u, такого что выполняется:
F(u, v, ...)=F(z, v, ...)=F(всевозможные перестановки) (условие уникальности)*.
Или более привычно: u, v, ... являются простыми ключами, а F(u, v, ...) составным ключом в единственном числе.

Где это может пригодиться? При работе со словарями (Dictionary). Например, Вам необходимо поместить объект Obj в Dictionary, для этого нужно построить ключ key, но как же быть, если Obj идентифицируется множеством (u, v, ...), а как известно, элементы множества не упорядочены и мы не можем просто построить цепочку идентификаторов (key1, key2, ...) (по аналогии со вложенными Dictionary). Ключ в данной задаче находится как применение оператора F на искомое множество: key=F(u, v, ...).

Без ограничения общности можно принять, что набор есть множество строк и ограничиться набором из 2-х элементов.

Как оказалось, решение очень простое, для того чтобы построить уникальный ключ для множества из двух строк u и v, нужно посимвольно сравнить u и v, выбрав max = max(u, v), min = min(u, v) (в данном случае необходимо найти только либо max либо min), а далее выполнить простую конкатенацию (concat) полученых значений через разделитель (delimiter):
F(u, v) = max(u, v) + delimiter + min(u, v).
По аналогии задачу можно продолжить на n-мерный случай.

UPD*: Стоит заметить, что если вместо Dictionary использовать Hashtable, то условие уникальности ключа не обязательно (см. комментарии).

Всем спасибо!
И Всех с наступающим Новым Годом!

Используем Reflection в T4 (Text Template Transformation Toolkit)

noreply@blogger.com (Илья Дубаденко) — Wed, 22 Dec 2010 12:18:00 +0000

Недавно, мне была поставлена следующая задача: для каждого класса из стороннего API, разработать обертку (wrapper class), для удобства использования стороннего API. Оптимальное решение подобных задач всегда использовать кодогенерацию, а наиболее удобный инструмент для этого, это T4 (Text Template Transformation Toolkit). Так как набор классов находился в уже скомпилированной сборке, то действовать надо было только через System.Reflection. Как выяснилось позже, что при работе со сборкой через reflection в T4 возникает проблема блокировки, загружаемой через Assembly.Load, сборки. Stackoverflow подсказал, что для решения данной проблемы нужно воспользоваться FxCop API, предоставляющий достаточный инструментарий для работы со сборкой на уровне Reflection.

На момент написания статьи была доступна версия 1.35, релиз которой доступен здесь. Не буду вдаваться в подробности моей задачи, а просто приведу простой Hello-world пример работы с FxCop библиотекой. Итак после установки FxCop, добавим в наш проект новый T4 файл (TestTemplate.tt) содержащий следующий код:

<#@ template debug="true" hostSpecific="true" #>
<#@ output extension=".T4.txt" #>
<#@ assembly name="C:\Program Files\Microsoft FxCop 1.35\FxCopSdk.dll" #>
<#@ assembly name="C:\Program Files\Microsoft FxCop 1.35\Microsoft.Cci.dll" #>
<#@ import namespace="Microsoft.Cci" #>
<#
string assemblyPath = @"...путь к нашей сборке...";

// Загрузка сборки без блокировки (аналог Assembly)
AssemblyNode assembly = AssemblyNode.GetAssembly(assemblyPath);

// Указываем какое пространство имен
Identifier namespaceId = Identifier.For("SomeNamespace");

// Указываем какой тип (у нас это имя класса)
Identifier typeId = Identifier.For("SomeType");

// Получаем полную информацию о типе (аналог System.Type)
TypeNode type = assembly.GetType(namespaceId, typeId);

// Перечислим все члены типа (свойства, методы, события)
foreach(Member member in type.Members)
{
// Публичный ли член
if(member.IsPublic)
{
WriteMember(member);
}
}
#>
<#+

void WriteMember(Member member)
{
// Если член является свойством
if(member is Property)
WriteProperty(member as Property);
}

void WriteProperty(Property property)
{
// Получим имя свойства (полное имя, имя)
Identifier name = property.Name;

// Получим CLR тип свойства System.Type.
System.Type type = property.Type.GetRuntimeType();

// Форматируемый вывод.
WriteLine("Property '{0}' type of '{1}'", name, type);
}

#>
Выполнив "Run Custom Tool" на шаблоне T4 мы получим текстовый файл (TestTemplate.T4.txt), в котором перечилены все публичные свойства указанного типа, с указанием имени свойства и его CLR типа:

Property 'SomeProperty' type of 'System.Int32'

Так как сейчас я не генерировал код, я просто вывел результат в обычный текстовый файл.
Оригинальный тип:

namespace SomeNamespace

{

public class SomeType

{

public int SomeProperty

{

set; get;

}

public void SomeMethod()

{

}

Дальше можно усложнить нашу разметку. Например, разметка в виде C# кода, для получения исходника, или разметка в виде XML, CSV и другие.

Ссылки:

False sharing

noreply@blogger.com (Илья Дубаденко) — Wed, 17 Nov 2010 09:53:00 +0000

Казалось бы, зачем задумывываться о процессах, происходящих на таком низком уровне, как кэширование данных в L1 и L2 кешах (L1, L2 cache), если Вы программируете под .NET. Очевидно для повышения быстродействия программы (perfomance) за счет уменьшения кэш-промахов (Cache Miss). Самый простой и классический пример демонстрирующий проблему Cache Miss, это "неправильный" обход массива. При "правильном" обходе количество промахов будет минимально, следовательно участок кода выполнится быстрее:

int size = 10000;

int[,] matrix = new int[size, size];

// Вариант 1

// Очень медленный вариант

for (int col = 0; col < size; col++)

for (int row = 0; row < size; row++)

matrix[row, col] = 0;

// Вариант 2

// Быстрый вариант

for (int row = 0; row < size; row++)

for (int col = 0; col < size; col++)

matrix[row, col] = 0;

Еще один пример (с wikipedia), допустим нам необходимо как-то вычислять поле Foo.x, в нашем случае это простая инкрементация:

// Вариант 1

// Очень медленный

Foo foo = new Foo();

for (int i = 0; i < MaxIter; i++)

foo.x++;

против

// Вариант 2

// С локальной переменной, быстрый.

Foo foo = new Foo();

int sum = 0;

for (int i = 0; i < MaxIter; i++)

sum = sum + 1;

где

class Foo

{

public int x = 0;

}

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

// Вариант 1

// Создадим экземпляры Some в главном потоке

Some some1 = new Some();

Some some2 = new Some();

Some some3 = new Some();

// Запустим 3 паралельных задачи

Parallel.Invoke

(

() => { for (int i = 0; i < MaxIter; i++) { some1.Do(); } },

() => { for (int i = 0; i < MaxIter; i++) { some2.Do(); } },

() => { for (int i = 0; i < MaxIter; i++) { some3.Do(); } }

);

против

// Вариант 2

// Запустим 3 паралельных задачи

// Инициализация Some будет происходить внутри каждой задачи.

Parallel.Invoke

(

() => { Some some1 = new Some(); for (int i = 0; i < MaxIter; i++) { some1.Do(); } },

() => { Some some2 = new Some(); for (int i = 0; i < MaxIter; i++) { some2.Do(); } },

() => { Some some3 = new Some(); for (int i = 0; i < MaxIter; i++) { some3.Do(); } }

);

Q:Какой из этих двух вариантов выполнится быстрее?
A: Все зависит от реализации метода Some.Do. Если метод Do изменяет состояние объекта Some таким образом, что строка (cache line) загруженная в кэш станет недействительной, то почти наверняка, второй вариант будет выполнятся намного быстрее первого (ситуация False Sharing), иначе оба варианта потребуют примерно одинаковое время на выполнение.
Например, подобная реализация Some увеличит время исполнения первого варианта относительно второго:

// Реализация Some с изменяемым состоянием

class Some

{

int _x = 0; // состояние объекта Some

public void Do()

{

// изменение состояния

_x++;

}

Но стоит увеличить объект таким образом, что кэшируемые данные окажутся в разных кэш-строках, то скорость выполнения первого и врогого варианта сравняется:

// Реализация Some с изменяемым состоянием

class Some

{

int _x = 0; // состояние объекта Some

// больше чем размер кэш-строки

long l1;

long l2;

long l3;

long l4;

long l5;

long l6;

long l7;

long l8;

long l9;

long l10;

long l11;

long l12;

long l13;

long l14;

long l15;

long l16;

public void Do()

{

// изменение состояния

_x++;

}

Ссылки:

Настройка логов на примере NLog

noreply@blogger.com (Илья Дубаденко) — Fri, 29 Oct 2010 15:10:00 +0000

Хочу поделиться с Вами своим best practices по настройке логирования на примере NLog. Логи, это первая вещь, которую приходится настраивать при создании нового проекта, причем обычно для каждого нового проекта настройки логирования выглядят, как шаблонное решение, поэтому разумно выделить единый общий шаблон и использовать его в своих проектах. В данной статье рассмотрим мое простое шаблонное решение, которое я успешно применяю во многих своих проектах. Основная идея которую я отразил в шаблоне, это ведение не одного общего лога, а нескольких, каждый из которых лишь отличается уровнем подробности логирования и назначением, это 2 основных и 2 вспомогательных лога.

Основные
1. ShortLog - служит для общей оценки работы приложения и выполнят роль "оглавления" для FullLog. Из-за сравнительно небольших размеров его удобно анализировать.
  - Лог пишется в файл на диск.
  - Уровень логирования задан как Info.
  - Для уровня Error, Fatal записывается только комментарий ошибки.
2. FullLog - служит для детального анализа работы приложения и включает в себя ShortLog. Анализируется выборочно.
  - Лог пишется в файл на диск.
  - Уровень логирования задан как Debug либо Trace.
  - Для уровня Error, Fatal записывается комментарий ошибки и информация об исключении.
Вспомогательные
1. ConsoleLog - аналогичен ShortLog и служит для мониторинга работы программы.
  - Лог пишется в консоль.
  - Уровень логирования задан как Info.
  - Для уровня Error, Fatal записывается только комментарий ошибки.
2. SystemLog - аналогичен FullLog, но менее подробен и служит для ведения лога основе EventLog.
  - Лог пишется в EventLog.
  - Уровень логирования задан как Info.
  - Для уровня Error, Fatal записывается комментарий ошибки и информация об исключении.

Что касается самих логов, то у меня существуют несколько правил:

Метку времени в persist-логах предпочитаю полную в формате dd.MM.yyyy HH:mm:ss
Уровень логирования в логах записываю заглавными сразу же после метрки времени и в скобках: 29.10.2010 12:39:40 (INFO)
Все логи ведутся в единой директории log
Лог файлы создаются на текущую дату и располагаются в директории созданной на основе текущей даты в формате yyyy-MM-dd, для удобства сортировки

Приведу пример конфигурационного файла (NLog.config) для NLog:

<?xml version="1.0" encoding="utf-8" ?>

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<target

name="consoleLog"

xsi:type="Console"

layout="${shortLayout}" />

<target

name="shortLog"

xsi:type="File"

fileName="${logDir}/short.log"

layout="${commonLayout}" />

<target

name="fullLog"

xsi:type="File"

fileName="${logDir}/full.log"

layout="${detailedLayout}" />

<target

name="systemLog"

xsi:type="EventLog"

layout="${detailedLayout}" />

</targets>

<rules>

</rules>

</nlog>

Пишем обертку для Stopwatch

noreply@blogger.com (Илья Дубаденко) — Wed, 06 Oct 2010 19:25:00 +0000

Во время работы приложения, в качестве мониторинга времени выполнения метода или доступа к свойству используется класс Stopwatch из System.Diagnostics. Работает Stopwatch очень просто, он замеряет время прошедшее между вызовами Start* и Stop* методами. Приведу простой пример:

// Наш секундомер.

Stopwatch timer = new Stopwatch();

timer.Start(); // Запустим секундомер

try

{

Thread.Sleep(1234); // долгая операция

}

finally

{

timer.Stop(); // Остановим секундомер

// Показания секундомера:

TimeSpan elapsed = timer.Elapsed;

Console.WriteLine("Время выполнения {0}", elapsed);

}

В данном примере видны все неудобства использования Stopwatch, это необходимость явно создавать объект Stopwatch, это явный запуск и остановка секундомера, при этом, если возможны исключения, то нужно добавить и обработку исключений.

Решение данной проблемы очевидное, нужно применить интерфейс IDisposable в сочетании с блоком using. Для этого реализуем вспомогательный класс:

class Watcher : IDisposable

{

Action<TimeSpan> _action;

Stopwatch _timer;

// закрытый конструктор

Watcher(Action<TimeSpan> action)

{

_timer = new Stopwatch();

_action = action;

_timer.Start();

}

public void Dispose()

{

_timer.Stop();

if (_action != null)

{

try

{

_action(_timer.Elapsed);

}

catch

{

// не забываем, что Dispose

// безопасен относительно

// исключений

}

public static Watcher Start(Action<TimeSpan> action)

{

return new Watcher(action);

}

И пример использования:

using (Watcher.Start(t => Console.WriteLine(t)))

{

Thread.Sleep(1234); // долгая операция

}

Получилась достаточно удобная конструкция, допускающая вложенность любой глубины и разделяющая код на блоки:

using (Watcher.Start(t => Console.WriteLine(t)))

{

using (Watcher.Start(t => Console.WriteLine(t)))

{

// операция 1

}

using (Watcher.Start(t => Console.WriteLine(t)))

{

// операция 2

}

Класс Watcher не является законченным, его можно расширять на вкус и цвет. Например, если ведется лог, можно сбрасывать информацию сразу в лог, который можно получать при помощи IoC and DI pattern. Либо добавить header/footer информацию, которая будет записываться в лог при входе или выходе из блока.

Ссылки:

Stopwatch Class

Шаблон реализации Equals

noreply@blogger.com (Илья Дубаденко) — Fri, 24 Sep 2010 15:49:00 +0000

Работая с объектами, нам часто явно или неявно приходится их сравнивать их друг с другом. За сравнение объектов отвечает метод Equals или его типизированная версия из IEquatable, возвращающая true в случае если объекты равны, в противном случае false. Стандартная реализация метода Equals не всегда удовлетворяет потребностям разработчика, так как она не учитывает конкретных особенностей объекта, и в этом случае, реализация конкретного Equals/IEquatable ложится на плечи самого разработчика. Каждый разработчик вправе по-своему реализовать данную функциональность (не нарушая правил Implementing the Equals Method), как ему будет удобно. У меня, как у разработчика, на этот счет со временем выработался удобный шаблон реализации метода Equals/IEquatable, состоящий из 2-х простых правил:

От простого к сложному: выполнять сравнение начиная с простых условий и заканчивая более сложными.
Понять равенство/неравенство объектов как можно раньше: делайте незамедлительный "return true/false".

Реализация шаблона на языке C# в комментариях на примере класса Foo:

class Foo : IEquatable<Foo>

{

public override bool Equals(object obj)

{

Foo foo = obj as Foo;

return this.Equals(foo);

}

public bool Equals(Foo other)

{

// От ПРОСТОГО к СЛОЖНОМУ.

// Выполняйте сравнение начиная с

// простых условий (проверка на null, сравнение ссылок)

// и заканчивая более сложными (сравнение содержимого).

if (other == null)

{

// this заведомо не null.

return false;

}

if (Object.ReferenceEquals(this, other))

{

// обе ссылки ссылаются на один и тот же объект.

return true;

}

// Сравнение содержимого.

// Здесь опишите конкретное сравнения по полям.

// От ПРОСТОГО к СЛОЖНОМУ.

// 1. Выделите самые простые относительно

// операции сравнения поля и сравните их первыми.

// Более сложные оставьте на конец.

// 2. Делайте незамедлительный "return false"

// при первом же несовпадении.

// 3. Сравнивайте поля класса методом Equals,

// за исключением простых типов: field.Equals(other.field)

// 4. Не забывайте в конце вызвать base.Equals(other).

return true;

}

Ссылки:

Implementing the Equals Method

Enum поле в XML API

noreply@blogger.com (Илья Дубаденко) — Tue, 31 Aug 2010 12:45:00 +0000

Проектируя публичное API очень важно понимать, что Ваше API будут использовать другие разработчики различного уровня, которые будут вынуждены разбираться в нем с нуля. Именно поэтому важную роль здесь играет простота и понятность созданного Вами API. Интуитивно-понятное API намного проще осваивать, и тем более использовать. Любое API подразумевает обмен сообщениями между "клиентом" и "сервером", и зачастую такие сообщения удобно записывать в виде XML. Стандартная ситуация, Вы формируете некий XML и посылаете его на сервер, сервер разбирает его и отвечает Вам другим XML (XML API). К примеру, это может быть запрос аутентификации:

<auth>

</auth>

</request>

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

</response>

С подобным в своей практике мне приходилось сталкиваться ни раз, поэтому решил написать об этом пост. На первый взгляд в ответе с сервера нет ничего подозрительного, но это только кажется. К примеру мы никогда не узнаем что обозначает код возврата 42, не имея под рукой документации к API, google. Более того, имея под рукой документацию, нам каждый раз придется нырять в нее, уточняя каждый полученный статус, либо придется держать его в уме. Еще хуже, это унаследовать число 42 в следующей версии API, со ссылкой на предыдущую.
Но все не так уж и плохо, данную проблему можно устранить, если записывать все коды, статусы, enum-поля и подобное в виде строк:

<result>LoginIncorrect</result>

</response>

Код "LoginIncorrect" более информативен нежели код "42". Даже не имея под рукой документации можно понять, что аутентификация прошла неуспешно, потому что пользователь с логином "ilya" не зарегистрирован в системе. Можно возразить, что передавать "LoginIncorrect" вместо "42" расточительно, но это только кажется. В противном случае переходите на бинарный протокол обмена данными.

Мой совет: всегда при проектировании внешнего XML API записываете все коды, статусы, enum-поля и подобное в виде строковых констант.

Marker Interface против Custom attributes

noreply@blogger.com (Илья Дубаденко) — Thu, 05 Aug 2010 16:02:00 +0000

Бывают случаи, когда у разработчика C# возникает острая необходимость пометить некую сущность маркером (Marker), и в зависимости от типа маркера соответственно обрабатывать сущность. Например, Вы получаете сообщения, и для различных типов сообщений (но не для всех, а например только для типа MessageB) делаете запись в лог о их получении (например, в методе OnReceive(Message msg)):

class Message{}

class MessageA : Message { }

class MessageB : Message { }

class MessageC : Message { }

Существуют несколько способов решения данной задачи, и первое что приходит в голову написать следующее:

void OnReceive(Message msg)

{

if(msg is MessageB)

{

// Делаем запись в лог, что

// получили сообщение типа B

}

очевидно, что такое быстрое решение не очень красивое, так если мы заходим логировать приход сообщения типа MessageC, то придется расширять if-условие.
Тогда на ум приходит идея ввести некий маркер, и если вспомнить про Marker Interface pattern, то мы получим следующую реализацию:

interface ILogMarker

{

// Пусто, интерфейс-маркер.

}

class Message{}

class MessageA : Message { }

// пометим маркером ILogMarker

class MessageB : Message, ILogMarker

{

}

class MessageC : Message { }

void OnReceive(Message msg)

{

if(msg is ILogMarker)

{

// Делаем запись в лог, что

// получили сообщение помеченное

// как ILogMarker.

}

Уже намного лучше, условие if у нас уже фиксировано. Единственное что должно смутить, это странное сочетание типа MessageB и интерфейса ILogMarker, ведь ILogMarker несет в себе метаинформацию, а не саму информацию о типе.
Но на этом можно было бы и остановиться, если бы не наличие такого инструмента как Custom attributes, и в этом случае, использовать "Marker Interface" при проектировании типов не рекомендуется (Interface Design: Avoid using marker interfaces (interfaces with no members)).
Итак, принимая во внимание данную рекомендацию:

// Custom attribute-маркер

class LogAttrubute : Attribute

{

}

class Message{}

class MessageA : Message { }

// пометим маркером LogAttrubute

[LogAttrubute]

class MessageB : Message, ILogMarker

{

}

class MessageC : Message { }

void OnReceive(Message msg)

{

if (msg.GetType().IsDefined(typeof(LogAttrubute), false))

{

// Делаем запись в лог, что

// получили сообщение помеченное

// как LogAttrubute.

}

Итого, мы получили фиксированное if-условие, метаданные о типе сообщения вынесены в Custom attributes, а не в сам тип в случае Marker Interface.

Ссылки:

NQueueing - Система Массового Обслуживания

noreply@blogger.com (Илья Дубаденко) — Tue, 03 Aug 2010 15:06:00 +0000

Хочу представить Вам свою миниатюрную библиотеку (NQueueing), упрощающая C# .NET разработчикам процесс разработки приложений, в которых присутствует многопоточная обработка очередей (Система Массового Обслуживания (СМО)). Библиотеку NQueueing можно скачать с nqueueing.codeplex.com как в виде исходников, так и в виде готовой сборки.

Q: Зачем это?
A: Библиотека содержит расширяемый набор классов и интерфейсов, представляющих для .NET разработчика простой инструмент для реализации собственной СМО.

Q: Пример использования?
A: Например, Вы пишете приложение которое принимает из сети пакеты, фильтрует, разбирает и складывает их в базу, при этом, каждый из перечисленных шагов выносится в отдельную СМО (отдельный(-ые) поток(и) со своей очередью). Обработка задач из очереди на каждом шаге происходит независимо от других шагов в отдельном потоке, что позволяет достичь максимальной производительности системы целиком.

Q: Как устроена?
A: Основу библиотеки NQueueing представляет интерфейс IServerQueue.

Интерфейс является generic-типом, и типизируется типом задачи. Все обработчики очередей реализуют данный интерфейс.
Уровнем выше, находится абстрактный базовый класс для всех обработчиков очередей ServerQueueBase, инкапсулирующий в себя общие свойства любой СМО (например: объект очередь и массив потоков).
Следующий уровень абстракции - это конкретные реализации различных типов СМО, унаследованные от ServerQueueBase классы: StandartServerQueue (для поштучной обработки задач из очереди) и BatchServerQueue (для пакетной обработки):

Q: Как использовать?
A: Использовать библиотеку достаточно просто:

Скачать библиотеку.
Добавить на нее reference в проекте. После чего станет доступен namespace NQueueing.
В зависимости от типа задачи, выбрать соответствующий тип СМО (StandartServerQueue, BatchServerQueue итп).
Далее создать экземпляр СМО (выбранной на предыдущем шаге), передав в конструктор ссылку на делегат, в котором и описывается процесс обработки пришедшей задачи, и указав параметры СМО: длина очереди, число потоков обработки.
При помощи потоко-безопасных TryEnqueue/Enqueue ставить задачи в очередь.

Простой пример:

using System;

using System.Threading;

// Добавить reference на библиотеку

using NQueueing;

namespace NQueueingTestApp

{

class Program

{

// Имитация случайной задержки

static Random rnd = new Random(DateTime.Now.Millisecond);

static void RandomSleep(int min, int max)

{

Thread.Sleep(rnd.Next(min, max));

}

static void ProcessingOne(int item)

{

// Обработать здесь задачу item...

// Обработка происходит в отдельном потоке.

RandomSleep(10, 300); // Случайная задержка в обработке

// Номер текущего потока, от 0 до (maxThreadsCount-1)

string name = Thread.CurrentThread.Name;

Console.WriteLine("{0} / Thread №: {1}", item, name);

}

static void Main(string[] args)

{

// Создадим Систему Массового Обслуживания состоящую

// из 3-х потоков и очередью длины 10.

IServerQueue<int> smo = new StandartServerQueue<int>(ProcessingOne, 10, 3);

smo.Start(); // Запускаем процесс обработки

// Добавим 15 задач в очередь

for (int task = 0; task < 15; task++)

{

// Поставим задачу в очередь в текущем потоке

EnqueueStatus result = smo.TryEnqueue(task);

RandomSleep(10, 100); // Случайная задержка при добавлении

Console.WriteLine("{0} / Enqueue: {1}", task, result);

}

smo.Close(); // Не забываем остановить

Console.ReadKey();

}

Q: Расширяемость?
A: Да, такая возможность есть. Для этого необходимо реализовать интерфейс IServerQueue, либо реализовать наследника от базового класса ServerQueueBase.

Буду благодарен за Ваши отзывы, рекомендации и конструктивные советы.

Ссылки:

Queueing model

Раcширяем IDisposable

noreply@blogger.com (Илья Дубаденко) — Thu, 22 Jul 2010 15:58:00 +0000

Наверняка Вы сталкивались с ситуацией, когда Вам требуется совершить явный вызов метода Dispose у объекта, реализующего интерфейс IDisposable, при этом, для каждого такого Dispose-вызова приходиться постоянно писать одинаковый код, по следующему шаблону (проверка на null, вызов IDisposable.Dispose):

// Освобождение ресурсов

if (some != null)

{

some.Dispose();

}

Раз этот код сильно похож и выделяется в шаблон, то его логично вынести в отдельный метод, а еще лучше в Extension Method для типа IDisposable:

static class IDisposableExtention

{

// Безопасный, относительно NullReferenceException Dispose

public static void SafeDispose(this IDisposable self)

{

if (self != null)

{

self.Dispose();

}

После чего, искомые четыре строчки кода для Dispose-вызова свернуться до одной - вызова нашего метода SafeDispose:

some.SafeDispose();

some.SafeDispose(); // При повторном вызове ничего не произойдет.

Блок using и null object

noreply@blogger.com (Илья Дубаденко) — Thu, 17 Jun 2010 12:29:00 +0000

Интересное поведение наблюдается, если в блоке using используется нулевой объект: using(null){...}. Казалось бы, очевидно, у нас должно возникнуть исключение NullReferenceException при попытке вызвать метод Dispose нулевого объекта (null object), как только мы выйдем за пределы блока using:

using ((IDisposable)null)

{

}

// Исключения NullReferenceException не будет.

// Метод Dispose вызван не будет.

Рассмотрим довольно распространенную конструкцию: Допустим, есть класс Some, реализующий интерфейс IDisposable:

class Some : IDisposable

{

public void Dispose()

{

Console.WriteLine("dispose");

}

и статический метод (например, это может быть какой-нибудь builder), возвращающий экземпляр Some:

static Some GetSome()

{

// Так получилось, что вернули null

return null;

}

Вопрос: "Возникнет ли NullReferenceException исключение, когда мы выйдем за пределы блока using?".:

using (Some some = GetSome())

{

if (some != null)

{

// Действия с some...

}

}// IDisposable.Dispose()

Ответ: "Нет, метод Dispose объекта some в данной ситуации вызван не будет.".
На самом деле, блок using будет оттранслирован в блок try...finally с проверкой на null:

Some some = GetSome();

try

{

if (some != null)

{

// Действия с some...

}

finally

{

if (some != null)

((IDisposable)some).Dispose();

}

Или:

.method private hidebysig static void Main(string[] args) cil managed

{

.entrypoint

// Code size 39 (0x27)

.maxstack 2

.locals init ([0] class NullUsing.Some some,

[1] bool CS$4$0000)

IL_0000: nop

IL_0001: call class NullUsing.Some NullUsing.Program::GetSome()

IL_0006: stloc.0

.try

{

IL_0007: nop

IL_0008: ldloc.0

IL_0009: ldnull

IL_000a: ceq

IL_000c: stloc.1

IL_000d: ldloc.1

IL_000e: brtrue.s IL_0012

IL_0010: nop

IL_0011: nop

IL_0012: nop

IL_0013: leave.s IL_0025

} // end .try

finally

{

IL_0015: ldloc.0

IL_0016: ldnull

IL_0017: ceq

IL_0019: stloc.1

IL_001a: ldloc.1

IL_001b: brtrue.s IL_0024

IL_001d: ldloc.0

IL_001e: callvirt instance void [mscorlib]System.IDisposable::Dispose()

IL_0023: nop

IL_0024: endfinally

} // end handler

IL_0025: nop

IL_0026: ret

} // end of method Program::Main

Ссылки:

Enum как результат

noreply@blogger.com (Илья Дубаденко) — Thu, 03 Jun 2010 12:13:00 +0000

Иногда, бывает очень удобно возвращать результат работы сервис-метода в качестве Enum значения. Представим ситуацию: Вы пишите сервис-метод, который возвращает два возможных состояния true/false (область значений), как бы Вы поступили, ограничились бы стандартным типом Bool или все-таки ввели бы новый Enum? Идея оставить Bool не совсем удачна, если вдруг придется расширить область значений сервис-метода. Например, в задаче аутентификации пользователя, где помимо информации об удаче/неудаче необходимо указать, в чем состоит неудача аутентификации, в итоге получим 4 возможных результата: "успех" (Ok), "провал" (Fail), "логин не верен" (LoginIncorrect), "пароль не верен" (PasswordIncorrect):

// Результат аутентификации

enum LoginStatus

{

// Успех

Ok = 0,

// Провал

Fail = (2 << 1),

// Уточняем, в чем провал:

LoginIncorrect = (2 << 2),

PasswordIncorrect = (2 << 3)

}

На этом можно было бы и закончить, но возможно, Вы возразите мне: "А как связаны статусы: Fail и PasswordIncorrect ? Интуитивно понятно, что связь между статусами есть.". Проблема решается просто на уровне битовых полей и флагов, давайте свяжем эти статусы следующим образом: статус PasswordIncorrect, это тот же статус Fail, но с небольшим уточнением в виде одного бита (2 << 3):

// Результат аутентификации

[Flags]

enum LoginStatus

{

// Успех

Ok = 0,

// Провал

Fail = (2 << 1),

// Уточняем, в чем провал:

LoginIncorrect = (2 << 2) | Fail,

PasswordIncorrect = (2 << 3) | Fail

}

Вот это уже намного лучше. Осталось привести пример использования:

if ((LoginStatus.Fail & status) == LoginStatus.Fail)

{

// Аутентификация завершилась неудачей

// и не важно, почему.

}

if ((LoginStatus.LoginIncorrect & status) == LoginStatus.LoginIncorrect)

{

// Аутентификация завершилась неудачей:

// как минимум логин пользователя не существует.

}

if ((LoginStatus.PasswordIncorrect & status) == LoginStatus.PasswordIncorrect)

{

// Аутентификация завершилась неудачей:

// как минимум пароль указан неверно.

}

Допустим, мы ввели еще один статус "Пароль имеет пустое значение" (PasswordIsEmpty), тогда мы с легкостью сможем расширить наш Enum следующим образом:

// Результат аутентификации

[Flags]

enum LoginStatus

{

// Успех

Ok = 0,

// Провал

Fail = (2 << 1),

// Уточняем, в чем провал:

LoginIncorrect = (2 << 2) | Fail,

PasswordIncorrect = (2 << 3) | Fail,

// Пустой пароль

PasswordIsEmpty = (2 << 4) | PasswordIncorrect

}

Достоинства:

Никаких magic-constants.
Простота и легкость расширения.
Установление взаимосвязей за счет комбинирования.

Недостатки:

Ограничение числа возможных статусов разрядностью Enum.

Ссылки:

Enumeration Types (C# Programming Guide)

XML elements или XML attributes

noreply@blogger.com (Илья Дубаденко) — Thu, 27 May 2010 12:41:00 +0000

Всегда проектируя структуру XML файла, Вы наверняка задумывались, где хранить данные: в атрибуте (XML attribute) или все-таки в узле (XML element). Это довольно важный вопрос, который нужно решить раз и навсегда еще на этапе проектирования XSD схемы, иначе последующее переделывание XSD схемы не есть хорошая практика. Обратите внимание на два XML файла:

<?xml version="1.0" encoding="utf-8" ?>

<root>

</root>

<?xml version="1.0" encoding="utf-8" ?>

<root>

<child>

<data>

some data

</data>

</child>

</root>

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

Узел не может содержать несколько атрибутов, с одинаковыми именами.
Узел можно легко расширить, добавив в него дочерние элементы (узлы или атрибуты).
Узлы упорядочены между собой, атрибуты нет.
Узлы могут хранить секцию CDATA, атрибутам приходиться хранить экранированные значения.
Узлы позволяют описать структуру данных, атрибуты могут содержать только плоские данные.
Атрибуты имеют более компактную форму записи.
Атрибуты имеют значения по-умолчанию.

Хорошей практикой считается хранить в атрибутах метаданные (metadata), а в узлах сами данные (!)

Резюмируя, можно сказать, что ID, Name, Date, Money и подобное лучше хранить а атрибутах, большие тексты, данные (нуждающиеся в экранировании), списки, тем более данные, которые можно представить в виде структуры, храните в узлах.

<!-- Неудачный вариант разметки.

body - может содержать спец. символы,

быть достаточно длинным полем, и нет

гарантий, что оно в дальнейшем не

расширится дочерними узлами.

-->

<!-- Универсальный вариант, храним все в узлах.

Много текста и выглядит немного громоздко.

-->

<body>Hello world</body>

</message>

Hello world

</message>

Ссылки:

Thread-safe events

noreply@blogger.com (Илья Дубаденко) — Fri, 14 May 2010 18:07:00 +0000

Если Вы пишите многопоточное приложение, то всегда стоит задумываться о потоко-безопасности (thread safe). Сегодня затронем важную тему про то, как правильно возбуждать событие (event raise), доступ к которому осуществляется в нескольких потоках.

class SomeClass

{

// Доступ к данному событию происходит

// в нескольких потоках.

public event EventHandler SomeEvent;

}

Стандартный, потоко-безопасный (thread safe) шаблон вызова события выглядит следующим образом:

// Потоко-безопасный вызов.

public void OnSomeEventThreadSafe(EventArgs args)

{

// Очень важно, сделать копию события:

EventHandler handler = SomeEvent;

// И далее работать только с ней:

if (handler != null)

{

handler(this, args);

}

Зачем, нам работать с копией, если мы можем и с оригиналом? Если коротко, то при многопоточном доступе к событию SomeEvent, у нас может возникнуть исключение. Например, если второй поток удалит последний зарегистрированный delegate из SomeEvent, в то время как в первом потоке проверка SomeEvent!=null была успешно пройдена.

// Не потоко-безопасный вызов.

void OnSomeEvent(EventArgs args)

{

if (SomeEvent != null)

{

// SomeEvent - может оказаться равным null.

SomeEvent(this, args);

}

Видно, что при добавлении нового события, при потоко-безопасном подходе приходится дублировать один и тот же кусок кода (копирование-проверка-вызов). Данное дублирование можно избежать, если вынести всю логику в метод-расширение (Extension Methods):

static class EventHandlerExt

{

// Метод расширение, для организации потоко-безопасного вызова события.

public static void Raise(this EventHandler self, object sender, EventArgs args)

{

EventHandler handler = self;

if (handler != null)

{

handler(sender, args);

}

Использование:

SomeEvent.Raise(this, EventArgs.Empty);

UPD:
Хотя Рихтер рекомендует использовать в качестве "копирования" следующее:

EventHandler temp = Thread.VolatileRead(ref SomeEvent);

//или

EventHandler temp = Interlocked.CompareExchange(ref SomeEvent, null, null);

объясняя это следующим:
Remember that delegates are immutable and this is why this technique works in theory. However, what a lot of developers don’t realize is that this code could be optimized by the compiler to remove the local temp variable entirely.... so a NullReferenceException is still possible.

Ссылки: