ASP.NET, LLBLGen и Spring.Net с сервисным уровнем

Question

Итак, я думаю об использовании LLBLGen Pro и Spring.Net в этом проекте asp.net с использованием сервисного уровня для отделения бизнес-логики от хранилища данных. Я также рассматриваю возможность использования PONOS в UI Layer, теперь мой вопрос:

Должен ли я отображать объекты Entity LLBLGen в Ponos на уровне данных или на уровне обслуживания? Если я сделаю это на уровне данных, то потеряю всю их богатую функциональность на уровне обслуживания. Или я должен просто пропустить сопоставление с Ponos и использовать сущности LLBLGen? Если потом будет сложнее проверить это правильно?

Может кто-нибудь дать мне плюсы и минусы обоих подходов?

Спасибо

Answer 1

Преимущество использования LLBLGen Entities без сопоставления состоит в том, что вы получаете сущности, сгенерированные прямо из вашей схемы базы данных (или даже без схемы базы данных в LLBL 3.x), так что вы можете иметь очень удобную модель сущности в случае минут. Недостатком является то, что ваши сущности наследуются от классов инфраструктуры LLBL, что затрудняет их обогащение поведением / бизнес-логикой. Если вы обычно разрабатываете свою бизнес-логику как набор сервисов, это не представляет проблемы.

Я не рассматриваю тестирование как проблему в этом сценарии, поскольку я обычно рассматриваю сущности как "анемичные" объекты данных, и я обычно не высмеиваю такие объекты (нет реальной причины для этого).

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

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