What is the different between Model/Business Layer/Data Access and Repositories in the MVC architecture?

Question

I like to start my question by stating that I am new to .NET framework and ASP.NET altogether. However, I am trying to learn ASP.NET 5 MVC 6. I have read many tutorial to get me up to speed. The main tutorial that I have learned a lot from was "Learn MVC in 7 Days"

I think I get the MVC architecture over all, but there is some terminology/layers that are confusing me i.e. Model, Business Logic layer, Data Access layer and View Model.

Here is my overall understanding of the MVC architecture "Please correct me if wrong"

• (M) Model: is an object that represent a database table. Each table in the database is a model. Each column with in each table is an attribute in the model's object. For example, if I have a table called "users" with the following columns id,firstname,lastname and username then the model will be called user and "id,firstname,lastname and username" are attributes.
• (V) View: is the way to present the data to the end user by placing data into HTML page.
• (C) Controller: is a layer that will be called by the route engine. The controller class holds some logic on what data/views should the user see. For example, UsersController class has a method called Index() which request some data from the user model and then returns a view called ShowAllUsers.

However, Model seems to have another 3 layers underneath it like so

• View Model: which seems to be a way to transform the raw data coming from the model into a presentable "view ready" format. For example, if we want to present the user's Full Name to the end user but we do not have fullname as an attribute in the model. Then we this layer will create a new object which is the same at the model object with one additional virtual attribute called fullname. Therefore, we now can display obj.fullname in the view.
• Business Logic Layer
• Data Access layer

Additionally, if I want to have a repository for my controller, where would this fit here? I do understand this may not be necessary for a small application, but I am just trying to understand and learn the correct way then I can decide whether this is needed in my app or not.

My question here is what is the business logic layer and what is data access layer? and where would the repository fit here?

I will appreciate an explanation with an example.

Solution 1

The following snippets are pulled from some tutorials on the MSDN, which you may find helpful:

Data Access Layer

When working with data one option is to embed the data-specific logic directly into the presentation layer (in a web application, the ASP.NET pages make up the presentation layer). This may take the form of writing ADO.NET code in the ASP.NET page's code portion or using the SqlDataSource control from the markup portion. In either case, this approach tightly couples the data access logic with the presentation layer. The recommended approach, however, is to separate the data access logic from the presentation layer. This separate layer is referred to as the Data Access Layer

Business Logic Layer

The Data Access Layer (DAL) created in the first tutorial cleanly separates the data access logic from the presentation logic. However, while the DAL cleanly separates the data access details from the presentation layer, it does not enforce any business rules that may apply. For example, for our application we may want to disallow the CategoryID or SupplierID fields of the Products table to be modified when the Discontinued field is set to 1, or we might want to enforce seniority rules, prohibiting situations in which an employee is managed by someone who was hired after them. Another common scenario is authorization – perhaps only users in a particular role can delete products or can change the UnitPrice value. In this tutorial we'll see how to centralize these business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL.

From a Code Project article, I found this description of the Data Access Layer's purpose to be particularly informative:

The data access layer provides a centralized location for all calls into the database, and thus makes it easier to port the application to other database systems.

I also located this blog post that does an excellent job of illustrating how the Business Logic Layer integrates with repositories:

Finally, here is Microsoft's definition of business logic:

Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies; and ensuring data consistency and validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a use case or user story.

I wish I could provide my own expert description of these layers, but I am also learning about this subject so I thought I would share what I had uncovered in hopes that we'll both be able to learn something from it. For example problems related to these layers, please refer to the tutorials I have linked above.

Solution 2

MVC is only about Presentation layer. Don't confuse it with a solution for Business and Data layers only because it contains the word Model

Firstly lets talk how layered architecture works:

The idea is very simple. The top layer is dependent on the below layer. So, Presentation layer is dependent on Business layer, Business layer is dependent on Data Layer. In other words, Business layer defines business logic and provides interface for Presentation layer, Data layer defines data access logic and provides interface for Business layer

Now lets talk about what MVC is:

• V(View) - is where UI logic exists.
• M(Model) - is interface to Business logic layer. It's important to understand that it's not business logic itself, it's just interface. That's why we say that Presentation layer is dependent on Business layer - because it uses its interface
• C(Controller) - it's where you call Business layer's interface and maps received data to View.

Also check these answers:

• How should a model be structured in MVC?
• Architecture more suitable for web apps than MVC?