DDD (java) Совокупные корни и постоянство

Я создаю приложение, которое будет использовать таблицы разных размеров, в то время как я работал над проектом, помеченным как 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);
}

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


person nevermore    schedule 24.02.2012    source источник


Ответы (1)


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

Объектно-реляционные модели поведения: единица работы (184), карта идентичности (195), отложенная загрузка (200)

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

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

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

person Dmitry    schedule 24.02.2012
comment
То, что вы говорите, имеет большой смысл, я думаю, что создание всего ORM - это слишком много, учитывая, что это не такой уж большой проект для начала, хотя я знаю, что это не совсем ддд, вы предвидите какие-либо проблемы, связанные с выполнением просто вместо этого сопоставление 1-1 и позволить «репозиториям» (которые, очевидно, не будут репозиториями) просто сопоставлять непосредственно с базой данных? (в основном просто прославил дао) - person nevermore; 25.02.2012
comment
Я думаю, что этот подход будет работать, но его трудно назвать «управляемым доменом», он будет управляться данными. - person Dmitry; 25.02.2012
comment
Правда, я бы не стал называть это ддд, но если это мешает мне перекатывать собственную форму, я соглашусь на это. Честно говоря, я просто искал достойный способ получить доступ к базе данных, и из того, что я читал об активной записи, он казался слишком ограничивающим для наших целей. Как я уже сказал, раньше я работал над проектами semi-ddd, и мне нравится, как вы можете смоделировать свой домен для своей проблемы, но для этого проекта кажется, что это будет слишком много работы при слишком малой пользе. Еще раз спасибо за всю помощь, я очень ценю это. - person nevermore; 26.02.2012
comment
Как бы то ни было, в мире .NET в области «Micro ORM» происходит много движений. Должны быть альтернативы Java: эквивалент микроформы - person Dmitry; 27.02.2012