DDD, Aggregate root без ORM, как сохранять?

Можно на примере выше, вот в order мы добавили новый item, как его сохранить\обновить в репозитории? (без orm)

Вы хотите чтобы я написал кусок SQL-я, который положит ваш Order в базу?

Поясню =).. Например, OrderRepository.GetById(666) вернул вам Order со всеми его Items, потом вы в ордер добавили новый айтем order.AddItem(item). Как вы все это дело потом сохраните в базу?

Без ORM можно сделать из Order ActiveRecord, т.е. захренячить SQL в модель, но это очень плохая и печальная идея. Можно пойти другим путем и забыть про наш ActiveRecord и Order с его AddItem в принципе. В случаи когда нам понадобиться добавить новый Item для Order, то мы просто добавим Item с ключем от Order в базу напрямую(без order.AddItem(item)). В таком случаи мы рассинхринизируем базу и клиент, но если нам это уже не важно, то пофиг, если важно, то мы всегда можем достать оновленый Order из базы заново, ну либо извращаться с AddItem.

В данной ситуации работать с ORM на много проще, они создавались для этого.

Станислав Силин,

В случаи когда нам понадобиться добавить новый Item для Order, то мы просто добавим Item с ключем от Order в базу напрямую(без order.AddItem(item)).

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

ddd329,

сумма заказа не должна превышать определенный лимит...

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

обновлять АГРЕГАТ полностью в Базе Данных

нам никак не поможет(и не возможно в принципе).

А если вы предполагаете, что эта провекра будет внутри order.AddItem(item), где order часть DAL слоя, то вы сами себе стреляете в ногу...

нам никак не поможет(и не возможно в принципе).

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

Станислав Силин,

Предметная логика, конечно я считаю, должна быть реализована в Domain Layer, а не в Базе Данных. Если два пользователя одновременно редактируют АГРЕГАТ, один добавил позицию, и второй добавил позицию в заказ, и если просто две записи добавились напрямую(как вы пишите) в БД, то бизнес-правила могут быть нарушены.

ddd329, ну так я ж пишу

но если нам это уже не важно, то пофиг, если важно, то мы всегда можем достать оновленый Order из базы заново

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

ddd329, типа order.AddItem(item) вас от этого спасет.

в том то и дело, как реализовать метод Update в OrderRepository для Order (пример выше), пробегать по всей коллекции Items и не существующих добавлять а измененные item обновлять?

red_gorilla: ORM умеет следить за изменением состояния как корневого, так и вложенных entity.
Как это реализовали в EF, NHiber и т.д. можно я думаю посмотреть в исходниках.
Но это вообще хороший вопрос, как best practices, сделать такую штуку. И делать оптимальный UPDATE только изменившихся полей и т.д.

Я бы не заморачивался и взял EF.

Просто бывают ситуации когда EF, NHiber не подходит из за медленности работы