Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I know that we should only create repositories for Aggregate Roots and not for the entities it aggregates. Should I apply the same logic to MVC, e.g., have a Controller/PageView for an Aggregate Root and then a/some PartialView/PartialAction for the sub-entities.
Please illustrate your answer with the famous Order/OrderLine example.
I am currently using the S#arp Architecture and there is no examples of this.
Edit 1 : I started a thread on the Sharp-Architecture group
I will take a shot at answering my own question.
First of all, ASP.NET M(VC) and DDD are things that are complementary. The concept of Aggregate Root should not alter or drive the design of the views/controllers. An Aggregate Root is something applied to a (business) model. The views/controllers should deal mostly with simple objects. It may be necessary to create some specific classes (DTOs). Model binding is something cool but the controllers (or Model Binders) should not have the responsibility of creating an Aggregate Root.
What do you think ?