MVC3 App/Service Layer/Repository Layer/POCO Classes/EF4 - Questions!

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

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.