Now that everyone is talking about MVC, I notice that the business rules are not being addressed. In the old days of the 3-tier architecture, The business rules were in the middle layer. Where do they fall in the new MVC?
+4
A:
A quote from a Wikipedia Article:
MVC is often seen in web applications, where the view is the actual HTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML. Finally, the model is represented by the actual content, usually stored in a database or in XML nodes, and the business rules that transform that content based on user actions.
gimel
2008-10-17 13:15:05
+9
A:
At first brush, I'd say they belong in the model. The MVC Entry on Wikipedia seems to agree: "In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data". After all, by 'Business rules' we mean the functional algorithms and logic that encode the domain that your application is involved with, as opposed to input/output related logic. These core business-related logic does not - or should not- change based upon what is being displayed to the user (which is the domain of the View) or the user input (which is primarily received by the Controller).
In my experience, asking this sort of question has been very revealing during the software development process: we found a large number of things that were considered 'business rules' by some people, but turned out to be something else. If it is not a true business rule, it might not belong to the model.
FOR
2008-10-17 13:15:57
+1
A:
Is there any reason why you cant mix MVC and Ntier? Our application does just that. Our controllers are used for data validation and decide which Business Layer calls to make.
OurApp.Web - Asp.net MVC Project
OurApp.Business - Business Layer Library
OurApp.DataAccess - Data Layer Library
OurApp.Entities - Basically all the 'models' shared by all layers
Vyrotek
2008-10-17 13:20:22
I like this approach. Unfortunately, I think many web frameworks make this leap an uncomfortable. At some point you might need helper objects in your business layer that don't necessarily correspond to any database tables / persistent storage - something that every model class I've seen seems to believe is a foundational thing. At that point you wonder, where well do I put this code?
Koobz
2010-05-13 00:23:54
+3
A:
Business rules always live in the model. The model is the bit that you could resuse with a completely different UI. The view is obviously completely dependent on UI choices and the controller has to take data from the model and tell the view to render it.
Putting business logic into the view is bad because it ties the structure to the presentation.
Putting business logic into the controller is bad because it splits your business domain between the data persisted by the model and the rules in the controller.
domgblackwell
2008-10-17 13:22:11
+5
A:
The reason you never see MVC address "Business Rules" is that MVC by and large is a presentation pattern. It's focused on how to structure your application. The Model, for example, can be thought of as a presentation model. The model of your application, which the view then renders.
However, in order to create the presentation model, you generally need to go to your domain models where all your business logic lives. At that point, MVC doesn't dictate where that code physically live. Is it on another tier? MVC doesn't care.
Haacked
2008-10-17 16:42:19
A:
You guys are wrong the business rules live within the controller and not the model...
This comment is just plain WRONG. The controller is a technical part of the application that orchestrates the data flows and triggers actions in the model and the view. In a typical PC application the controller is concerned with mouse events, keystrokes and similar types of things.
Michael Dillon
2009-12-10 14:52:23
A:
Business rules should be in the model, NOT the controller. The controller and view are part of the presentation layer.
The model represents the domain's entities and functionality ..
The controller is merely a manager for taking user input and requests, performing actions in/on the model and mapping that to views in the presentation layer. The controller is not just a mediator either, the view OR controller may act upon the model.
Logic Labs
2009-10-01 09:03:58
I think that a lot of people implicitly think of the model as the "database model" which is why business rules don't seem to have a place. If instead, you see the model as a simulation of something from the real world, then it is obvious that the business rules are as much a part of the model as the data that they manipulate.
Michael Dillon
2009-12-10 14:54:20