23

I am new to this whole design concept, and in reading for the last few weeks I have gathered a lot of information, but it seems scattered and conflicted. Terms are mixed, and I am just having a hard time wrapping my mind around this.

The pattern I am using is like this and assume the flow as follows:

MVC Application
The controller(s) process the request/response from the client for a given view. Inside the controllers action methods, they contact the services (Service Layer) and either request objects to build the view models, and sen the objects from the view models back.

View Models
I am using strongly typed view models to and from the views.

Are view models DTO's? Should they contain just simple properties like Name, AddressLine1, Address City, etc, or should they contain complex properties, multiple objects, etc.

Is the validation in the view model. If so would it be validation like required fields, field length, etc. Then validation like user name already exists, or where you would need to interact with other objects in the service layer?

Can the view models just contain the POCO classes returned from EF, or should I be using the AutoMapper?

If using AutoMapper and DTO, are DTO's clones of the POCO classes?

Would you map in the controller, view model, or in the service layer below?

Services
To me, the service(s) are objects that contact the repository(s) to get POCO objects back from the EF. This is where all of my business logic is. Once the service hands an object back to a repository to be persisted to the EF, they are considered valid objects. Is this correct?

Repositories
There is no business logic in them, they are just used to transport objects between the service(s) and the EF. Is this correct? I am implementing Interfaces here with generic repository. Then you could extend the generic repository for special needs?

Questions About Terminology
1) Is a business object equal to a domain object? How much logic should a domain object contain?

2) Is the domain model the EF model? I am using the Model-First approach.

3) Dependency Injection - Should I be using this? I understand how it works, just don't get the real benefit. I was playing with Ninject.

I think the community would benefit from some sort of wiki that contained all the best practices with code samples. Is there something like that out there? A lot of the samples out there are very simple, and a lot of the Microsoft samples do not use this pattern even when claiming to.

Thanks in advance to everyone who has and will help me with this.

BTW - I think StackOverflow needs a little, "Buy Me A Beer" button next to the "Accept Answer" checkbox :)

Sam
  • 15,336
  • 25
  • 85
  • 148

1 Answers1

30

Are view models DTO's?

Could be considered a sort of data transfer objects between the controller and the view.

Should they contain just simple properties like Name, AddressLine1, Address City, etc, or should they contain complex properties, multiple objects, etc.

Ideally simple properties but could also aggregate other view models but no models there (ex: like EF models).

Is the validation in the view model.

There are two type of validation logic: business validation (ex. username already exists) which goes into the service layer and UI validation (ex: username is required) which goes into the view model.

Can the view models just contain the POCO classes returned from EF, or should I be using the AutoMapper?

No EF in view models. View models are POCO classes with simple properties and other complex properties pointing to other view models. They could also contain methods in order to properly format the data that will be presented on the particular view those models were intended for.

If using AutoMapper and DTO, are DTO's clones of the POCO classes?

Not sure I understand this question.

Would you map in the controller, view model, or in the service layer below?

The controller.

To me, the service(s) are objects that contact the repository(s) to get POCO objects back from the EF. This is where all of my business logic is. Once the service hands an object back to a repository to be persisted to the EF, they are considered valid objects. Is this correct?

Yes.

Is the domain model the EF model?

If you are using EF Code first approach then yes, otherwise no (if EF pollutes the domain with EF specific attributes and classes).

There is no business logic in them, they are just used to transport objects between the service(s) and the EF. Is this correct?

Yes.

I am implementing Interfaces here with generic repository. Then you could extend the generic repository for special needs?

Yes, but don't get too fancy. Normally Repositories are for CRUD operations. It's services that should contain the business logic.

Is a business object equal to a domain object?

Yes.

How much logic should a domain object contain?

This will depend on the amount of domain logic you have for the particular project you are working and on any existing domain logic you could reuse from older projects you or someone else have worked on.

Dependency Injection - Should I be using this?

Yes, absolutely.

I understand how it works, just don't get the real benefit

It provides weaker coupling between the different layers of your application which in turns makes them easier to unit test and reuse in other projects.

I think the community would benefit from some sort of wiki that contained all the best practices with code samples.

I agree.

Is there something like that out there?

I doubt it.

BTW - I think StackOverflow needs a little, "Buy Me A Beer" button next to the "Accept Answer" checkbox

Can't agree more.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • arin - If using AutoMapper and DTO, are DTO's clones of the POCO classes? What I mean by this is if say I had a view that was going to display a customer's basic information with a collection of addresses and orders, I would assume the View Model would have the basic properties of the customer and then a collection of addresses and orders. Would those collections be properties of the POCO objects, or do I need to build a class in the MVC app that mimics the order and address classes from the POCO and use those in the view model? – Sam Feb 27 '11 at 23:29
  • @Darin - Is using POCO generated classes from the EF using the model-first approach the same as, or close too the code-first method? The POCO classes are pretty bare. Have a look here: http://www.striano.net/Customer.vb.txt, is this polluted? – Sam Feb 27 '11 at 23:36
  • 2
    @Sam, if you needed a view that was going to display a customer's basic information with a collection of addresses and orders you would build a CustomerViewModel that will contain the basic properties and a `AddressViewModel` and a `OrderViewModel` which will contain the properties you would like to show for a given customer about his addresses and orders and then the `CustomerViewModel` could have two collection properties of `AddressViewModel` and `OrderViewModel`. – Darin Dimitrov Feb 27 '11 at 23:46
  • 2
    As far as the domain models are concerned, personally, I define them by hand when analyzing my project requirements and never use anything that is *autogenerated* as domain model. If you use something that is autogenerated it means that you have based your domain logic on this *something* which IMHO is not a good thing. It's up to you to analyze the project requirements and define the domain objects. It later stage you could decide to map your models to a relational database or purchase a third party service API on the internet or something else. – Darin Dimitrov Feb 27 '11 at 23:48
  • @Darin - So in the case of the customer orders and addresses, each record gets a view model? – Sam Feb 28 '11 at 02:48
  • @Darin - Aside from the basics (Name, CompanyName, Phone, Email, etc.) what else would you put in a customer domain object? – Sam Feb 28 '11 at 02:52
  • @Sam, in the case of customer, orders and addresses your view model could look like this: `public class CustomerViewModel { public string FirstName { get; set; } public IEnumerable Addresses { get; set; } public IEnumerable Orders { get; set; } }`. And as far as the customer domain object is concerned, well, that's harder to say and it would really depend on the project requirements or any existing code base that should be taken into account. If you are designing an entirely new application just include the properties you think would be useful. – Darin Dimitrov Feb 28 '11 at 07:29
  • This may also help: http://weblogs.asp.net/shijuvarghese/archive/2011/01/13/developing-web-apps-using-asp-net-mvc-3-razor-and-ef-code-first-part-2.aspx – stormwild Dec 07 '11 at 06:12