Хранилища и постоянное невежество снова

Question

Вот где я до.

У меня есть общий класс репозитория Repository<TKey, TValue>. У него есть обычные методы репозитория.

Каждый репозиторий занимает IContext<TKey, TValue> в своем конструкторе, который обеспечивает постоянство для репозитория.

У меня есть специализированные репозитории, которые состоят из общего репозитория, а затем методов, адаптированных к действиям репозитория, которые являются специфическими для специализированного объекта. Поэтому, если бы у меня был специализированный репозиторий для объектов Kitten, у него были бы методы для ClimbTree (возможно, с использованием объекта дерева), но не метод BuryBone (Bone bone). Суть, которую я подчеркиваю, заключается в том, что она создает связь между котенком и его деревом, которое необходимо сохранить. void CleanWhiskers() может быть более простым примером. Это устанавливает чистоту усов котят.

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

Я начал с некрасивых методов в хранилище для создания дочерних объектов. Таким образом, хранилище Kitten будет иметь метод CreateFurBall(), который добавит объект FurBall в коллекцию FurBall котенка и добавит Furball в хранилище FurBall для сохранения (фактически тот же объект).

Теперь я перешел на систему, где у меня есть что-то похожее на ObservableCollection, которая уведомляет свой родительский репозиторий при добавлении POCO. Так что я могу просто создать POCO Furball и добавить его в коллекцию, которая затем будет автоматически зарегистрирована в репозитории FURBOL.

Прежде всего, я буду реализовывать nHibernate в контекстах, я думаю, что это довольно хорошо. Это действительно открытый вопрос, для любого, кто был на этом пути раньше, вы можете увидеть что-нибудь, что заставляет вас «ОСТАНОВИТЬСЯ !!»

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

IQueryable<entity> GetEntities();

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

IEnumerable<entity> GetEntities_byPage(int page);

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

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

Answer 4

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

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