I will try to help (hopefully not cause further fragmentation - every answer here is saying subtly different things).
Abstract: The question seems to refer to the MVC architecture: it speaks of Controller, Model and View. It presents DAL and Business as distinct layers and at the same level as the first 3 (which is a little mistaken, but more about that below). Having said that, I will try to explain what MVC is, after all, and how these 3 layers relate.
First of all, I’m going to use the terms Model, Controller and Vision (After all, we are in the OS in Portuguese).
Second, MVC is not a term restricted to . NET, much less C#: it is actually an architectural pattern that exists decades, which was used long before the popularization of the Web (it was created in the 1970s by the people of Smalltalk)! On the other hand, the framework ASP.NET MVC follows the architecture MVC (so what goes for the latter is generally also for the former).
Thirdly, I think it is important to start by defining the layer which is by far the most controversial: the Model.
Translating what’s in the lobby Model-view-controller of Wikipedia in English, we find the following phrase:
The central component, the model, consists of application data, business rules, logic and functions.
The fact that the term "model" is used indiscriminately, meaning a Active-Record (for example, by the Ruby on Rails community), or DAL or a mere DTO (by the ASP.NET community itself) does not help.
So let’s stop messing around: Model not only is the name of a entire layer (and not the name of a type of class, or of a specific design-Pattern), as it is also, almost always, the greater layer of any self-respecting MVC system! In fact, this is precisely why it is usually divided into sub-layers: access to data, services, etc. (however, this is not described in the MVC architecture, even if it is often recommended).
Editing Trying to explain in a slightly less "radical" way: specifically in the ASP.NET MVC world, the nickname "model" is usually given (the most suitable name for this type of class is "View Model") for the classes used to carry data between the controller and the view. And here is the question: model is a class or a layer? Well, just as "Rio de Janeiro" is a term that depends on context (it can refer to the city or the state), so is "model". Formally speaking, this term refers to the entire layer, but it can be, at first, used to reference any class belonging to it. That is, a domain class or an entity, even if they are not "view models", are also "models".
And now let’s define the other MVC layers:
- The Controller is the layer responsible for the rules presentation, and to transform data between Model and the Vision. And a lot of attention: presentation rules != business rules!
- To Vision is the layer responsible for presenting the data to the end user (it can still be split between passive and active, but that is beyond the scope of this answer).
The main advantages of MVC architecture are, in my view, decoupling between the presentation needs and business rules, the ease of using TDD techniques and the practicality of introducing new representations of the same data (the three concepts, moreover, are closely related).
In practice, some examples of the advantages of using MVC:
- You can create multiple different Views representing the same data source (for example, to present data in the form of a detailed listing, or in the form of a graph, or merely as a JSON package - in ASP.NET MVC it would be necessary to create a new action in the Controller for each of these alternatives, but other MVC libraries can allow this only by adding a new View).
- The rules of business become independent of the presentation needs - could even be maintained by a team separately. If changes occur in any business object (for example, the name and type of a field of a returned DTO), the impact is minimized: in principle only the Controller (which transforms the data for the consumption of the Visions) would need to be changed.
- It is now possible to test each layer independently: I can connect my Views to Test Controllers (which do not query the database and use data fake, for example) to check if the presentation is suitable; I can also directly call the methods of a Controller from a suite of unit tests, without rendering any Vision, and so on.
Editing
The PO also refers to two other layers, DAL and Business, which nay are described by the MVC architecture, but need to be explained as well:
- DAL: Data Access Layer, or Data Access Layer. Typically they are represented in the form of classes that encapsulate SQL queries, or calls to some ORM library (such as Entity Framework, Nhibernate and Linq to SQL, in the case of . NET).
- [Business Layer] Classes of Service, which exposes the data obtained from the DAL to the upper layers, usually in the form of Dtos.
As I said above, from the point of view of the MVC architecture they are "sub-layers", belonging to the Model (but this does not make them less important, on the contrary).
Note: When both the Business and DAL layers are present (and only in this case), the first usually works as a gateway for the second. In other words, the DAL layer is accessed only by the Business Layer.
Not always I am obliged to have these two layers:
In simple CRUD MVC applications, where you just want to query, insert, edit and delete data, it makes no sense to have a Business Layer. For these cases, Model = DAL (and it is from there, I imagine, that comes the so common conceptual error that I mentioned above).
In MVC applications without persistence, it makes no sense to have a DAL. In this other case, Model = Business Layer (a typical example of this type of application is a calculator - the Business Layer would be represented by the variables and functions needed to perform the calculations).
Even in these "atypical" cases, the architecture is still MVC.
And that’s it! I hope I’ve helped.
DAL is an abstract language-free concept: Database Abstraction Layer
– hernandev