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

Kellyekellyn

There is a good chance your NHibernate mappings are not correct. – Carolecarolee

It looks like I need to add .Cascade().All() (I'm using Fluent NHibernate) but thanks for the heads up! – Kellyekellyn

@Rob - briefly, I'd say even the repository is a layer too far, the increasing brittleness you see is a warning! If you haven't read it already, Repository is the new Singleton convinced me that you might as well write your application straight against NHibernate. The Onion Architecture articles are also germane (and interesting). – Nabalas

@Jeff I'd been thinking that myself actually. I might as well just use the NHibernate objects directly in the service classes. I like to keep business logic out of the MVC projects for the reasons stated already. – Kellyekellyn

@Rob: what will the code in those service classes manipulating NHib objects look like? Will it be getting and setting properties on those NHib objects? If so, this will continue to lead you towards an anemic domain. Something to consider. – Erepsin

@qstarin I would be using automapper to do the getting and setting, but it may be calling out to other external dependencies, sending emails etc. However, I have a complex domain which is based on many rules. I do not want these rules to get lost in my MVC code. I want to be able to reuse this logic and offer it as a web service. – Kellyekellyn

@Rob Stevenson-Leggett - Have you thrown all your logic into one Service? – Phidias

@Phidias Not all, there's several services, this one is particularly unwieldy – Kellyekellyn

@Rob: AutoMapper or not, that is manipulating the (what should be) internal state of your domain objects from outside the domain objects. I always find that is the road to anemia. Look at any given property, ask yourself: in how many places might this property be changed. Again, just trying to provoke some thought along the lines of avoiding an anemic domain. – Erepsin

I'm going to close this - I don't think there's a real answer - it seems I need to review a few things. Thanks for your input though. – Kellyekellyn

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.

Episcopal

Thanks that's helpful. How about the second part of the question - with the abstraction of the service layer? – Kellyekellyn

I would forget about the service layer until it is absolutely necessary. Usually a service layer would be present to implement high level operations, involving multiple repositories, long running processes or something else, other than basic CRUD. – Episcopal

I have a complex domain with many rules. I feel uncomfortable letting this logic reside in my controllers as it is shared between 2 different applications and will be offered as a REST service. – Kellyekellyn

Then you have a good reason to define services. I was referring to more simple logic like the one in your example, that belongs inside a repository. – Episcopal

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).

Tinworks