Domain Design class decisions

Question

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

Thanks

Answer 1

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.