Take the 2-minute tour ×

I am creating a simple web site to get more familiar with MVC 2.0. I've been doing web forms since 1.0 and getting ready to start a major overhaul of a web forms site to MVC. So want to build a smaller app to work out the learning curve.

So I'm going to build a time tracking application. I'm using ASP.NET MVC 2.0 and LINQ to SQL. I plan on giving the repository and unit of work a try since I will be using them in the large web site.

My database only has 4 tables Category, Project, Assignment, and User. So I will have those 4 entities in LINQ2SQL. Then I will have POCO's for ProjectDetails, ProjectSummary, AssignmentDetails, ect. But are those consolidated table entities? Or does each of them need their own Repositories? Or should they fit into the aggregate Repository?

Let me know if you need any more details


share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

Your domain POCO's do not have to have a 1-to-1 relationship with your DB tables. And nor do your Repositories classes have to be restricted to reading/writing a single table.

In a domain driven design you often start with your domain models first and then figure out how to persist those to your storage mechanism whether it be SQL, NoSQL, memory cache, etc.

share|improve this answer
Since their are multiple ways of building your domain model how do you decide what way to do it. I have found SRP, one repository (gateway), and I'm sure they are others. –  Matt Heffernan Sep 9 '10 at 0:02
Most of our models are 1-to-1 wrt to our DB tables and for those we have a single repository for each that reads/writes to a single table. In the cases where a model is more complex we have a single repository that reads/writes to multiple tables within the same DB. But those repositories are harder to maintain so we try to keep them to a minimum. –  Todd Smith Sep 9 '10 at 17:55
add comment

Your Answer


