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

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

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

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

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

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

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

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

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

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

Совместное использование Repository с Unit Of Work.

В этом посте я решил поделиться мыслями о том, как можно применить паттерн Repository совместно с паттерном Unit Of Work (UOW). Рассмотрим это на конкретном примере. Для этого введем две сущности: Customer и Order, состоящим в отношении один-ко-многим соответственно.