Совместное использование контента между бизнес-объектами и DTO - PullRequest
Новая
       7

Совместное использование контента между бизнес-объектами и DTO

2 голосов
/ 28 июня 2010

All

Мой типичный подход для службы WCF среднего размера будет выглядеть примерно так:

  1. Определить интерфейс, используя контракты данных WCF и сервисные операции. Контракты на передачу данных будут представлять собой DOC POCO без CRUD или логики домена.
  2. Моделирование домена с использованием полнофункциональных бизнес-объектов.
  3. Предоставить некоторый механизм для перехода от DTO к BO и наоборот (см. Связанный вопрос: Шаблон / стратегия создания BO из DTO )

Теперь большую часть времени (если не всегда) содержимое данных бизнес-объекта и DTO практически одинаково. Как люди относятся к созданию библиотеки объектов контента, которые совместно используются BO и DTO. Например. если бы у нас были WibbleDTO и WibbleBO, мы могли бы создать интерфейс IWibbleContent, который оба реализуют. Мы могли бы даже создать интерфейс IWibbleContent и класс WibbleContent, на который ссылаются как DTO, так и BO.

Итак, конкретные вопросы:

  1. Вы когда-нибудь разделяли интерфейсы контента / данных между вашими DTO и BO?
  2. Вы когда-нибудь разделяли классы контента данных между вашими DTO и BO?

Если нет, то, я думаю, согласно моему связанному вопросу, у нас остается утомительное копирование кода, или мы используем что-то вроде AutoMapper.

Любые комментарии приветствуются.

Ответы [ 2 ]

2 голосов
/ 28 июня 2010

Мы используем очень похожий подход, который вы описали в DTO и BO.

У нас редко бывают общие интерфейсы, либо они очень простые (например, интерфейс для получения BusinessId), либо они специфичны для определенной реализации, например. расчет, который может быть сделан на клиенте или на сервере.

На самом деле мы просто копируем свойства. Они обычно достаточно тривиальны, поэтому не стоит делиться кодом.

В конце, больше кода отличается от аналогичного.

  • У нас есть много атрибутов в этих классах, которые почти никогда не совпадают.
  • Большинство свойств реализованы как get; set; на сервере, но с OnPropertyChangedEvent на клиенте, что требует использования явных полей.
  • Мы не разделяем много кода на стороне клиента и сервера. Таким образом, нет необходимости в общих интерфейсах.

Даже если многие свойства одинаковы в обоих классах, на самом деле разделять не так много.

0 голосов
/ 28 июня 2010

Я обычно создаю POCO и использую их на всех своих уровнях - доступ к данным для бизнеса через пользовательский интерфейс. На бизнес-уровне у меня есть менеджеры, у которых POCO перемещаются взад и вперед. Мы рассмотрим Entity Framework и / или NHibernate, поэтому я не уверен, куда это нас приведет.

Да, мы пишем какой-то дополнительный код, но сохраняем все скудным и подлым. Мы используем MVC для нашего пользовательского интерфейса, который для меня был находкой по сравнению с большинством веб-форм, я никогда не вернусь. Прямо сейчас наша битва заключается в том, чтобы отправлять JSON обратным вызовам ajax или использовать частичные представления, последнее - то, что мы делаем большую часть времени.

Мы правы? Может и нет, но у нас это работает. Так много вариантов, так мало времени.

...