DDD - Совокупные корни и создание поведенческих объектов

Question

DDD - Совокупные корни и создание поведенческих объектов

Единственная база данных я знаю это, делает это - SQLite, в зависимости от настроек, которые Вы настраиваете с PRAGMA full_column_names и PRAGMA short_column_names. См. http://www.sqlite.org/pragma.html

Иначе все, что я могу рекомендовать, должен выбрать столбцы в наборе результатов порядковым положением, а не именем столбца, если это - слишком много проблемы Вам для введения имен столбцов в запросе.

Это - хороший пример того, почему это - плохая практика для использования SELECT * - потому что в конечном счете у Вас будет потребность вывести все имена столбцов так или иначе.

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

7

domain-driven-design

задан 19 October 2009 в 06:11

2 ответа

Другие вопросы по тегам:

domain-driven-design

Похожие вопросы:

score 5 · Answer 1

У вас правильная концепция агрегированных корней, но ваши два варианта действительно касаются реализации - и оба действительны.

Вариант 1

Плюсы: интерфейс вашей сущности остается довольно чисто.
Минусы: метод Добавить требует логики для связать отношения между Сообщение и Комментарий (думаю NHibernate). Вы могли бы создать строго типизированная коллекция и переопределите метод Add, или вы можете вернуть события в Сообщение в handle.

Вариант 2

Плюсы: Методы Добавить / Удалить предоставляют удобное место для логики соединения.
Минусы: По мере роста количества свойств коллекции может произойти взрыв из Добавить / удалить методов. Кроме того, открытые коллекции должны быть ReadOnly, чтобы гарантировать, что Комментарии всегда добавляются / удаляются с помощью специальных методов.

Я предпочитаю вариант 1 - я использую общие коллекции, которые вызывают события. ИМХО, это кажется более естественным, и другим разработчикам легче кодировать. Хотя другие участники SO выразили иное.

Когда мы говорим о поведении , мы говорим о присоединении логики к Сущности. Например. если вы хотите прекратить добавление комментариев через 5 дней,

score 3 · Answer 2

Я бы выбрал второй вариант.

Во-первых, мне нравится отображать коллекции как IEnumerable. Таким образом, будет невозможно так легко манипулировать этим списком и защитить его от нежелательного поведения. Регулярно проверяю метод добавления и удаления, есть ли объект в списке или нет.

Во-вторых, он инкапсулирован, и я могу добавить логику позже.

Наконец, вы можете создать цепочку методов с этим методом, вернув сам себя:

var post = new Post()
    .AddComment("My First comment")
    .AddComment("My Second comment")
    .Publish();

Если метод AddX сильно раздувает вашу сущность, то это можно сделать с перегрузкой:

var post = new Post()
    .Add(new Comment("My First comment"))
    .Add(new Comment("My Second comment"))
    .Publish();