MVC3 App/Service Layer/Repository Layer/POCO Class

Question

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 :)

Answer 1

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.