Repository / UoW - To use or not to use?

Question

I know this has been done a million times before but I'm still in two minds in which way to go:

1. EF - UoW / Repository - Service - Web or
2. EF - Service - Web

It seems like the UoW / Repository layer is redundant as you can mock DbContext etc. This would make the implentation simples and having the service closer to EF seems more versatile.

Does anybody have any good advice on this?

One question I have around this though is I'm going to be using Ninject to wire things up. On the web side if I want to inject DbContext into the service it needs reference to EF. This seems wrong.

kernel.Bind<FunkySoftwareContext>().ToSelf().InRequestScope();

Is there a way to counteract this?

Answer 1

Depends on if you want to have correct abstractions or not.

The service layer should not expose database entities. It should expose proper business/domain models. They may or may not look exactly as the db entities.

imho that's what the repository pattern is good for. It takes the business model representation and transform it into something that the database/orm can use (and vice versa).

But if you've decided that the objects loaded from Entity framework is a perfect representation of your domain/business model, by all means go ahead and skip the repositories.

I've written a blog entry about that here: http://blog.gauffin.org/2012/06/protect-your-data/

Answer 2

(this was going to be a comment but it grew too big!) You should ask 2 questions if you have 2 questions. If this was a Ninject question, I'd answer it but the title suggests not.

On the ninject side, see Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?) (inc following the link to the duplicate).

Summary is it is correct for a single Composition Root to manage to Binding process so ultimately you will end up having something (see @jgauffin answer) that will be InRequestScope and the right place to say that is in the CR.

Other approaches (go read all the UOW MVC Repository InRequestScope Qs & As) boil down to just having Business layer service classes injected into the Controller class which either

1. Implement IDisposable all the way down if some turtle under it is using a DBContext may be a better way to manage it.
2. (More ideally) let the Controller explicitly Commit any UOW (and deal with failures) in an explicit manner (which doesnt completely preclude some catch-all handling with Filters etc.). I'm definitely not saying that the Controller should be directly talking to a DBContext.

Answer 3

It seems like the UoW / Repository layer is redundant as you can mock DbContext etc. This would make the implentation simples and having the service closer to EF seems more versatile

Even you yourself relize that Repository pattern over-uses by now, EF itself implement UoW with DbContext and Repository with DbSet. So, needless to add UoW/Repository to your architecture.

If you need more advices on this here and here . Or even advices from Ayende: here and here