How to implement n-layer architecture in MVC?

Question

I know this question has been asked before. I am only asking so that I can get a better explanation. In my webforms applications, this is how I implemented my projects. The solution had two projects. The first project contains Data Access and Business Logic. The first project is referenced in the second project. The aspx.cs files call the business logic class and the business logic class calls the data access class.

I am trying to follow the same approach in my MVC applicaiton. How would I implement that? Controller calls Model which in turn calls Business logic? This approach would add overhead right?

As I understand it, in MVC, controller and view models are your business logic. model is your data access. Views are your presentation logic. — Nick.Mc, Jul 25 '14 at 01:51
@ElectricLlama Thanks for the reply. If that approach is followed, wouldn't I lose code reusability ? For example, I could use project 1 in my example for project 3 without having to duplicate project 1 functionality again. How would I implement it in a way where the reusability is not lost? — Samson Bujju, Jul 25 '14 at 01:55
I'm no authority but the way that makes sense to me is that the ViewModel can be used to house only the information necessary for the presentation layer and used with strongly typed views for easy scaffolding. The data layer model should be concerned only with the representation needed for the data persistence. In between those two sits the business layer which has its own model to represent the business objects... whether that's 2 projects or 3 is down to preference. But that's all just opinion, not science. — Klors, Jul 25 '14 at 01:59
you should check my question http://stackoverflow.com/questions/7474267/mvc3-and-entity-framework — Jorge, Jul 25 '14 at 02:05
@Jorge I believe you already implemented your projects like the way I want to. In that case can I assume that your view calls controller which calls the model which calls the business logic? — Samson Bujju, Jul 25 '14 at 02:13
Yes i already implemented this architecture, and your controllers should called your business layer, your views are base on your businnes objects — Jorge, Jul 25 '14 at 02:15

Keith Payne · Accepted Answer · 2014-07-25T02:58:33.283

In reference to the direction the comments are taking this thread (this doesn't fit neatly into a comment):

The models folder that is created with a new MVC project is for View Models - they are classes to support views. These are not your business models or data models.

For instance, in a ViewModel that supports a view, you might have a enum property that renders to a dropdown:

public enum CustomerTypes 
{
    INDIVIDUAL = 0,
    COMPANY
}

public class CustomerViewModel
{
    public CustomerTypes Type { get; set; }

    public string[] CustomerTypesSelectList { get; set; }
}


public class CustomerController : Controller
{
    public ActionResult Edit()
    {
        var model = new CustomerViewModel();
        model.CustomerTypesSelectList = 
            Enum.GetNames(typeof(CustomerTypesSelectList));

        return View(model);
    }
}

And with this you have some javascript in your view to populate a fancy drop down list with the items in CustomerTypesSelectList.

The UI-specific string[] property is a common construct of a ViewModel that gets stripped away when it gets converted to the business model or data model. The Controller would control the conversion (a.k.a. mapping), but probably rely on another class to implement the mapping that ties together the ViewModel and the business model.

To sum up, in an n-layer architecture:

The MVC Controller is not your business logic. Your business logic resides inside of various services and components that are called by the controller.
The Models folder contains ViewModels - classes that are meant to support the operation of the UI only.
The Controller calls a mapper to translate between ViewModels and business models when calling into the business layer.

score 0 · Answer 2 · answered Jul 27 '14 at 04:03

Have your architecture with following things

Data access project - add ORM/ADO.net with repository and unit of work pattern. Repositories can be generated using T4 template from ORM

ViewModel project - have a separate project for Viewmodels (containing properties to be used by view).

Business layer - have classes which contains functions that access repositories from data access layer, join them if needed using LINQ and populate in Viewmodel and return view model object or view model collection to controller.

WEB Project - Controller - access business layer functions using dependency injection and return view model to view View - Access view mode returned by controller

How to implement n-layer architecture in MVC?

2 Answers2