Шаблон спецификации, определенный в домене

Question

Используя Linq to SQL и доменный уровень в стиле DDD с разделенными репозиториями, у кого-нибудь есть хорошие идеи о том, как внедрить шаблон спецификации без утечки L2S в доменный уровень, все еще понятно? :)

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

Это создает проблему, потому что для реализации Спецификации домен (насколько я могу судить) должен видеть запрашиваемые типы (типы L2S).

Есть идеи?

Кроме того, nHibernate не может быть рассмотрен по причинам, которые я не хочу объяснять ..:)

Answer 1

Рассматривали ли вы преобразование ваших общих спецификаций в дерево Expression, которое будет переводиться в правильный синтаксис L2S? Похоже, это главная проблема, которую вы здесь решаете. Шаблон спецификации не является проблемой, но отображение в L2S равно.

Answer 2

У меня недавно была такая же проблема. Другой шаблон, но все же LINQ to SQL (L2S). Я попробовал два разных способа избежать утечки.

Сначала мы попробовали использовать DTO и слой отображения. Итак, мы написали супер простые объекты, которые имели однозначное сопоставление с таблицами. Все они были украшены атрибутами L2S. Затем мы написали слой отображения, чтобы сопоставить DTO с нашими бизнес-объектами. Все это было скрыто через шаблон Repository от Doman Driven Design. Таким образом, потребители бизнес-объектов даже не подозревали, что L2S находится под капотом.

Дальше, в основном для разнообразия. Мы попытались использовать функции отображения XML в L2S, поэтому сами объекты не нуждались в атрибутах. Для коллекций мы выставили IEnumerable вместо любой из коллекций L2S. Если вы посмотрите на внутренности бизнес-классов, вы все равно сможете обнаружить некоторое использование L2S (EntitySet или Ref). Но потребители этого класса понятия не имели. Таким образом, некоторые биты утечки, но ничего радикального.

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

Итак, в конце мы помещаем слой между L2S и доменом. Это сработало. Потребовалось больше кода, но это было действительно просто. И все это было очень проверяемым.

Answer 3

Если вы не хотите ссылаться на Linq2Sql со своего доменного уровня, вы должны работать с интерфейсами, которые представляют ваши сущности, а не с самими сущностями. Затем вам нужен слой отображения между вашими интерфейсами и вашими сущностями.

Я работал таким образом и обнаружил, что это серьезное препятствие. Я переключился на NHibernate для новых проектов, а для старых проектов я просто перестал беспокоиться о домене, ссылающемся непосредственно на сущности Linq2Sql. На мой взгляд, преодоление этого ограничения просто слишком дорого.

Answer 4

Классы Linq-To-Sql могут быть частичными. Это означает, что вы можете расширить их, реализовав частичное, реализующее общий интерфейс. Этот интерфейс может быть разделен между слоями без проблемы «кровотечения», которую вы описываете. Остальное - это просто детали вашего «IsStatisfiedBy», которые легко инкапсулировать.