Должны ли репозитории быть одновременно загружающими и сохраняющими сущностями?

Question

В моем дизайне есть классы репозитория, которые получают сущности из базы данных (как это так, что это не имеет значения).Но чтобы сохранить сущности обратно в базу данных, имеет ли смысл делать это и в хранилище?Или имеет смысл создать другой класс (например, UnitOfWork) и возложить на него ответственность за сохранение содержимого, приняв его с помощью Entities, и вызвав save(), чтобы он сказал, что нужно идти вперед и делать свою магию

Answer 1

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

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

Конечновы можете иметь отдельные классы Reader / Writer-helper, если это уместно в вашем проекте.Но, как видно из бизнес-уровня, единственным путем к постоянству должен быть репозиторий ...

HTH!Томас

Answer 2

Фаулер говорит , что API хранилища должен имитировать коллекцию:

Репозиторий является посредником между доменом и слоями отображения данных, действуя как коллекция объектов домена в памяти .

Answer 3

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

Хранилище вполне может использовать ваш класс UnitOfWork и может нуждаться в предоставлении методов BeginUow и Commit.