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.

3 Answers 3


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 (original article with proper formatting). 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.

  • Nice link! I'm checking it out. Oct 17, 2012 at 0:47
  • 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. Oct 23, 2012 at 21:21
  • Entity Framework, with its use of transactions, is already an implementation of the Unit of Work pattern. Oct 26, 2015 at 13:44
  • 2
    link is dead...
    – Newtopian
    Jul 3, 2017 at 16:43

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.


What theoretical foundation have you found for "Repository pattern" database design? I'm guessing none. It's a layer of complexity resting on a bogus premise: that the "persistence layer" is something you need to be isolated from. From what I can tell, it plays to widespread programming ignorance of relational design principles, and panders to a presupposed centrality of the application's OO design. But it doesn't justify its existence on rational, let alone theoretical, grounds.

The One True Path to database design hasn't changed in 30 years: analyze the data. Find the keys and constraints and many-to-one relationships. Design your tables according to Boyce-Codd normal form. Use views and stored procedures to facilitate data access.

Unloved though it may be, a SQL DBMS provides a better isolation layer than anything the programmer can provide. It's true that as the database changes the SQL used to access it might have to change. But note that that's true regardless of whether or not there's a mediation layer. As long as the application uses views and stored procedures to access the DBMS, ordinary SQL engineering tools will indicate when changes to the underlying database invalidate those views and stored procedures.

Therein lies the challenge, of course. A mediation layer provides the illusion of isolation and the comfort to the programmer of writing code, which he knows how to do. Learning database design and SQL requires learning something new. Most people would rather die than think, and many succeed.

Someone on your team will doubtless object that writing SQL to support your 200 classes is a lot of work. No doubt. But at least it's useful work. If you design a database by mimicking your OO design, you will also do a lot of work, much of it useless, and defeat most of what the DBMS offers you.

For example, you contemplate reflecting Unit of Work in the database (as table or tables, I presume). Unit of work is a built-in service of the DBMS: begin transaction ... update database ... commit transaction. Nothing to model, other than the mapping of your classes to the database tables in SQL.

Your question was posted 4 years ago. I'm answering because it was "updated" in some way recently, indicating it's still of some interest to someone. I hope my answer encourages the reader to apply basic relational theory to the problem instead of adopting a pointless workaround.

  • 2
    "Learning database design and SQL requires learning something new. Most people would rather die than think, and many succeed." Your cathartic attacks on strawmen obscure whatever actual wisdom you might have had to offer. What about those who know SQL well and yet still favor software patterns that don't rely solely on views and stored procedures for abstraction? Jun 29, 2021 at 19:31
  • @MarredCheese, those who know SQL and prefer not to exploit it are free to hold their opinions and work as hard as they want to, of course. The OP asked — 4 years ago! — how to design the data access layer. I would recommend then and now to design the database first, and use the DBMS's features to insulate the application from changes in the database design. Once that's done, use any access pattern you want that doesn't try to write the SQL for you. Jul 7, 2021 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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