Architectural concerns: Fluent NHibernate, The Repository pattern and ASP.NET MVC

Question

I've just started a new project and have naturally opted to use a lot of new tech.

I'm using (Fluent) NHibernate, ASP.NET MVC 3 and am trying to apply the Repository pattern.

I've decided to seperate my Business Logic into a seperate project and define services which wrap my repositories so that I can return POCOs instead of the NHibernate proxies and maintain more seperation between my Front end and DA logic. This will also give me the power to easily provide the same logic as an API later (a requirement).

I have chosen to use a generic IRepository<T> interface where T is one of my NHibernate mapped Entities which all implement IEntity (my interface only a marker really).

The problem is this goes against the aggregate root pattern and I'm starting to feel the pain of the anemic domain model.

If I change an object that is hanging of another

• Root <- changed
  • Child <- changed

In my service I have to do the following:

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);
}

If I don't save the child first I get an exception from NHibernate. I feel like my generic repository (I currently require 5 of them in one service) is not the right way to go.

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

I feel like instead of making my code more flexible, it's making it more brittle. If I add a new table I need to go and change the constructor in all my tests (I'm using DI for the implementation so that's not too bad) but it seems a bit smelly.

Does anyone have any advice on how to restructure this sort of architecture?

Should I be making my repositories more specific? Is the service abstraction layer a step too far?

EDIT: There's some great related questions which are helping:

• Repository Pattern Best Practice
• repository pattern help
• Architectural conundrum

Answer 1

When you have an Aggregate, the Repository is the same for the aggregate parent (root) and its children because the life cycle of the children is controlled by the root object.

Your "Save" method for the root object type should be also directly responsible for persisting the changes to the children records instead of delegating it into yet another repository(ies).

Additionally, in a "proper" Aggregate pattern, the child records have no identity of their own (at least one that is visible outside the Aggregate). This has several direct consequences:

1. There can be no foreign keys from outside records/aggregates to those children records.
2. Resulting from point 1., every time you save the root object state, you can delete and recreate the child records on the database. This usually will make your persistence logic easier if you bump into precedence problems.

Note: the reverse case of 1. is not true. Child records in an aggregate can have foreign keys to other root records.

Answer 2

I feel like instead of making my code more flexible, it's making it more brittle. If I add a new table I need to go and change the constructor in all my tests (I'm using DI for the implementation so that's not too bad) but it seems a bit smelly.

Implement the Unit Of Work pattern in your repository. That means practically you have a unit of work class which holds your services inject via ctor or property injection. Futheremore it holds a commit and/or transaction method. Only inject the IUnitOfWork instance in your services. When you add a repository you just have to change the unit of work not touch the business logic (services).