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

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

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

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

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

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

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

Mock для ICloneable типов

Буквально недавно я столкнулся с задачей, суть которой заключалась в том, чтобы создать 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;

}

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

Все программисты знают, что пришедшие из внешнего источника данные всегда надо проверять. Например в качестве входного параметра для метода (свойства, конструктора), может приходить ссылка, которую нужно проверить на 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;

    }

}

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

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

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

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

Hello, Entity Framework "Code-First"

В этой статье рассмотрим простой пример, демонстрирующий новый способ разработки через "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; }

}

Caching в WCF сервисе

Кэширование данных неотъемлемая часть высоконагруженных и ресурсоемких проектов. В этой статье я опишу процесс организации оптимального механизма кэширования в 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.
И, предже чем приступить к реализации наметим основные шаги:

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

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

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

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

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