The main idea behind OOP is to unify data and behavior in a single entity - the object. In procedural programming there is data and separately algorithms modifying the data.
In the Model-View-Controller pattern the data and the logic/algorithms are placed in distinct entities, the model and the controller respectively. In an equivalent OOP approach shouldn't the model and the controller be placed in the same logical entity?
MVC is an exercise in Separation of Concerns, a UI architecture. It is a way to corral the complexity that can occur in user interfaces due to the presentation not being separated from the content.
In theory, all objects can have behavior that operate on the data they contain, and that data and behavior remain encapsulated. In practice, a given OOP object may or may not have logic that corresponds to its data, or may not have any logic at all (a Data Transfer Object, for example).
In MVC, the business logic goes in the model, not the controller. The controller is really just a go-between to glue together the View and the Model. So in the model, you can have data and behavior in the same place.
But even that arrangement does not guarantee strict data/behavior fusion. Objects containing only data can be operated on by other classes containing only logic, and this is a perfectly acceptable use of OOP.
I'll give you a specific example. This is a bit contrived, but let's say you have a Currency object, and that object has the ability to represent itself in any available currency, pegged to the dollar. So you would have methods like:
public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }
...and that behavior would be encapsulated with the Currency object.
But what if I wanted to transfer the currency from one account to another, or deposit some currency? Would that behavior also be encapsulated in the Currency object? No, it wouldn't. The money in your wallet cannot transfer itself out of your wallet into your bank account; you need one or more agents (a teller or ATM) to assist in getting that money into your account.
So that behavior would be encapsulated into a Teller object, and it would accept Currency and Account objects as inputs, but it would not contain any data itself, except maybe a bit of local state (or maybe a Transaction object) to help process the input objects.
Teller be placed in? In the Controller from where the Teller's methods are called or in the Model because it's part of the business logic?
Teller goes in the Model, although it could be called from the controller. It's part of the business domain.
Commented
Oct 11, 2012 at 14:21
MVC works at a much higher level of abstraction than single objects, and in fact each of the three (model, view and controller) will typically consists of many objects that each have both data and behavior.
That objects which encapsulate data and behavior are a good fundamental building block for programs in general doesn't mean it's the best pattern at all levels of abstraction and for all purposes.
OOP does not restrict interactions among objects that each have their own data and their own behavior.
Think of an ant and an ant colony analogy: behavior of an individual ant (run around all day, bringing food) is different from behavior of the overall colony (find the most desirable place, make more ants). The MVC pattern describes the desired social structure of an ant colony, while OOP guides the design of individual ants.
OOP is also about Separation of concerns, that is to separate different roles/responsabilities in different objects.
MVC separates into these components :
So these responsabilities are clearly distinct and should indeed be separated into multiple entities.
Product only dealing with Product, it's really about subject
In the Model-View-Controller pattern the data and the logic/algorithms are placed in distinct entities, the model and the controller respectively.
Model and controller are two distinct roles. A model has both state and logic, and a controller has both state and logic. The fact that they communicate doesn't break the encapsulation of either one -- the controller doesn't know or care how the model stores its data, or what it does to the data when the controller retrieves or updates some part of it. The model doesn't know or care what the controller does with data that the model provides.
Think of it this way: if objects couldn't pass data back and forth without breaking encapsulation, you could really only have one object!
In an equivalent OOP approach shouldn't the model and the controller be placed in the same logical entity?
MVC is an OOP approach -- specifically, it's a recipe for deciding how to use objects to organize a program effectively. And no, the model and controller shouldn't be the same entity. A controller allows separation between model and view. Keeping model and view independent of each other makes them both more testable and more reusable.
MVC is a pattern which describes a sensible way for objects to interact; it is not itself a meta-class. At that, OO is about describing behaviours and data of entities, and how said entities interact. It isn't about unifying the entire system into one massive object.
Controller does not represent the behavior of a model. Controllers altogether represent the behavior of the whole application _ what a user can do and what a user can see.
It is wrong to view controllers and models as one. They have different purposes, different semantics and thus shouldn't be unified in one object.
The model layer is not merely data any more than the controller layer is merely logic.
The controller layer will have a complete collection of objects for its purposes. There will be objects for receiving input from the view, and from transforming that input into a form the model can process. The Struts Java framework has a good example of this in its Action/Form model. The Form is populated with input from the user, and then passed to the Action. The Action takes that data and uses it to manipulate the model.
In the same way, the Model layer doesn't consist entirely of data. Take a User object, for example - you may need code that gets a user from a database, or code to associate a User with an Order, or to validate that the User's address is within the area your company services...you get the picture. This is not controller logic. It's business logic, and it's led many to split their Model layer into several layers such as Service or Manager layers for business logic, a DAO (Database Access Object) layer for database access, and others.
MVC isn't a method for organizing individual Model operations. It works at a higher level than that - it's a method for organizing how the application is accessed. View is for presenting data and human actions for manipulating it, Controller is for translation between user actions and the various views, and the Model is where business data and the business reasons for it to exist reside.
The point of OOP is to group together data and functionality that belong together. A calculation that is based on some piece of data does not always belong with that data.
In MVC the functionality to display a piece of data (view) is kept separate from the data (model). Why is that? It's specifically so that the display logic can be changed without having to change the underlying data. It makes it easy to change the view whenever you need to make a different presentation of the same data: or when the characteristics of the display hardware change: or when you switch from Windows to Linux; or when you want two people to have two different ways of looking at the same data.
MVC isn't in conflict with OOP - it is actually derived from a correct application of Object Oriented Principles.
I believe you're confusing persistent data bound to a model object with the application data from the databases the model interacts with. A model contains business logic and rules for working with databases and conducting transactions. It might set and check internal state flags like whether there's a sale today, whether the user qualifies for VIP status and then branch logic accordingly when it comes time to access, set, or manipulate data or conduct a purchase. It's those flags we're talking about when we discuss objects in terms of encapsulation of a set of methods and persistent values or data.
Just as the model object maintains data for establishing what business rules are in play, a controller should, IMO, hold on to more general application state data pertinent to how the app should behave, like whether the user is logged in or they have valid credit card data in place. Model methods would determine the state of these things in the first place but it makes sense for the controller to maintain flags pertinent to general app flow if they don't apply to how the business is run or data transactions are conducted. Once you've determined they're not logged in, don't even bother the model with user state checks until it's clear another log-in attempt is being made.
Likewise with a proper view object vs. the more typical HTML templates you see in most server-side web frameworks. Once the user's color preferences are loaded up, it should be the view that holds on to that data and executes on it. Loading, validating and changing settings are all model problems but they should only be model problems once until changes happen.
IMO, nothing says controllers can't be composite objects with views and models as internal aggregate objects. This actually makes sense if you apply MVC on a smaller scale like a UI widget factory since the controller is the ideal place to expose an interface to higher level app objects while burying the data and logic details of how the View and Model interact. It doesn't really make sense for monolothic app objects where the controller is really the highest level object though.
As I understand it; The argument is component based architecture vs OOP. And without getting into the religious war, I think that they are both describing the same thing; just looking at it from different angles.
For example, the whole point of OOP/OOD is to make your code more modular and reusable. Yes?
Which is exactly the goal of component based architecture. So they are more alike than anything else.
I think that MVC is just the natural evolution of OOP and dare I say it; a better way to organize your objects, separation of concerns and code reuse.
I am late to this party, and considering all the answers before mine, I admit I don't have much new to offer. But it seems to me that the question isn't about the pattern itself but about the implementation. MVC in and of itself does not lend itself to any particular methodology. In fact, I can easily envision procedure oriented code in an MVC pattern (which is what I felt like you were implying).
So, I think the real question is; are we more prone to procedural code when using the MVC pattern.
(and maybe I'll just get some down votes?)
Not anti, but also OOP is not required for MVC.
Because controllers, which are usually represented by classess hold no data. For which pure functions would suffice.
If you go further and separate data from behaviour, for example let's say that models work only on database data, which they fetch every time their function (that is responsible for data manipulation) is called (instead for storing some kind of data in the instance fields) - then you can say the same for the models.
Going further, if you take the view layer of an application and divide it in similar fashion, you will actually end with conclusion that MVC has nothing to do with OOP, and it is completely possible to write MVC implementation without any pain using only procedurall approach.
In my Opinion OOPs has a drawback that since the (data and behavior) are moulded as one entity(Class) this shows more coupling effect than cohesion. Whereas on the other hand MVC it has Model containing...(Beans, DAOs, Other Logic classes), Controller that specifies how the control must travel and Views to determine how the data should be shown are given in a seperated fashion. Based on this no matter if the project is Too big to prepare can be easily made as seperate entity other than getting mixed unlike OOPs. The problem is solved in logical pattern just like divide n conquer strategy and MVC follows this atmost.
