Как вы храните свою доменную логику отдельно от DB / Persistence Logic с Linq-2-Sql?

Question

Я пытаюсь найти наилучший способ разделить проблемы моей логики предметной области и логики постоянства.Я использую Linq-2-Sql для доступа к данным, и я следую учебному пособию NerdDinner .Если вы посмотрите на страницу 40, то увидите, что они используют частичные классы для бизнес-правил в своих классах, сгенерированных Linq.Для меня это кажется неправильным (не так ли?), И я хотел бы иметь свои собственные POCO, которые представлены на уровне представления моего приложения.Похоже, что одна опция здесь , это использовать отдельный класс DTO.Мне это кажется лучше, но он добавляет гораздо больше кода для тестирования и поддержки.

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

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

Таким образом, мой текущий подход состоит в том, что две библиотеки классов - одна с Linq-2-Sql DBML + частичные классы, а вторая - с набором классов, которые не имеют ничего, кроме автоматически сгенерированных свойств, а затем класс «репо»который управляет получением данных из сборки Linq и преобразованием их в IQueryable<T>.

Есть ли лучший способ?Есть ли лучшая золотая середина?Могу ли я взять лучшее из обоих миров?Если да, как бы вы разделили их на разные сборки?

update

Может быть, мне действительно нужно объединить всю логику Persitence / Domain водна сборка (тот же подход, который использовался в образце NerdDinner), а затем создание разных «объектов просмотра» на уровне представления, которые являются денормализованными версиями моих сущностей Linq-2-Sql?

Answer 1

Я стараюсь сохранять свои доменные объекты настолько невежественными, насколько позволяет технология, которую я использую.Что касается LINQ to SQL, я следовал подходу, изложенному Ианом Купером (см. Невежество с LINQ to SQL , Архитектура приложений LINQ to SQL, часть 5 и Архитектура LINQ to SQL Applications, часть 6 ).По сути, вы можете вручную кодировать свои доменные объекты и подключать их к LINQ to SQL, используя sqlmetal, чтобы сгенерировать сопоставление с базой данных, которое затем вы можете вручную редактировать в соответствии со своими потребностями.Это сработало довольно хорошо для меня.

У Джереми Миллера есть хорошая статья на тему невежественности в журнале MSDN.См. Шаблон единицы работы и невежество постоянства .

Мой нынешний подход таков: две библиотеки классов: одна с Linq-2-Sql DBML + частичные классы, а вторая снабор классов, которые имеют только автоматически сгенерированные свойства, а затем класс «repo», который управляет получением данных из сборки Linq и преобразованием их в IQueryable<T>.

Мне это не нравитсяподход.Это так сильно нарушает СУХОЙ.

Answer 2

Вы видели AutoMapper ? Если вы загляните в блог , вы увидите описанную вами ситуацию.