Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our data model has almost 200 classes that can be separated out into about a dozen functional areas. It would have been nice to use domains, but the separation isn't that clean and we can't change it.

We're redesigning our DAL to use Entity Framework and most of the recommendations that I've seen suggest using a Repository pattern. However, none of the samples really deal with complex object models. Some implementations that I've found suggest the use of a repository-per-entity. This seems ridiculous and un-maintainable for large, complex models.

Is it really necessary to create a UnitOfWork for each operation, and a Repository for each entity? I could end up with thousands of classes. I know this is unreasonable, but I've found very little guidance implementing Repository, Unit Of Work, and Entity Framework over complex models and realistic business applications.

share|improve this question

migrated from Oct 16 '12 at 17:45

This question came from our site for professional and enthusiast programmers.

up vote 3 down vote accepted

First, you will run through every entity that you have and ask yourself :

Does it make sense to persist this entity alone?

What I mean here, is that in your object model, some entities are likely contained in others in a master-detail relationship. If your entity is highly dependant on another, do not create a repository for this entity alone because it won't likely be persisted by itself. Instead, you will create a repository for each parent class, and you will make sure that the child entities and other relations are persisted at the same time.

I don't like how they implemented the UnitOfWork pattern in the link you provided. I suggest you to do something more along these lines. You don't have to define one class per repository. The same class can be used for every repository, each having their own instance of the UnitOfWork class for the lifetime of the operation. You can also reuse the same UnitOfWork in different repositories for changes that you want persisted at the same time.

share|improve this answer
Nice link! I'm checking it out. – Eric Falsken Oct 17 '12 at 0:47
@EricFalsken Feel free to accept this answer if it was of any help. – marco-fiset Oct 22 '12 at 20:46
Your link (and answer) were the most helpful although I ended up not using the patterns provided. I ended up using a wrapper class that proxied the Add/Attach/Remove/SaveChanges methods to work as a generic repository, and then added a Query/QuerySingle/QueryAll method that accepts custom query classes to hold my query implementation. This is working out nicely so that I can do both LINQ and T-SQL queries without getting EF directly involved. – Eric Falsken Oct 23 '12 at 21:21
Entity Framework, with its use of transactions, is already an implementation of the Unit of Work pattern. – Greg Burghardt Oct 26 '15 at 13:44

You could implement a generic repository that would work with all entities. I've found this to be a good discussion on generic repos

share|improve this answer
I highly doubt that a generic repository would do the job for a highly complex object model. Relations are likely to have custom persistence logic which cannot be made generic. – marco-fiset Oct 16 '12 at 19:15
And I've found that the simple requirement of occasional compound (multi-column) keys makes a single, generic repository almost impossible. – Eric Falsken Oct 17 '12 at 0:48

Maybe you should have a look at Domain-Driven Design. It recommends grouping your objects in Aggregates and creating repositories only for the Root entity of each Aggregate. It's a nice way to bring order to a big complex object model.

Your different functional areas could be Bounded Contexts. There are various techniques to deal with overlapping Bounded Contexts if the separation between them isn't clear.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.