Архитектурные особенности: Свободное использование NHibernate, шаблон репозитория и ASP.NET MVC
Я ' Я только начал новый проект и, естественно, решил использовать много новых технологий.
Я использую (Свободно) NHibernate, ASP.NET MVC 3 и пытаюсь применить шаблон репозитория.
Я решил разделить мою бизнес-логику в отдельный проект и определить службы, которые обертывают мои репозитории, чтобы я мог возвращать POCO вместо прокси NHibernate и поддерживать большее разделение между моей внешней частью и логикой DA. Это также даст мне возможность легко предоставить ту же логику, что и API позже (требование).
Я решил использовать общий интерфейс IRepository , где T - одна из моих отображенных сущностей NHibernate, которые все реализуют IEntity (на самом деле мой интерфейс - всего лишь маркер).
Проблема в том, что это противоречит совокупному корневому шаблону, и я '
- Дочерний
В моем сервисе я должен сделать следующее:
public void AddNewChild(ChildDto child, rootId)
{
var childEntity = Mapper.Map(child);
var rootEntity = _rootrepository.FindById(rootId);
rootEntity.Children.Add(childEntity);
_childRepository.SaveOrUpdate(child);
_rootRepository.SaveOrUpdate(root);
}
Если я сначала не сохраню дочерний элемент, я получаю исключение от NHibernate. Мне кажется, что мой общий репозиторий (в настоящее время мне требуется 5 из них в одной службе) - неправильный путь.
public Service(IRepository thingRepo, IRepository rootRepo, IRepository childRepo, IRepository catRepo, IRepository productRepo)
Я чувствую, что вместо того, чтобы делать мой код более гибким, он делает его более хрупким. Если я добавляю новую таблицу, мне нужно пойти и изменить конструктор во всех моих тестах (я использую DI для реализации, так что это не так уж плохо), но это кажется немного вонючим.
Есть ли у кого-нибудь совет, как реструктурировать такую архитектуру?
Должен ли я делать свои репозитории более конкретными? Уровень абстракции сервисов зашел слишком далеко?
EDIT : Есть несколько замечательных связанных вопросов, которые помогают: