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

Question

Для меня одна область вопроса о DTO / BO - это когда передавать / возвращать DTO и когда передавать / возвращать BO.

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

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

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

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

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

Должен ли я всегда передавать / возвращать либо DTO, либо BO, либо смешивать и сопоставлять (кажется, что смешивание и сопоставление могут вызвать путаницу)

Answer 1

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

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

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

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

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

Итак, я предполагаю, что это будет квалифицироваться как смешивание и сопоставление, но с четкими указаниями, где я делаю, что:

Надеюсь, это поможет.

Answer 2

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

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

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

Answer 3

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