Как отображения Entity Framework Code-First отражают дизайн, управляемый доменом? - PullRequest
7 голосов
/ 29 января 2011

Я хочу использовать Entity Framework Code-first для нового проекта.Поэтому я решил провести небольшое исследование и создать демо-версию, чтобы понять, как это происходит.В связи с этим у меня есть серьезная проблема или, возможно, еще кое-что, что мне не понятно, в том числе способ отображения кода структуры сущности на уровне сущности и дизайн, управляемый доменом.

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

Это нормально, но отображение Entity Framework Code-First, похоже, работает как реляционный путь между сущностями.Так как оба могут сосуществовать?

В качестве примера (Мышление на стороне разработки, ориентированной на домен):

Journal содержит JournalEnty содержит задач , задач , заметок

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

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

Нопроблема приходит сюда .. как это может отразить отображение кода первого кода в Entity Framework?С интуитивной точки зрения мы бы сказали, что журнал содержит запись журнала и что запись журнала содержит заметки, проблемы и задачи.Но с точки зрения DDD это, вероятно, не так.Поправьте меня, если я ошибаюсь, но код сначала работает как реляционная база данных.

Итак, как бы мы отобразили приведенный выше пример в первом коде?

Большое спасибо.

1 Ответ

2 голосов
/ 31 января 2011


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

Вот ScottGu сообщение в блоге об этом.

...