13
Assuming a project with these layers: DAL, Controller, Negocio, Model and View
I’m trying to learn C# seeing ready-made project codes, but not quite understood yet the correct order of creation and their dependence on each other.
I’d like to know how that gear works. I realize that if you forget a piece it won’t work, so I’d like to know what each of those layers is for.
Could someone give me a brief explanation?
13
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 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:
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:
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.
Congratulations on the friendly response. Very didactic and enlightening. Helped me a lot and will help other people for sure. + 1 and Best Answer. Thank you.
In fact what is TDD?
TDD - Test Driven Development, or Development Oriented to Tests. A style that is talked about a lot, but not used so much. : ) Still, it’s a very important thing to know: learning to use TDD makes you a better programmer, in my opinion (even if, because of the employer’s fault, we often can’t use it, but this has improved).
The only thing I disagree with is putting business rules, which are not related to the model, within this layer, but otherwise, in my opinion, your answer is perfect.
@Betasystems-Rodrigoduarte: without wanting to repeat myself and already repeating myself, what I did was describe what the MVC architecture is. That’s how she is. You may, for example, find it necessary to have a separate business layer from the data access layer, and I agree!! But this is not described by MVC. And, in practice, it also does not escape from it: the Model should be seen as a "super-layer" that contains the sub-layers of data access and business rule, perfectly separated as is the custom nowadays.
@Betasystems-Rodrigoduarte I made an edition in my reply, inspired by your comment. I know you don’t agree with the way I described the Model, but I hope I can be more convincing now! :)
@rsenna, got much better the explanation, but still add that in the business layer, would be all business rules pertaining to the application, and in the model layer, Model , would be the respective belonging the models themselves, as validations and related... About your first answer, it is more theoretical than practical, so I agree with you... It took me a while to understand this. :)
Very good answer, it is also interesting to define well what are the rules of Business (responsibility of Model + DAL) and what are the rules of the View layer (responsibility of the Controller).
9
Assuming you’re talking about C# for Web and ASP.NET MVC, the way to understand the layers of the system would be:
These layers can be seen in the order I exemplified, with the top closest to the user and the bottom closest to the system/machine.
Information should always run from the bottom up and requests/actions from the top down. Also the layers should not depend on a layer above it. Whenever necessary the dependency is a layer depending on the layer just below it, without skipping.
Just to make a comparison. I always learned (in Java/Struts) that Model = Business, because it contains the modeling of business objects. That the flow control done by the Controller should not include specific business flow. That DAL is different from model for the reason already mentioned. And the model can eventually be displayed in the form of services, made available to the controller. The View part is equal.
@Piovezan No Java/Struts you have the JavaBeans which are used for Model os Business Logic Beans, the System State Beans and the Action Form Beans. The model is not pure MVC and the Beans have mixed functions if we look at the traditional Mvc model, so there is this difference that you talked about. Newer Java frameworks, other than Struts, have these functions more separate from the traditional form.
Wow. I’m sorry, but this answer is not correct. To say that "Model/DAL: does not contain business rules" is, in my opinion, absurd: the Model is precisely the layer that should contain (among other things) the business rules! What you’re suggesting (keeping the business rules in the Controller) is usually called a "fat-controller" and is now regarded as a anti-pattern.
What are the other things that should be contained in the Model? And if so, what is the role of the Controller?
I can not answer in the form of comments. : ) I will add an answer here, wait a minute.
Take a look at this: http://joncairns.com/2013/04/fat-model-skinny-controller-is-a-load-rubbish/ http://stackoverflow.com/a/14045514/412426
If this is how you are talking, it is better not to use MVC and use a 4-layer model where one of them is the one who has Business. Model is persistence, period. For reasons of interoperability and portability they should have nothing other than persistence code and data agglomeration.
@Alexandremarcondes: no, it is not "end point". I understand that you think so (it is a fairly common error) but this view does not correspond to the formal definition of Model-view-controller. MVC has been around for decades, not a web phenomenon. Anyone developing Objective-C for OSX, for example, probably uses MVC for desktop applications.
@Alexandremarcondes: (and the link you actually passed agrees with what I’m saying - "Domain Objects" are business classes).
@Alexandremarcondes: Opa, just now I noticed that you sent two links. What I said goes to the according to. The first, in fact, it’s just another Ruby programmer thinking that MVC was invented with Ruby on Rails. :P He makes a common mistake in this community: thinking that Model is the same as "Active Record". The comments of Albert, of 15/04/2013, and Marnen Laibow-Koser, of 30/06/2013, translate well what I am trying to say.
6
Your application should solve a business problem. Following this thought development should start at the Business layer.
Given the above options, with the Business layer ready, you could go to your presentation layer (Asp.Net MVC):
Create Controller (interprets user actions and maps them to Model calls).
Create Model (represents the application data that will be displayed in the View).
Create the View (user interface and in general is created from the Model).
During presentation layer development (Asp.Net MVC), you will need to recover/write data, so as you need methods that will recover/write data you will develop DAL.
In short, you can start the development by the Business layer, following the following sequence:
Business > Presentation Layer (Controller > Model > View) parallel to your Infrastructure layer (DAL).
3
Your question is too broad for a simple answer here, but the ideal would be:
Modelo -> Dados -> Negócios -> Controller
If there is a need to distribute, a layer of this type:
Modelo-> Dados -> Negócios -> API/Serviço -> Controller
Try abstracting in interfaces not to generate dependencies of concrete types, for example, in the layer of Negócios, work with layer interfaces Dados and in the Controller with layer interfaces of Negócios. This will facilitate component exchange in the future if needed.
There is a project called Sharp Architecture, that has an example architecture between layers and injection of dependency, good practices in software development, it is worth taking a look.
Browser other questions tagged c# asp.net-mvc mvc
You are not signed in. Login or sign up in order to post.
DAL is an abstract language-free concept: Database Abstraction Layer
– hernandev