I disagree entirely. How data flows between the Model, View and Controller is NOT specified in ANY valid description of the MVC pattern, so for you to say that “it MUST be done in so-and-so way” is completely out of order. The MVC pattern merely defines WHAT nust be done in each of the three components, not HOW it must be done. The HOW also includes how data flows between the various components.
The MVC design pattern is infinitely flexible as it can implemented in many different ways in many differet languages, and even many different ways in the same language.
The only “rule” in MVC is that you must have separate components which handle the responsibilities of Model, View and Controller. Is is entirely up to you whether the resulting code is well structured or a pile of spaghetti
Your views on data flow in MVC are contradictory and confusing. You seem to say MVC doesn’t specify data flow but now you’re saying that without data flow MVC wont work. 
You were essentially saying “put the arrows anywhere, it’s still MVC”
So you see, the same data can pass through the Controller, the Model, the DAO and the View, but this does NOT mean that all the components share the same logic. The data access logic (program code) to transform the data to/from SQL exists ONLY in the DAO, not anywhere else. The display logic (program code) which transforms that data into HTML exists ONLY within the View, not anywhere else.
Ok you have data related to one specific view in a model that can be used by any number of different views Data that’s not needed by the model in the model? Not right (and you do have display logic as you need to work out the total number of pages…)
Again you are inferring too much by the arrows in the diagram. The data flows from the Model to the View, but it does not matter whether that data is pushed by the Model or pulled by the View. The mechanics of how the flow is actually performed are irrelevant as they are an implementation detail.
This is yet another straw man argument. As I’ve said all along (at least 3 times I believe). Push/pull is an implementation detail. What you’re arguing (the arrows can go anywhere, and that MVC doesn’t specify which components communicate) is a separate issue, you cant seem to see this distinction.
Wrong. The Model does not work out how many records or pages there are. These are variables which are determined immediately after the sql SELECT statement has been issued within the DAO. These variables are then passed through the Model to the View so that they can be displayed (or not) in some way. The fact that the DAO contains data that is transformed in the View most certanly does NOT mean that the DAO contains “display logic”. It is data, not logic.
The DAO is part of the model layer. You have display logic in your model (layer). You need to work out how many pages there are in total for the sole purpose of putting “page X of Y” in the view.
This control should be limited to where and how each field is displayed, but NOT which records should or should not be displayed, or the order in which they are displayed. The choice of which records to display, and their order, has already been determined by the Model/DAO.
Which is some nice display logic in your model (or DAO, which by the way, is part of the model).
I’m going to follow webaddictz’s advice. I’m not going to reply again in regards to the whole display logic in model thing is definitely an implementation detail and I don’t really think it’s useful to anyone now that we’re going around in circles. Especially since I’ve provided reasoning (ie drawbacks in your method) and all you’re doing is arguing seemingly irrelevant details (logic/data) and not back up your argument with actual reasoning (e.g. the benefits a model which contains variables that are required by a single view) and mixing two different issues into a single argument, which is not helping anyone, yourself included.
So you agree with me that MVC can have many different implementations, and not just one? Then you must disagree with TomB who is saying that only his implementaton of MVC is the correct one.
You are falling into a common trap. The definition of MVC is the same regardless in what language a particular implementation is constructed. MVC is a “design” pattern which simply identifies the function that each of the Model, View and Controller components needs to perform. How those functions are actually performed within a particular implementation is entirely up to the implementor.
I repeat, MVC is MVC regardless of whether it is for a desktop app or a web app. The programming language is also irrelevant - the implementations will be different, but they still implement separate components which can be recognsed as fulfilling the functions of Model, View and Controller.
In a (potentially futile) attempt to simplify this discussion I’m going to reply to as few of your points as I feel necessary. If you feel I missed something important please tell me
MVC clearly dictates that:
-Models should not know about the views or controllers
-Views have access to models
-Controllers can access models and views
Which looks like this:
(source: wikipedia)
You’re explaining MVC as if it’s this:
You still do not understand what “display logic” actually means. In a web application this means the code which generates the HTML which is passed to the client’s browser. If the Model does not generate any HTML then it does not contain any “display logic”.
This is not true. Display logic is anything related to, and only needed by presentation. This includes sorting and limiting. In your example the model is telling the view “Display these records” rather than the view asking the model for “these records for me to display”. The difference is subtle but important. Your model needs to work out how many pages there are in total. This is something used entirely for display purposes. It is display logic, theres no need for it to be in your model… and it needs to be in every model which uses the view rather than once, in the view.
That is just a bunch of data which is passing through, and in no way affects how the Model does its job. To the Model these are just variables which have no processing significance, so there is no “logic” attached to them.
It has to be in every model which uses the view. This is unarguably a cause of reduced reusability and clutter in the model. Imagine you have 100 views all with slightly different requirements, should they all have variables in the model which are used only by them?
What’s wrong with that? It is up to the Model to obtain data by whatever means necessary, and it is up to the View to display whatever data it has been given. Logic such as which colour is to be used in what circumstances comes under the heading “business rules” and therefore belongs in the Model. The Model makes decisions and the View implements those decisions.
The model should be view agnostic. It should be able to work with any view/controller without modification.
While my View may only display a subset of the fields on each database row, it does not filter out any rows it has been given. Every row is processed in exactly the same way. Nor does it sort the rows it has been given as they were pe-sorted in the DAO.
But you’re filtering out data here, there’s no reason the view shouldn’t be able to decide what it shows (it’s the views job after all), regardless of whether it’s a field or a record.
If I wish to change the number of columns which are displayed, or the order in which they are displayed, then I can change the View and not have to touch the Model. This is as it should be.
Nail/head. So changing the order of the fields is ok, but not the records. That’s at best inconsistent.
Imho, the view should have total control over what it shows.
webaddictz thanks for the link and explaination. sunwukung: Thanks for the breakdown. I’m sure I’ll find all of this fascinating and understand more as I get deeper into MVC. After reading this thread, I’m looking forward to it now and will have my own views to offer.
None of the definitions of MVC that I have have come across, including this one state how the data moves between the Controller, the Model and the View. They simply state the responsibilities of each of those three components and leave the implementation details to the implementor. The fact that your personal definition of MVC includes such implementation details is something that I can (and will) ignore with impunity.
Data is most definitely NOT accessed in the Controller. All SQL statements are the sole responsibility of the DAO, which is only ever accessed from the Model.
It is possible for new data to be sent to the Controller via the POST method, and for the Controller to inject this directly into the Model, which then tells its DAO to perform an sql INSERT.
Absolute rubbish! The View contains variables which identify the limit, offset and sort order required by the user. These pass THROUGH the Model to the DAO where they are added to the relevant sql SELECT statement.
The VIEW does NOT decide which records to display, or in what order. It simply displays ALL the records it is given and in the order in which they are given.
This is called pagination and is automatically built into each of my Transaction Patterns, so absolutely NO extra code is required. EVER.
I have the same functionality built into my framework, so it is available within every relevant screen automatically without the need for any extra code.
It IS different on the web. If the user changes any of the variables which affect limit, offset or order then the whole page is refreshed, which means that the DAO completely rebuilds its data according to the new variables, and the View displays this new data. The View does not manipulate the data in any way, it simply displays it.
It is ONLY the DAO which processes the limit, offset and order variables - they merely pass through the Controller and Model on their way to the DAO. The View must include some method of allowing the user the change the limit, offset and order variables, but it does NOT process them
My models are actually facades that call business layer object, which in turn calls a data layer object when necessary. The only thing those facades do is validate incoming data. They’re great for testing purposes.
That’s because it all comes down to personal programmer preference. The pattern doesn’t have any hard and fast rules; it just states that you separate your logic into three distinct tiers, namely Model, View and Controller. There have been countless discussions such as this one which always seems to lead to no specific point or a lot of posts that start with “I disagree”.
It’s not hard at all to get to know the principle of MVC; it’s finding a balanced implementation of that principle that you can both live and work with at the same time. For me, the View is a template engine that can do a lot of things to make my life easier, such as partials, helpers, layouts, slots, etc. The controller is a man-in-the-middle: it merely selects the view and controls the application flow.
The model is the weird kid in each project. Depending on the project, I may go with an implementation from a set of patterns, such as Transaction Scripts, a Domain Model or Table Data Gateway. If the business logic isn’t that complex, I tend to opt for a Transaction Script approach more and more often. If it is complex though, I tend to go for a Domain Model. If it’s an administrative-ish project (simply CRUD’ing data), I tend to go with a Table Data Gateway. You can find a rather decent article on the subject written by Martin Fowler on his website: http://martinfowler.com/articles/dblogic.html.
I let my view select the data from the model, that easier than using a middle man that doesn’t do anything with the data.
The flow is not same because if you look at all web based interpretations the controller acts as a layer between the model and view. When in reality the view should only directly communicate with the model on behalf of an event being dispatched that the view reacts to. The difference is significant considering the controller doesn’t mediate and pass data from the model to view in the traditional paradigm. Instead the view interacts directly with the model.
I think this is an interesting conversation about MVC albeit theory. Does anyone have a link to a tutorial with clean code examples, modeling and laying out the structure and control flow that’s being discussed here? I’ve learned PHP from the procedural method and am now moving to the OOP method and have been directed to the MVC model to help learn OOP. It seems to me that this conversation has taken on a feel of programmer preference rather than hard and fast rules of the MVC framework model. Does MVC framework have hard and fast rules that one should follow for good programming style and stability or is it flexible enough to get mangled up in to a twisted mess of spaghetti code rendering it unreadable and impossible for someone else to extend?
Which is why most web based interpretations are doing it wrong. argumentum ad antiquitatem and all that. There’s no reason the view shouldn’t directly interact with the model in a web based application.
You are most welcome. Some good advice from someone who has been in your position: some people always think their way is the only right way, but let me assure you, it’s not. Programming is about problem-solving and you can solve each problem in a lot of different ways. The best way to solve the problem is dependant on the problem, not some kind of puristic view of what you should use. Don’t let people get to you too much.
Well in MVC the view gets its own data from the model. Controller extracting from model and passing to the view is wrong, as we discussed in the last topic (linked in the first post). As for broadcasting changes, it doesn’t really apply to PHP since the view will be refreshed anyway.
Of course the Model should have state! It is changes in state which are reflected by changes to the View. If the Model is a database object then state is persisted in the database.
By state I meant a does the model contain a ‘current record set’. Selecting which records to show is clearly display logic (along with ordering and limiting). Basically whether the view requests a specific result set, or whether it requests the models current state. imho there are pros and cons of both.
emphasizing ALL of your KEY points like THIS is perhaps not helping
I think it is important to clarify that “Model” commonly has two meanings when discussing MVC.
In the general application sense of MVC, the Model is all the code is the layer separate from the Presentation layer (which contains all the View and Controller code). As adiian wisely points out, the Model should have no dependencies on the Presentation layer (i.e., View and Controller).
However, when talking about a specific PHP implementation of MVC, it is common to refer to the classes loaded for a given Request as the Model, View and Controller. There may be several classes of each type instantiated for a Request. As Czaries and TomB both mention, these Model classes can take many forms – from directly accessing the database to being more abstract Domain Model type classes. And different kinds of these Model layer classes can be used simultaneously in an application. What they have in common is that they are not Controller code (Request processing and program flow) or View code (Response generation).
So in the general sense MVC is about separations. However when discussing an implementation MVC is typically about classes.
You can see from this thread what a hornet’s nest this topic is!!
There are lots of concepts flying around here (with little in the way of practical definition IMO), so I’ll give it a shot:
Model - a broad term meaning an OOP representation of a Domain (be that a business, blog, NHS medical records…, airport timetable). The first thing is to not confuse the Model with it’s persistence methods - the means by which it records changes in the database
Entity - This term isn’t used very often, but it means an Object in the Domain, a Domain Object. So a User is really an Entity within the Model.
Service Layer - A layer of logic to co-ordinate interactions between Entities in your Domain Model, not a “thing” but the glue that helps “things” work together.
Data Persistence Design Patterns & Terms
- Table Data Gateway - a class for interacting with a single table in the database
- Transaction Script - a simple OOP wrapper for a set of pre-baked SQL calls.
- Active Record - an Entity class with hard coded (or inherited) persistence methods.
- Data Mapper - an object that queries the data source, and then creates maps that data into an Entity class
- DAO - Data Access Object: generic term for any object that accesses data, could apply to all of the above
- DBAL - Database Abstraction Layer: generic term for the layer of the application concerned with persistence
- ORM - Object Relational Map: generic term for OOP methods which abstract database interaction and generate Domain Objects of some description using any of the above methods.
A lot of the confusion relies on the blurred boundary between the Model and it’s persistence methods. You could generate Domain Entities/Objects using some of the methods above. You could just avoid the whole issue and avoid ORM altogether - which isn’t a crime(and in a lot of cases would seem advisable, given some of the shortcomings of ORM’s).
@Tony Marston
regarding the Domain Model - I’m talking perfect world - not the real world. Design patterns are nebulous concepts - as demonstrated by this (and hundreds of other threads). This polymorphous nature is one of the principle criticisms of OOP right? But, in a “perfect world”, the Domain Model would ideally be just that, a model of the Domain - and nothing to do with the framework in which it manifests. That’s highly unlikely - but a noble ideal nonetheless (along with decoupling, dependency injection… yadda yadda yadda).
+1 @webaddictz - good post
So what logic in each class separates them from another if the class itself doesn’t know about what fields its holding why need a separate class for each table, “other than to be neat”
Sorry if i missed the point :S
IMHO the model should be well designed to be decoupled. I would say the model should implement not only the persistence operations, but it should also define , encapsulate and implement the business logic entities. In the MVC pattern the controller is responsible for application logic and the model for business logic.
I would say that a well designed model layer should be decoupled well enough to be able to be reused in a non MVC pattern implementation.