ASP.NET MVC SoC when dealing with back end objects (design decision)

Question

I had a discussion with some peers and even some technical leads in the team around this and Im all for the purist MVC approach. Especially when the project is in its infant stages (its easy to implement a pattern going forward). Im a firm believer that anything to do with the back end should be kept separate from the Views, Models and also the View-Models.

A final decision was made to go with using the objects deemed pass-through because they are used everywhere, from the UI all the way back to the back end platform which handles the actual request.

Here is a sample illustration of what is going to be implemented: MVC stack <-> Back end platform <-> Can either talk to a database or another 3rd party service And in the above example, a back end request object can be made in the controller level and passed through the the back end platform and there it can get adapted to suit either a database or another service. And when the database/3rd party service responds, its response is taken and adapted to one of our own types. This type will then be returned to the MVC stack. The Views and the ViewModels just use these back end platform types.

What Id like to see done: Id like for the controller to pass on the responsibility to an adaptor or indeed a service layer which is responsible for taking in POCOs and creating back end platform objects. Create the request, send it off to the Back end platform. And when it responds, adapt the response into a View or a ViewModel and send it back to the controller. Objects are injected into the controller so its simply a matter of passing the POCOs to another layer to take responsibility of creating requests, sending it off and then returning a response which consists of a View or a ViewModel.

Pros and cons. With the current implementation, its convenient and given that we (my company) owns the code that goes from front-end to the back end that gets used. It saves time. Which we don't have much of to get the job done. I don't see the separation of layers here.

With the implementation that Id like to see done, I believe it approaches the SoC a bit more and adds down on another layer of adaptation. This is a bit more work. And, from a pure MVC point of view, its using the back end platform objects which are being used in the back end (although it was assumed that these objects will also be used in the front end).

I realise this is long and doest have pretty pictures. Apologies.

Id like to know what you out there would have done. Cheers.

Answer 1

This is a common point of confusion with ASP.NET MVC, mostly because MVC is so un-opinionated about how your application should be built. @MikeSW makes a good point: it's important to realize that MVC is a UI pattern, but more importantly, you should realize that it's just a pattern. It's not law, the framework won't complain if you do something different.

I'll tell you how a typical ASP.NET MVC project develops, because there's a reason why it's typical. You have domain layer. That could include a DAL, services, whatever. For many, this is just Entity Framework, but if you're building anything larger than a ToDo app (and maybe even for that), you're going to want to abstract that out.

Now, because MVC comes with Entity Framework, the common assumption is that your entities are your Model of MVC. That's a very poor assumption. Entities are dumb - intentionally dumb. They're not really intended for anything but data transfer to and from the database. A Model should be the opposite of that: it should hold all your business logic for the application (or at least that piece of the application. In that way, a view model is closer to the Model of MVC, but even then, it's not all-ecompassing. I would say that your Model is some combo of your view model plus your domain layer. Regardless, the point is that if you intend to use entities as an end-to-end, be-all-end-all Model, at some point, it will bite you in the glutious maximus. It's not a matter of if, but when.

My recommendation is the following:

Database -> Entity Framework -> Domain Layer -> Controller -> View Model -> View

And, back the same way.

Your domain layer will utilize Entity Framework (but this could later be substituted with a Web API, WCF Service, whatever) to retrieve your entities. Your controllers will map your entities to view models and vice versa and then your views will use your view models. For POST operations, your controllers receive view models, map those to entities, and then send them through the domain layer down to be created/updated/whatever. All big MVC projects are built like this or in some minor variation of this, and for a good reason: if you don't do it this way now, you'll only have to do it this way later, with much more time and expense on the tail-end.