Where are the Business Rules in MVC

Question

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?

Biskra

So? Quicksort is 46 years old and still being used. The important thing is that it works very well. – Antibaryon

I noticed the same thing a few years ago. It seemed like as soon as I learned it, it started popping up everywhere I looked. – Mulligan

Answer 1

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.

Rewrite

The model though should NOT be in the MVC project and it should not have dependencies on any particular UI technology. – Sapanwood

Answer 2

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.

Levana

Answer 3

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.

Storage

Answer 4

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.

Cholera

That is not MVC. MVC is about organizing code. All dynamic webpages would be MVC by your definition. – Laughable

Answer 5

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

Sapienza

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? – Astred

Answer 6

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.

Genni

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. – Crotty

Answer 7

This is an anciently posted question, but I like a rules repository to be completely independent of any part of an application. Multiple applications, multiple implementations of a business tier, should be able to access a static rendering of a business rules repository. Simple separation decisions such as this make a migration from desktop -> web, for instance, trivial.

In my architecture, View -> Model -> Controller -> Business Tier -> Rules Repository, i.e. the controller accesses coarse data as presented by the business tier/layer, feeds it to the model which massages it into a presentable form, and the view passively displays it. The business tier, which is re-usable across any presentation format, will have explicit rules and access to a subsystem with implicit rules. By design, each component is ignorant of the details of a component above it.

Oftentimes

Answer 8

I think the issue is a matter of definition. It seems to me that the logic for presenting the screens in the order needed is a controller issue and I have seen some projects that use a rules engine to determine the order and what is required input from the user. This is not the same as business rules imho.

Sartin

I believe OP is talking about business logic which belongs to model. – Weatherproof

Answer 9

You guys are wrong the business rules live within the controller and not the model...

Riches

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. – Crotty