I'm still in the process of learning DDD. I'm writing an ASP.NET MVC Application and I have several drop downs that I need to populate from the database. I've created mapped entities for every type (status, result, etc.)
What I can't figure out is from where I should be getting the data. Creating a separate repository for each type of selection list feels like a pain when you have to inject plenty of repositories into the MVC controllers. Also, all these selection lists are read-only so a开发者_如何学Go repository per selection list seems overkill. Creating a single super repository for all selection list types doesn't seem right either, since a repository should be like a collection of one entity type.
I've been reading a little about CQS and having a reporting layer, but I don't know how that would be implemented correctly.
First of all - do not even look at CQRS if You don't feel comfortable with DDD. I mean - do look, but don't try to implement real project with it. Yet.
When we aren't separating read from write sides of our application, repository gets messed up a little bit cause of mixed responsibilities.
From one point of view - it is responsible for persisting aggregate root, from other - it's responsible for reporting too.
That means - there is nothing wrong (at least in my mind), if repository contains functionality to retrieve data for presentation purposes only.
In Your case - i would just build dropdowns using data from according repositories. So - Product dropdown list would take data from ProductRepository.Find(bySomething)
(or Repository<Product>(bySomething)
in case I decide to use generic repository).
P.s. Be warned that DDD isn't that much about patterns. It's more about ubiquitous language and making Your domain model explicit.
精彩评论