DDD (Java) Совокупные корни и постоянство - PullRequest
2 голосов
/ 25 февраля 2012

Я создаю приложение, которое будет использовать таблицы разных размеров, в то время как я работал над проектом, помеченным DDD, прежде чем он действительно не получил правильную часть персистентности, и, таким образом, я оставил исследования вещей. Одна вещь, которую я не до конца понимаю и не могу найти конкретных примеров, это как сохранить «детей» от совокупных корней. Я работаю без ORM (просто старый DAO), который довольно сложно найти примеры (на самом деле это проект для Uni, который специфичен для БД, поэтому мне «не разрешено» использовать ORM, хотя я ценю это было бы намного проще, я просто не могу). Я искал конкретные примеры на stackoverflow, но, похоже, ничто не описывает мою конкретную проблему.

Я сомневаюсь, что приведенный ниже код верен

public DataTable getTableByID(int id) throws AccessException{
    DataTable result = this.context.TableContext().getEntityByID(id);
    result.setColumns(getColumnsByTableID(id));     
    return result;
}

private List<DataColumn> getColumnsByTableID(int id){
    Object[] arguments = { id };
    return this.context.ColumnContext().getUnitsWhere("TABLE_ID = ?", arguments);
}

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

1 Ответ

4 голосов
/ 25 февраля 2012

DDD - это набор рекомендаций, которые не зависят от технологии. Однако проектам, в которых доменные объекты являются долгоживущими (т.е. перезапускается процесс выживания), нужна какая-то инфраструктура для решения проблем с постоянством, ORM, если вы используете реляционную базу данных. В таких случаях ORM является обязательным условием, поскольку вам необходимо, чтобы модель вашего домена была максимально независимой от настойчивости. Вы не хотите, чтобы постоянные проблемы «кровоточили» в вашей доменной модели. Теперь вопрос заключается в том, используете ли вы существующий ORM или пытаетесь создать свой собственный. И похоже, что вы пытаетесь создать свой, понимаете ли вы это или нет. Строительство ORM - это большое начинание, собственный проект. Я не уверен, насколько реально ожидать, что один человек создаст ORM и само приложение в разумные сроки. В любом случае, у Мартина Фаулера есть набор шаблонов , на которые вы, возможно, захотите посмотреть:

Объектно-реляционные поведенческие паттерны: единица работы (184), идентичность Карта (195), Lazy Load (200)

Объектно-реляционные структурные структуры: поле идентичности (216), чужое Отображение клавиш (236), Сопоставление таблиц ассоциаций (248), Зависимое сопоставление (262), Встроенное значение (268), Сериализированный большой объект (272), Одна таблица Наследование (278), наследование таблицы классов (285), бетонный стол Наследование (293), Картографирование наследования (302).

Шаблоны отображения объектно-реляционных метаданных: отображение метаданных (306), Объект запроса (316), Репозиторий (322).

Для вашей конкретной проблемы посмотрите Identity Map и Data Mapper . Вы также можете посмотреть на источники гибернации для подсказок реализации, но это может быть немного подавляющим.

...