2013-09-18 2 views
2

Я разрабатываю бэкэнд для новой системы, и я попытаюсь использовать DDD. Я определил свои объекты DDD в Core-проекте, и я прочитал эти объекты с уровня сохранения, используя шаблон репозитория.DDD. Прочитать непосредственно из репозитория или использовать сущность?

Мне нужен сервис WCF, чтобы мои клиенты могли получить доступ к серверу. К и из этой службы WCF я отправляю/получаю DTO.

Допустим, у меня типичный сценарий Order, Orderrows. В моей службе WCF объявляю функцию

IEnumerable<DTO.OrderRows> GetOrderRowsForOrder(DTO.Order o) 

Мне нужен совет, как реализовать этот метод. У меня есть два разных варианта.

  1. Используйте мой домен-объект, чтобы прочитать порядок.

    Core.Order order = _orderRepository.GetById(o.Id); 
    IEnumerable<Core.OrderRow> orderRows = order.GetOrderRows(); 
    IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO()); 
    
    return dtos; 
    
  2. Непосредственно используйте репозиторий для считывания ордеров.

    IEnumerable<Core.OrderRow> orderRows = _orderRowsRepository.GetOrderRowsForOrder(o.Id); 
    IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO()); 
    
    return dtos; 
    

Для меня выбор 1 выглядит более 'объектно-ориентированный', но выбор нет. 2 выглядит проще и эффективнее.

Вопрос, какой из них использовать при использовании DDD? Уместно ли здесь использовать DDD?

(Это, конечно, простой пример, но что, если мне нужно, чтобы получить orderrows для списка заказов?)

ответ

4

Это зависит от ваших совокупных корней:

  1. Если заказ представляет собой совокупность root, который содержит строки порядка, то Order должен иметь свойство OrderRows, которое всегда будет заполняться при чтении заказа. Таким образом, при получении строк заказа из заказа не будет «неэффективности», потому что они уже будут в памяти.
  2. Если OrderRow является совокупным корнем в себе, тогда будет нетOrderRows или GetOrderRows метод на Order. Вместо этого вы должны использовать OrderRowsRepository, чтобы получить все строки заказов для заказа, аналогичные тому, что вы указали в своем втором примере.
2

Я использую номер 2, но в последнее время изменил свое мнение больше, чем число 1. Причина этого в том, что если вы используете 2, хранилища будут в конечном итоге завалены всеми видами методов для запроса хранилища вещи, о которых объект домена (сущность) должен знать и быть в состоянии ответить. Своими словами; это больше ориентировано на объект.

+1

Поскольку контекст явно разработан под управлением домена, я не согласен с вашим ответом. Определение Агрегатных Корней является решающим фактором здесь. –

+0

Я читал об общих корнях, и это имеет смысл. Но как насчет моего второго вопроса, подходит ли DDD для использования здесь? –

+2

@ErikZ: Это действительно зависит от вашего приложения. DDD - это не то, что вы применяете к небольшой части вашего приложения. Если вы решите использовать DDD, этот выбор управляет полной архитектурой вашей модели домена и окружающего кода. –

0

Предполагая Core.Order ваш совокупный корень, вы уже будете иметь свойство в нем OrderRows, таких как

public class Order 
{ 
    public IEnumerable<Core.OrderRows> Rows { get; set; } 

} 

Так выбор # 1 с небольшим изменением, чтобы вызвать свойство Rows, а не запрашивая с GetOrderRows() будет уместным.

Core.Order order = _orderRepository.GetById(o.Id); 
IEnumerable<Core.OrderRow> orderRows = order.Rows; 
IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO()); 

return dtos; 
Смежные вопросы