Связывание DropdownList в дизайне, управляемом доменом

Question

Я создал модель предметной области и определил сущности, объекты значений, службы и т. Д.Теперь мой запрос заключается в том, что у меня есть объект под названием «Компания», который имеет около 20+ атрибутов, и я хочу связать элемент управления выпадающего списка на одной из моих страниц, для которого требуются только два атрибута, т.е. company.Name, company.Id.Почему я должен использовать такую ​​тяжелую сущность, имеющую более 20 атрибутов, чтобы связать выпадающий список.

Есть ли способ справиться с этим, учитывая также производительность.

Заранее спасибо.

Answer 1

Вопрос не столько связан с DDD. Речь идет о производительности.

Как и я - мне все равно, есть ли 1 или 20 атрибутов, если эти атрибуты не взяты из отдельных таблиц. Нет большой разницы, если select выбирает 1 или 20 полей, но есть заметная разница, если select начинает присоединяться к другим таблицам, и есть заметная разница, когда select n + 1 .

Итак - когда я получаю список Company через свой ORM, чтобы создать список выбора, он достаточно умен, чтобы запускать sql select только над Company таблицей и лениво загружать другие вещи, если они необходимы (которые не в данном конкретном случае).

К счастью, я не занимаюсь разработкой систем, требующих сверхвысокой производительности, поэтому мне все равно, занимает ли это 1 или 20 полей. Если бы я это сделал - я сомневаюсь, что в любом случае я бы использовал ORM.

---

Для некоторых других механизмов персистентности - это может вообще не быть проблемой. Например. - если вы используете базу данных документов, вы можете хранить / извлекать весь агрегат в одном документе, потому что это меньше схемы. Производительность снижается резко.

Answer 2

Создайте общую модель ключ / значение и предоставьте метод из вашего сервиса, который возвращает название вашей компании / список идентификаторов компании. Это аналогично другим данным типа значений, для которых вы запрашиваете вашу БД (например, код состояния / идентификатор состояния).

Answer 3

В этом сценарии я хотел бы рассмотреть службу справочных данных, возвращающую упрощенные представления модели предметной области, или, предпочтительно (для простоты), реализовать кэширование.В любом случае, помните, что это действительно то, о чем вам стоит беспокоиться после того, как вы определили производительность архитектуры как проблему.

Answer 4

DDD не о производительности.С DDD вы должны оперировать «агрегатами» - согласованным набором связанных сущностей.Агрегаты должны быть загружены из базы данных в память приложения.Необычные запросы (фактически все запросы) рассматриваются в DDD как «Отчетность» и должны выполняться отдельными механизмами, такими как базы данных без кавычек.

http://devlicio.us/blogs/casey/archive/2009/02/13/ddd-command-query-separation-as-an-architectural-concept.aspx

это чушь собачья.Не используйте DDD.

Пишите запросы, когда вам нужно.Используйте Linq для составления-разложения запросов.