CODEWITHSUNDEEP
c#asp.net-mvc-3model-view-controllerdesign-patterns
Fabian Trottmann
Fabian Trottmann

Reputation: 224

MVC3 - reference to a separate service project in which module?

Initial situation:

I would like to build an MVC3 application with a layered architecture. The layers would be the persistence layer (repository pattern), service layer and the View layer. I also want to map entities to DTOs in the persistence layer, and passing these DTOs to the View.

In the View I would like to apply the MVC pattern by using MVC3 weapp. Now my Question is, in which module, the Controller or the Model should i access (reference to) the service layer. I always see references to the service layer in the controller, like this:

public class CustomerController
{
 public ViewResult Details( int id )
    {
       CustomerDTO customerDto = MyService.GetCustomerById();
       return View( customerDto );
    }
}

Shouldn't I access the service layer in the Model module? If I access my service layer in the controllers, I don't need the Model module at all...?

Upvotes: 2

Views: 219

Answers (2)

Tony Hopkinson
Tony Hopkinson

Reputation: 20320

Depends on whether you want to hide MyService from controller.

In your example it's visible. If you had a method on Model of the same name that then delegated to MyService, it wouldn't be.

Advantage of hiding it is you could swap MyService for YourSevice without impacting the View and Controller layers.

As for no model. Where are you defining your DTOs then? Basically MyService would be your model.

You are also operating on the assumption that the DTO for model to controller to view is the same all the way through, even when adding at least one other layer.

I'd think through that assumption if I were you...

Upvotes: 1

Andras Zoltan
Andras Zoltan

Reputation: 42343

I always work on the basis that any real work with the service layer is done in the controller.

If I access my service layer in the controllers, I don't need the Model module at all...?

Incorrect - it is highly unlikely that your service types either will have, or even should have the correct shape and metadata (for example [Display] or [DataType] attribution) or to make them work correctly with MVC views. You should have a Model type for all objects that get given to the view, even if they're one-for-one clones of your service types - because then you have a separation between the data that your view and controllers need and your service types.

If you try to bind your views directly to your service types, then you are creating either one of these two scenarios:

  • making it harder to change view & controller code because the data being sent to and fro has to conform to service types
  • making it harder to change service types because to do so would mean changing every view

The ViewModel (or Model, depending on your point of view) is your adapter between what's nice for viewing (displaying on a web page) and binding (receiving from a web page) - and it's simply the case that these two things will often drift apart from the actual service types used at the business logic level. Indeed they should, because they aim to solve different problems.

Upvotes: 6

Related Questions