Архитектурные проблемы: свободный NHibernate, шаблон репозитория и ASP.NET MVC - PullRequest
6 голосов
/ 16 февраля 2011

Я только что начал новый проект и, естественно, решил использовать много новых технологий.

Я использую (Свободно) NHibernate, ASP.NET MVC 3 и пытаюсь применить репозиторий.pattern.

Я решил разделить свою бизнес-логику в отдельный проект и определить службы, которые обертывают мои репозитории, чтобы я мог возвращать POCO вместо прокси NHibernate и поддерживать большее разделение между моей интерфейсной частью и логикой DA,Это также даст мне возможность легко предоставлять ту же логику, что и API позже (требование).

Я решил использовать общий интерфейс IRepository<T>, где T - это одна из моих сопоставленных сущностей NHibernateкоторые все реализуют IEntity (мой интерфейс на самом деле только маркер).

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

Если я изменяю объект, который висит на другом

  • Root <- изменен <ul>
  • Child <- изменен </li>

В моемСлужба Я должен сделать следующее:

public void AddNewChild(ChildDto child, rootId)
{
    var childEntity = Mapper.Map<ChildDto,ChildEntity>(child);
    var rootEntity = _rootrepository.FindById(rootId);
    rootEntity.Children.Add(childEntity);
    _childRepository.SaveOrUpdate(child);
    _rootRepository.SaveOrUpdate(root);
}

Если я сначала не спасу ребенка, я получу исключение из NHibernate.Я чувствую, что мой универсальный репозиторий (мне в настоящее время требуется 5 из них в одном сервисе) - неправильный путь.

 public Service(IRepository<ThingEntity> thingRepo, IRepository<RootEntity> rootRepo, IRepository<ChildEntity> childRepo, IRepository<CategoryEntity> catRepo, IRepository<ProductEntity> productRepo)

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

У кого-нибудь естьсовет, как реструктурировать такую ​​архитектуру?

Должен ли я сделать свои репозитории более конкретными?Является ли уровень абстракции сервиса слишком далеко?

РЕДАКТИРОВАТЬ : Есть несколько замечательных связанных вопросов, которые помогают:

Ответы [ 2 ]

2 голосов
/ 16 февраля 2011

Если у вас есть Агрегат, репозиторий одинаков для совокупного родителя (корня) и его дочерних элементов, поскольку жизненный цикл дочерних элементов контролируется корневым объектом.

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

Кроме того, в «правильном» агрегированном шаблоне дочерние записи не имеют собственной идентичности (по крайней мере, один виден за пределами агрегированного). Это имеет несколько прямых последствий:

  1. Не может быть внешних ключей от внешних записей / агрегатов к этим дочерним записям.
  2. Исходя из пункта 1. каждый раз, когда вы сохраняете состояние корневого объекта, вы можете удалять и воссоздавать дочерние записи в базе данных. Обычно это облегчает вашу логику постоянства, если вы сталкиваетесь с проблемами предшествования.

Примечание: обратный случай 1. неверен. Дочерние записи в совокупности могут иметь внешние ключи для других корневых записей.

1 голос
/ 26 апреля 2013

Я чувствую, что вместо того, чтобы сделать мой код более гибким, он делает его более хрупким.Если я добавляю новую таблицу, мне нужно пойти и изменить конструктор во всех моих тестах (я использую DI для реализации, так что это не так уж плохо), но это кажется немного вонючим.шаблон единицы работы в вашем хранилище.Это означает, что практически у вас есть единица рабочего класса, в которой хранятся ваши сервисы с помощью ctor или внедрения свойств.Кроме того, он содержит метод фиксации и / или транзакции.Только внедрите экземпляр IUnitOfWork в ваши службы.Когда вы добавляете репозиторий, вам просто нужно изменить единицу работы, не касаясь бизнес-логики (сервисов).

...