Ok, if you've got Entity Framework generated classes anywhere near your Service layer you're not separating concerns correctly.
Take a look at EF POCO. What you really need to keep your logic/DA/frontent code separate (and therefore maintainable) is the following setup (and a decent dependency injection framework):
- X.Web - Views + display logic (formatting things etc.)
- X.Interfaces - Definitions of your Services in Interface form
- X.Implementation - Your services in concrete class form
- X.DataModels - Definitions of your data objects and the Data-access interfaces for each of them
- X.DataAccess."Insert name of DA tool here" - this is where the implementations of your data access interfaces go.
This way you're forcing yourself to keep each set of objects hidden from the others. For example, your service layer will need to know about the DA layer, but not about how it actually achieves its DA, so it only needs an explicit reference to the X.DataModels assembly, where the Interface contracts for the DA layer reside.
You really don't want to pass anything that's specifically related to your data access layer into your service for one simple reason: What if you change DA methodology?
I'm not talking a database switch here: what if you want to slide in a caching layer? It will be much more difficult if you have to parse EF object in your cache layer, as you'll have to break out the parsing code into separate classes and share it between layers, which then strongly ties your Service and Cache layers together. The other option would be to put the caching layer in front of the Service layer, however this will bring other problems to the table (like datasets that are used repeatedly in different services being cached at slightly different times, which can lead to all manner of nonesense).
Yeah, I went a little off-piste at the whole "passing EF classes about" thing.
The conversion from data object to view should be done in the controller: you're completely correct about that. The above still applies though :)