views:

167

answers:

2

I think I am very close to assembling an MVC repository correctly but just falling apart at the fringe. I created an MVC project with a repository and am returning data successfully, but not accurately as it pertains to DDD. Please tell me where I am incorrect in terms of strict DDD assembly. I guess if the topics are too wide, a book suggestion would be fine. I hope that I am specific enough in my question.

This was one question but I separated them for clarity: Do you create a single namespace for all repository classes called MyStore.Models? Create a repository class for each entity like Product within the Models namespace? Do you put the Pocos in their own classes in the Models namespace but not part of the Repository class itself?

I am currently using Pocos to cut out entities from Linq statements, returning groups of them within IQueryable wrappers like so. I guess here you would somehow remove the IQueryable and replace it with some type of Lazy load? How do you lazy load without being dependent on the original Linq to Sql?

public IQueryable<Product> GetProducts(...) {
return (from p in db.Products
        where ...
        select new myProductPoco {  // Cut out a Poco from Linq
            ID = p.ID,
            Name = p.Name,
            ...
        });
}

Then reference these in MVC views within the inherit page directive:

System.Web.Mvc.ViewPage<IQueryable<MyStore.Models.Product>>

However, the nested generics looks wrong. I assume this requires a re-factor. Where do you define View Model classes that contain references to Entities? Within the controller class (nested class)?

+2  A: 

As book suggestions, try Eric Evan's Domain-Driven Design, and maybe Martin Fowler's Refactoring.

Martinho Fernandes
As I understand it, you should define your Domain Model classes separate from your repository. Furthermore, you should define your ViewModel classes separate from that (view model classes are subsets of Domain Model classes so you don't send unnecessary data to the client. :)
Dr. Zim
Well, my first comment is actually incorrect now that I know more. You don't create ViewModel classes that reflect pieces of Domain Models, you simply only populate the fields you need in the existing Domain Model. Pretty crazy. Still not sure on aggregate roots which use IList for relations. These seem to be way to large to load in bulk from the database.
Dr. Zim
+1  A: 

Also try Domain Driven Design Quickly produced by InfoQ. It's free to download or $30 in print.

"Domain-Driven Design Quickly was produced by InfoQ.com, summarized primarily by Abel Avram and with Floyd Marinescu as managing editor. Special thanks to Eric Evans for his support and Vladimir Gitlevich and Dan Bergh Johnsson for their detailed reviews. The intention of this book is to get an introduction to Domain-Driven Design into as many hands as possible, to help it become mainstream." -- InfoQ

Campey