Использование DTO и BOs

Question

Одна часть вопроса для меня о DTOs/BOs - о том, когда передавать/возвращать DTO и когда передавать/возвращать BOs.

Моя реакция кишки говорит мне всегда отображать NHibernate в DTO, а не BOs, и всегда передавать/возвращать DTO. Тогда всякий раз, когда мне нужно было выполнять бизнес-логику, я бы превратил мой DTO в BO.

Способ, которым я бы это сделал, заключается в том, что у моего BO будет конструктор, который принимает параметр, который является типом моего интерфейса (который определяет необходимые поля/свойства), который оба моих DTO и BO реализуют как единственные аргумент.

Тогда я смог бы создать свой BO, передав его DTO в конструкторе (поскольку оба с реализацией имеют тот же интерфейс, оба они имеют одинаковые свойства), а затем смогут выполнять мою бизнес-логику с помощью этого BO , У меня также был бы способ конвертировать BO в DTO.

Однако я также видел, где люди, похоже, работают только с BOs и работают только с DTO в фоновом режиме, где пользователю, похоже, нет DTO.

Какие преимущества/недостатки существуют с этой архитектурой и всегда с использованием BO?

Должен ли я всегда передавать/возвращать либо DTO, либо BOs, либо смешивать и сопоставлять (похоже, смешивание и сопоставление могут запутаться)?

Answer 1

Возможно, вы найдете это: http://automapper.codeplex.com/ полезно тоже.

Answer 2

Это зависит от того, чего вы хотите достичь. Я могу рассказать вам, что я делаю сам. У меня есть оба DTO и BO, отображаемые в NHibernate, но DTO отображаются как неизменные, поэтому я не случайно обновляю базу данных без использования BO.

Все запросы, доступные в WebServices, возвращают/принимают DTO.

При обновлении с помощью DTO я выполняю UnitOfWork, где я загружаю BO, обновляю свойства из DTO и сохраняю его снова, если он все еще действителен.

На клиенте я создаю BO из DTO (AutoMapper определенно является допустимым выбором здесь), когда клиент должен его модифицировать. У BO есть ctor, который принимает все аргументы, чтобы создать его так же, как NHibernate.

Преимущества: * Полный контроль над количеством данных, проходящих через провод (DTO обычно сплющиваются, поэтому при первом вызове отправляется только идентификатор связанных классов). * Мне не нужно иметь одинаковые свойства как в * Я могу смешивать и сопоставлять ленивую загрузку, как я хочу * Я могу использовать скалярные запросы и другие рассчитанные свойства в DTO без их создания в BO. * У меня может быть несколько разных DTO на BO для разных сценариев.

Так что, я думаю, что было бы квалифицировать как смешивание и согласования, но четкими указаниями, где я делаю который :-)

Надеется, что это помогает.

Answer 3

Я знаю, что это довольно старый вопрос, но позвольте мне дать мои «десять центов» по ​​этому вопросу.

При работе с любым проектом MVC (даже с Entity Framework или NHibernate) я использую POCO для сохранения и DTO/ViewModels для промежуточной работы из-за сглаженного поведения, меньше данных на провод и, наконец, (но не менее ценные), они никак не раскрывают отношения между объектами.

Я знаю, это может звучать как «серебряная пуля», но, по крайней мере, это работает для меня некоторое время.

(простите некоторые английские ошибки =))