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.

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.