Есть ли преимущество в использовании DTO вместо общей ссылки на сущности в общей сборке?

Question

Я пытаюсь получить четкий окончательный ответ на вопрос, который меня долго сводил с ума.

Обычно выражается, что BLL должен содержать Business Logic и Business Objects (BO) и иметь ссылку на DAL. DAL, с другой стороны, не может иметь ссылку на BLL, поэтому он не может принимать BO в качестве аргументов или возвращать BO в качестве возвращаемых значений.

Самый традиционный ответ на эту проблему:

a) Принять простые параметры и вернуть (желательно типизированные) наборы данных и таблицы данных для возврата данных: пространство имен DAL { общедоступный класс Контакты public DataTable GetContacts () {...} Публичное обновлениеКонтакты (DataTable contacts) {...}

b) Вторым наиболее рекомендуемым решением является определение временных, сериализуемых объектов передачи данных (DTO) (иногда называемых объектами значений (VO)), которые имеют только поля и свойства, не имеют методов и используются только для краткой передачи данные возвращаются в слой BLL, где они используются для заполнения новых BO, после чего они отбрасываются.

в) Используйте общую третью сборку (например, называемую Entities.dll), которая определяет BO и на которую ссылаются все 3 уровня: пользовательский интерфейс, BLL и DAL.

Вариант а) требует наименьшего количества работы для реализации (не нужно создавать другую сборку), поэтому и так часто предлагается, но в DataTables есть дополнительная разводка, которая не требуется для простых операций.

Все же очень неясно, какой из б) или в) лучше ...

Я вижу, что б) предлагалось иногда, и почти никогда не в), хотя в) кажется самым простым из двух.

Что мне не хватает? Почему в) так редко предлагается, даже если он кажется логически самым простым, и почему а) предлагается, когда он явно не подходит для всех сценариев (например, возврат отдельных объектов)?

Спасибо!

Answer 1

Ну, я почти не вижу (б) занятых на практике. Я использую подход, описанный в (c), большую часть времени (другой раз, когда я даже не разделяю между BLL / DAL или вообще не имею модель предметной области). В конце концов, бизнес-компоненты и компоненты данных, как правило, физически находятся в одном месте, поэтому для этих двух компаний очень просто разделить BO. Фактически, такие фреймворки, как Hibernate, Entity Framework, Linq2Sql и т. Д., Фактически поощряют (c), позволяя выполнять ORM для сложной модели предметной области.

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

Answer 2

Я не удивлюсь, если (с) будет довольно распространенным явлением. И если ваш BLL и пользовательский интерфейс находятся на другом сервере, вы также можете передавать объекты по проводам, если вы используете WCF. Посмотрите на этот пример, как выполнить сериализацию сущностей здесь [zip] и вот ссылка на страницу загрузки . Этот пост также может помочь с сериализацией с WCF

Answer 3

ДОБАВЛЕНИЕ к исходному Вопросу:

Я думаю (после первого ответа, Буу Нгуен, что следующий эталонный образец вполне приемлем, и, возможно, даже рекомендуется с LINQ и т. Д .:

BLL > 

 v    Business Entities Layer (BEL)

DAL >

Если BLL и DAL находятся на разных уровнях, а BLL связывается с DAL через WCF ...? В этом случае это не будет работать (бизнес-сущности, возвращенные DAL через WCF, будут сериализованы, а на стороне BLL будут десериализованы в прокси исходных BE ... и не сопоставлены обратно с Сами по себе BE или это явно неверно, и вышеупомянутая эталонная модель будет работать, когда BLL и DAL находятся на одном уровне, а также на разных уровнях?

ADDENDUM # 2: Нашел интересную ссылку о том, почему на самом деле хорошо использовать внешнюю сборку для BO. Он заявляет , что «Это нарушение правила, согласно которому слой должен знать только о слое сразу ниже, но база данных, которая определяет имена столбцов, не находится непосредственно под BLL, а ниже DAL. Наборы данных не защищают вас от базы данных, и поэтому я думаю, что они не правы. Лучшим решением будет использование строго типизированных объектов, определенных в отдельном проекте. Так, например, в DTO будет класс Teacher с именем свойство, но без метода оценки. "