Результаты поиска

DDD утверждает, что вы должны получать доступ к сущностям только через их совокупный корень. Так скажем, например, что у вас есть совокупный корень X, который потенциально имеет много дочерних сущностей Y. Теперь, для некоторого сценария, вы действительно заботитесь только о подмножестве этих объектов Y за один раз (возможно, вы показываете их в списке подкачки или что-то еще).

Это OK для реализации репозитория, так что в таких сценариях он возвращает неполный агрегат? То есть. объект X, коллекция Ys которого содержит только интересующие нас экземпляры Y, а не все из них? Это может, например, привести к тому, что методы на X, которые выполняют некоторые вычисления с участием Ys, не будут вести себя так, как ожидалось.

Возможно, это указывает на то, что рассматриваемая сущность Y должна рассматриваться как повышенная до агрегированного корня?

Моя текущая идея (в C#)-использовать отложенное выполнение LINQ, чтобы мой объект X имел IQueryable для представления его отношений с Y. Таким образом, я могу иметь прозрачную ленивую загрузку с фильтрацией... Но заставить это работать с ORM (Linq до Sql в моем случае) может быть немного сложно.

Есть еще умные идеи?

Типичный сценарий. Мы используем старой школы XML internally web-сервисов для обмена данными между серверами фермы и нескольких распределенных и локальных клиентов. Никакие третьи лица не участвуют, только наши приложения, используемые нами и нашими клиентами.

В настоящее время мы размышляем о переходе от модели XML WS к модели WCF/object-based и экспериментируем с различными подходами. Один из них включает в себя передачу объектов домена / агрегатов непосредственно по проводу, возможно, вызывая атрибуты DataContract на них.

Используя IExtensibleDataObject и DataContract с помощью свойства Order на DataMembers, мы должны быть в состоянии справиться с простыми проблемами управления версиями свойств (помните, что мы контролируем всех клиентов и можем легко принудительно обновить их).

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

Почему? Есть ли еще причина для этого? Мы используем одну и ту же модель домена на стороне сервера и на стороне клиента, конечно, предварительно заполняя коллекции и т. д. только в том случае, когда это считается правильным, и свойства коллекции "necessary." используют принцип Service locator и IoC для вызова либо NHibernate-based "service" для прямой выборки данных (на стороне сервера), либо клиента WCF "service" на стороне клиента для связи с фермой серверов WCF .

Итак-почему мы должны использовать DTOs ?