Репозитории и игнорирование постоянства снова

Нельсон прав.

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

Когда приложение хочет добавить пушистого комка к котенку, пушистый комок должен находиться рядом с котенком через Kitten.CreateFurBall(). Здесь я делаю предположение, что пушистый комок принадлежит котенку, а пушистый комок не является общим для других котят. Если пушистый комок достаточно сложен, вам может понадобиться абстрагировать его создание от FurballFactory, на которую котенок имеет ленивую ссылку.

Что касается создания объекта Kitten, вероятно, лучше всего с этим справиться, имея ссылку на KittenFactory в вашем KittenRepository, которая принимает dto для котенка и создает из него котенка.

Самая большая проблема, которую вы продемонстрировали, связана с методом Kitten.BuryBone(Bonebone). Котята не зарывают кости. Собаки делают.

Я должен был подумать, что такие методы, как ClimbTree(), BuryBone(), CreateFurBall() и CleanWhiskers(), относятся к объектам домена, а не к репозиториям.

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

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

Шаблон репозитория великолепен, особенно когда вы размещаете их все за интерфейсами, чтобы их можно было легко заменить. Я создаю репозиторий для каждой сущности. BrokenGlass прав в том, что методы обычно очень общие и не содержат ничего, кроме логики персистентности. Обычно я немного менее строг с типом логики, которая превращает его в репозиторий. Например, некоторые люди считают греховным помещать логику подкачки в репозиторий, но я с этим не согласен.

Я довольно часто использую Entity Framework и LINQ to SQL. Чтобы выводить из них результаты, мне нужно, чтобы LINQ работал с IQueryable<entity>, чтобы разбиение по страницам происходило на уровне базы данных. Мне не нравится выставлять IQueryable за пределы моего репозитория. Потому что что, если когда-нибудь мой репозиторий нужно будет переписать, и хранилище данных больше не сможет использовать IQueryable? Поэтому вместо того, чтобы возвращать это из моего репозитория:

IQueryable<entity> GetEntities();

... и пейджинг результатов в моем контроллере или в другом месте моего приложения. Вместо этого я делаю это:

IEnumerable<entity> GetEntities_byPage(int page);

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

Я думаю, что ваши репозитории должны возвращать некоторые довольно адаптированные данные, а не просто дамп необработанных данных, который ваш контроллер должен очистить (обычно после загрузки всего в память, YECK!).

В прошлом я использовал шаблон репозитория в качестве очень тонкого посредника между поставщиком постоянства и объектами данных — каждый репозиторий содержит только очень общие методы (т. е. обычно Add/Update/Delete).

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