8

I've been working with ASP.Net MVC for around a year now and have created my applications in the following way.

X.Web - MVC Application Contains Controller and Views

X.Lib - Contains Data Access, Repositories and Services.

This allows us to drop the .Lib into any application that requires it.

At the moment we are using Entity Framework, the conversion from EntityO to a more specific model is done in the controller.

This set-up means if a service method returns an EntityO and then the Controller will do a conversion before the data is passed to a view.

I'm interested to know if I should move the conversion to the Service so that the app doesn't have Entity Objects being passed around.

Improve this question
2
  • What exactly is the role and scope of your "Service" layer?
    – user8685
    Jan 23, 2011 at 19:56
  • Essentially, application logic and the go-to place for any communicating application.
    – LiamB
    Jan 24, 2011 at 10:46

5 Answers 5

Reset to default
2

I agree that you are doing it the right way. Jimmy Bogard (author of AutoMapper) wrote an excellent article on why this style of solution structure works and I follow this "guidance" whenever I can: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/12/08/organizing-asp-net-mvc-solutions.aspx

However you should also focus on getting the right structure within you Library assembly. Richard Dingwall wrote an interesting article on organizing your code by responsibility rather than technology: http://richarddingwall.name/2009/08/08/real-life-ddd-organise-code-by-responsibility-layers-not-repositories-and-services/

Improve this answer
3

As I understand your question, the Entity object is also your "domain" object, i.e. an object that represents some domain concept. This object should not be dictated by what is required to be displayed, but instead how your domain looks. That kind of logic fits perfectly in the .Lib project.

When you say that the controller converts the entity object to a "model", I guess this model is one that contains the properties that are necessary to display in the view. This is also called a "View Model" (note that WPF applications also talks of View Models, but here they mean something slightly different).

The point is that the view model in an ASP.NET MVC app is an object that communicates data between the controller and the view. And that responsibility has no place in the .Lib, it belongs solidly in the .Web

Improve this answer
1

I think you're doing it the right way.

Only the controller should now what exactly set up it needs in order to fill a model with the necessary presentation data. To do so it puts a bunch of Entity Objects together. Outsourcing the job of filling the models to another layer seems to contradict the idea of a view belonging to the presentation layer.

Improve this answer
1

I actually have a current application set up the same way but with the use of services returning models and not EF objects. The web layer knows nothing of EF but only the POCO models defined inside the lib layer. So, my web layer doesn't need a reference to EF in order to understand EF objects. I also only reference and use AutoMapper only in the lib layer for converting from EF objects to my models.

Improve this answer
0

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

EDIT

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.