The MVC's model

[Tony_Marston]

@TomB

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)

I’m afraid it is YOU who is inferring too much from the arrows in that diagram. The MVC pattern requires at least three components, the Model, the View and the Controller, each of which has its own specific responsibilities. The same data can flow between each of these components and is processed differently within each. HOW the data flows, whether it is pushed or pulled, or who does the pushing or pulling, is NOT specifed in the pattern. That is an implementation detail.

@TomB

You’re explaining MVC as if it’s this:

No I’m not. There’s no data flow in that diagram, so it simply won’t work.

@TomB

This is not true. Display logic is anything related to, and only needed by presentation. This includes sorting and limiting.

It is quite clear that you do not understand the difference between DATA and LOGIC.

DATA is just a collection of variables which may hold different values at different moments in time.

LOGIC is the program code which acts upon, manipulates or transforms that data in some way.

Thus in a web application the “display logic” is that code which transforms that data into HTML. The fact that some or all of that data has also passed through other components does NOT mean that those other components also contain “display logic”. They share data, yes, but not logic.

In a database application the Model may use a separate Data Access Object (DAO) in order to communicate with the database. This is where the data is transformed into SQL, or where and SQL statement provides data.

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.

@TomB

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.

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.

@TomB

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.

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.

@TomB

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?

I do not tailor each of my table classes so that it only contains the variables which the current View actually needs. This “tailoring” would create an enormous programming overhead which I personally would find unacceptable. Instead each table class creates whatever variables are appropriate to the current operation, then it hands ALL those variables to the View for transformation into HTML. How the View deals with those variables is of no concern to the Model.

@TomB

The model should be view agnostic. It should be able to work with any view/controller without modification.

If you bothered to read what I wrote you will see that I have already achieved that within my framework. Any table class (Model) can be used, without modfication, by any Controller and any View.

@TomB

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.

I disagree. It is not the View’s responsibility to filter out records, or to sort those records into a particular order. After the records are transferred from the Model to the View it is the View’s repsonsibility to display all of those records in the order in which they were given.

@TomB

Nail/head. So changing the order of the fields is ok, but not the records. That’s at best inconsistent.

Not in my opinion. It is far more efficient, and requires less code, to have the data sorted within the sql SELECT statement. The fields may come from the database in a totally random order, but the View can position each of those fields wherever it likes. I don’t have to change the sql statement in order to change the order of fields on the screen.

@TomB

Imho, the view should have total control over what it shows.

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.

[Tony_Marston]

@TomB

Well that’s a nice tautology but it’s those responsibilities that are the issue here. If the controller is calling an action on the model and passing the result to the view it’s not MVC. Perhaps mediator is too vague but in MVC the model is accessed by the view. If not it’s by definition, n-tier rather than MVC. I don’t even understand why this is even being questioned. MVC clearly dictates how data flows between the model view and controller. See your own diagram in the link you provided.

I disagree. The MVC design pattern does not dictate the mechanics of how the data flows between each of the three components, it simply identifies the responsibilities of each of those components and leaves the actual mechanics, the implementation details, up to the individual programmer.

@TomB

Then your model needs to be set up in a specific way to work with the view. This is display logic. How many records to display? Display logic, how they should be sorted? Display detail which should be of no relevance to the model.

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”.

Look at the case where the instruction from the user is “give me 10 database rows starting at page 3”. This is NOT data access logic. The page size and page number variables are just pieces of data which are captured in the View, passed to the Controller, through the Model to the DAO. It is ONLY when the DAO actually uses these variables to construct and execute an sql SELECT statement that there is any data access logic. “Logic” requires program code to process a variable, not simply to pass it down (or up) the chain of command.

@TomB

This inadvertently breaks the principles of MVC. The model essentially now knows it’s part of paginated data and has to be set up in such a way to cater for that specific view (knowing the total number of pages, records per page, etc)

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.

@TomB

The fact that they’re contained within the model is enough. You’re setting up the model to work with the view, rather than having a view which works with (usually an existing) model. Different views will need different things. Another view may need different, yet relevant, data. It may not have need for “number of pages” or anything you have put in the there to cater for a specific view. The net result is large, unwieldy models which become hard to maintain.

Your Model classes may be unwieldy and hard to maintain, but mine are not. Each one of my Model classes is capable of working with any View without modification. This is because each concrete table class inherits a large amount of code from an abstract table class.

@TomB

Should the model:

-Decide which colour to make a background based on a record attribute (e.g. status code)
-Tell the view how to handle exceptional cases (no records to display)
-tell the view whether it should display an error message or the result set

The Model may attach a CSS class to a column name, but the specifications of that CSS class are held outside the Model (in a separate CSS file). The colour which is actually used in the View is therefore outside the control of the Model.

When it comes to record sets or error messages, the View does not decide which to display, it simply displays whatever it has been given by the Model. If it is given a record set, empty or otherwise, it displays that record set. If it is given one or more error messages, then it displays those messages. It does not decide what to display, simply how to display it.

@TomB

Clearly this is all display logic (along with number of records, ordering, etc). If you put this in the model, you’re coding your models around how they’re going to be displayed instead of how they should behave and what data the contain. Your model is essentially telling the view what to do.

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.

@TomB

You’re giving your model control over the output. The model should not be concerned with how it could be presented. By putting things like “maximum number of pages” into the model you’re doing exactly this and creating a very firm contract between a model and a view, severly reducing reusability. (any model now needs to fulfil this contract to use the view)

The Model obtains data from somewhere, applies business rules which may generate additional values, messages or colour suggestions, and passes them to the View. As such the Model does control what is displayed (that is its purpose after all), but it is the View which constructs the output, which could either be HTML or PDF.

@TomB

Lets put it this way: should the model decide which fields the view should be showing? it’s the same issue. It’s likely in your system, the model contains a record set. Sometimes you don’t want to display all fields. Do you always want to show every field from a record? No you often want to only display some parts, even though the view could show them, it doesn’t. Congratulations your view is already filtering the data it’s receiving. It’s no different taking a subset of data from a record set, than a subset of data from an individual record.

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.

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.

[TomB]

@Tony_Marston

If I have three components which perform the responsibilities of Model, View and Controller as defined in the MVC design pattern, then that IS MVC whatever anyone says.

Well that’s a nice tautology but it’s those responsibilities that are the issue here. If the controller is calling an action on the model and passing the result to the view it’s not MVC. Perhaps mediator is too vague but in MVC the model is accessed by the view. If not it’s by definition, n-tier rather than MVC. I don’t even understand why this is even being questioned. MVC clearly dictates how data flows between the model view and controller. See your own diagram in the link you provided.

No I’m not. Logic implies code which manipulates the variables to produce some result. The variables for offset, limit and order simly pass THROUGH the Model to be processed by the DAO, then sent back to View where they can be displayed to and altered by the user.

Then your model needs to be set up in a specific way to work with the view. This is display logic. How many records to display? Display logic, how they should be sorted? Display detail which should be of no relevance to the model.

This inadvertently breaks the principles of MVC. The model essentially now knows it’s part of paginated data and has to be set up in such a way to cater for that specific view (knowing the total number of pages, records per page, etc)

The View does not sort the data as this has already been done by the DAO. The View does not extract a subset of the data from the Model, it deals with ALL the data currently contained in the Model.

The current/highest page numbers are not processed in any way in the Model, nor do they affect the processing of any business rules within the Model. They are simply variables which are passed down to the DAO and back up to the View.

The fact that they’re contained within the model is enough. You’re setting up the model to work with the view, rather than having a view which works with (usually an existing) model. Different views will need different things. Another view may need different, yet relevant, data. It may not have need for “number of pages” or anything you have put in the there to cater for a specific view. The net result is large, unwieldy models which become hard to maintain.

I don’t have to, no, but I’m perfectly within my rights to do so.

But it’s way beyond the scope of this discussion.

Then your definition of “display logic” is seriously flawed. Identifying what needs to be displayed is totally different from building the actual display, which in a web page is the HTML document. The Model tells the View “please display this message” and the View generates the necessary HTML to perform that task.

If the Model generated any HTML then that would be “display logic”.

Should the model:

-Decide which colour to make a background based on a record attribute (e.g. status code)
-Tell the view how to handle exceptional cases (no records to display)
-tell the view whether it should display an error message or the result set

Clearly this is all display logic (along with number of records, ordering, etc). If you put this in the model, you’re coding your models around how they’re going to be displayed instead of how they should behave and what data the contain. Your model is essentially telling the view what to do. You’re giving your model control over the output. The model should not be concerned with how it could be presented. By putting things like “maximum number of pages” into the model you’re doing exactly this and creating a very firm contract between a model and a view, severly reducing reusability. (any model now needs to fulfil this contract to use the view)

Lets put it this way: should the model decide which fields the view should be showing? it’s the same issue. It’s likely in your system, the model contains a record set. Sometimes you don’t want to display all fields. Do you always want to show every field from a record? No you often want to only display some parts, even though the view could show them, it doesn’t. Congratulations your view is already filtering the data it’s receiving. It’s no different taking a subset of data from a record set, than a subset of data from an individual record.

[sunwukung]

I disagree with both of you. You more than him.

@Tom - I don’t think you should issue data manipulation from the View, but you can interpret data there.

@Tony - we’ve discussed the role of the controller as a staging post for view variables elsewhere - and this is a facet of n-tier or two-step transform (which are not exclusive from MVC)

@both It’s meaningless to validate our interpretations of MVC via the fact that it “works” in our own application design. An application can work, but still be riddled with anti-patterns. Anti-patterns don’t break applications, they just make development trickier. Discovering an anti-pattern in our own work can take quite some time (and humility). It’s a classic example of pattern-itis, theory getting in the way of practice. Tell me which of the main frameworks is practising the TRUE MVC (not that it matters, if the application works…oh the irony)

@Tony I think it’s pedantic (unedifying) to be quibblling like this, which is NOT helped by this kind of text formatting (or multiple posts).

[Tony_Marston]

@TomB

I never said anything about MVC stating “how” the data is passed around. Only that it does specify which components interact with each other and which way the data is going… the data flow.

From that exact page:

"A view queries the model in order to generate an appropriate user interface […]. The view gets its own data from the model. "

“The view gets its own data from the model” is the major point here. Whether the View “pulls” the data out of the Model, or the Model “pushes” its data to the View is an implementation detail. You could even have the Controller “pull” from the Model and “push” to the View, but who cares? That the data flows is important, but the actual mechanics are an implementation detail.

@TomB

This is describing data flow. Which parts of the system should communicate with each other.

The data flows between the three components, yes, and each component deals with that data in its own way. But whether the data is “pushed” or “pulled” between those components is an impementation detail and not a requirement of the MVC pattern

@TomB

This is certainly not anything which is defined by MVC: such implementation details is something that I can (and will) ignore with impunity.

In my initial post I mentioned that there are differing opinions on this both with advantages and disadvantages. They are, of course, implementation details.

Yes, there are lots of different opinions. I am simply expressing mine. There are different advantages and disadvantages with each implementation, but my implementation is no worse than any other - provided that you measure by results and not purist “theory”.

@TomB

If your model is a list of ‘current’ records it causes several problems:

At any instance in time the Model only contains those records that are required in the current iteration of a particular transaction. It most certainly does NOT contain all available records which then have to be filtered and sorted by the View.

@TomB

By putting the display logic in the view (a crazy concept I know) your view can query the model to find out the total number of records and easily display “page X of Y”. If you’re using the model as a complete data set, how does the view get the total number of records (to work out the total number of pages).

The View does not contain any logic (program code) which manipulates the data it has been given. It is simply given a bunch of variables which it displays. Amongst these variables are one or more database records, current page number, highest available page number (as provided by the DAO), and any other piece of information which it may require.

@TomB

Performing a count on the model should return the number of records it contains. You could add a getTotalRecords() to the model which applies its current filter to a count query, but this has changed the models responsibility. It is no longer a ‘complete’ data set an you’ve essentially introduced the concept of a page (which is display logic) into the model.

The Model does not apply any filters to the sql query - it simply passes all the necessary variables to the DAO which then builds them into the SELECT statement which it then executes. The total record count, total page count and current page number are variables which are set in the DAO and passed through the Model to the View.

@TomB

With the view getting specific records from the model, it can also very easily do: “No records were returned by your search: here’s some you may be interested in”, which again is display logic.

Wrong. The View does NOT decide which error message to display, it simply displays whatever messages it is told to display by the Model. The Model may have different messages in different circumstances, and they may be in different langages.

@TomB

The model should act as a complete data set. It should contain everything needed by the view.

That is certainly the case in my implementation, but it does not contain more data than is required by the View.

@TomB

Sure, you can move all this stuff into the controller, but then you have fat controllers containing non-reusable display logic.

None of my Controllers contains any non-reusable code, and none contains any display logic (or even any business logic for that matter). The Model decides what information needs to be displayed, and the View deals with how.

[arborint]

Honestly, this guy has been confusing people for years. I can really think on no one comparable. Legendary. He still doesn’t seem to understand what those little arrows on all those diagrams mean. It is a shame that a someone that verbose gets some many things half-wrong.

TomB does have a lot of useful information for the OP, but they will have to wade through pages of other nonsense to find it.

[TomB]

@Tony_Marston

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.

I never said anything about MVC stating “how” the data is passed around. Only that it does specify which components interact with each other and which way the data is going… the data flow.

From that exact page:

"A view queries the model in order to generate an appropriate user interface […]. The view gets its own data from the model. "

“The controller notifies the model of the user action”

This is describing data flow. Which parts of the system should communicate with each other.

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 certainly not anything which is defined by MVC: such implementation details is something that I can (and will) ignore with impunity.

In my initial post I mentioned that there are differing opinions on this both with advantages and disadvantages. They are, of course, implementation details.

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

the following is completely implementation details and not really relevant but I feel I should respond

Of course, the only thing I’m arguing here is that the view should call:

$model->getRecords(101, 200);

Rather than just $model->getRecords();

If your model is a list of ‘current’ records it causes several problems:

By putting the display logic in the view (a crazy concept I know) your view can query the model to find out the total number of records and easily display “page X of Y”. If you’re using the model as a complete data set, how does the view get the total number of records (to work out the total number of pages). Performing a count on the model should return the number of records it contains. You could add a getTotalRecords() to the model which applies its current filter to a count query, but this has changed the models responsibility. It is no longer a ‘complete’ data set an you’ve essentially introduced the concept of a page (which is display logic) into the model.

With the view getting specific records from the model, it can also very easily do: “No records were returned by your search: here’s some you may be interested in”, which again is display logic.

The model should act as a complete data set. It should contain everything needed by the view.

@http://www.phpwact.org/pattern/model_view_controller

The view generally have free access to the model, but should not change the state of the model. Views are read only representations of the state of the model. The view reads data from the model using query methods provided by the model.

Sure, you can move all this stuff into the controller, but then you have fat controllers containing non-reusable display logic.

[sunwukung]

You two wanna get a room?

Seriously - how is this debate helping the OP? You simply have to look at any framework (No, not your wunder-framework Mr.Marston) to look at the different implementations of “MVC”.

[Tony_Marston]

@arborint

In the strictest version, the Model has no dependencies, the View is only dependent on the Model, and the Controller can have dependencies on both the View and Controller.

That’s a load of techno-babble. The MVC pattern contains three components with specific responsibilities, and how the data passes between components, and hence any dependencies, is a separate implementation detail which is NOT specified in the pattern

@arborint

However, more common now is Fowler’s take on the pattern where the View and Controller are clearly in the Presentation layer and can have dependencies on each other, and any code in the Presentation layer (View+Controller) can have dependencies on the Model.

I agree 100%, as witnessed in my FAQ26.

@arborint

I should note for the nitpickers that it is sometimes necessary for the Model layer to have dependencies on the Presentation layer. Reality is not as clean as theory. You can find some discussion about these exceptions and good ways to handle them around the web.

I do want to reiterate Fowler’s comment that MVC is TWO separations (not three). The first, and most important, is between the Model layer and the Presentation layer (View+Controller). The Model should not have any dependencies on the Presentation. Get that right and you are 90% of the way to a cleaner application. Hopefully that independence should help guide the OP in implementing Model classes.

The second separation is between the View and the Controller. It is less important and much more controversial – so more often argued. I think as long as you draw a consistent line between the two in you application you will be ok. If you can keep the View independent of the Controller you will get some benefits. If you can keep your Controllers skinny, even better. These are lessons learned by the trial and error of many programmers over the years.

This is more techno-babble. I have seen too many arguments on what “dependency” actually means, and far too much hair-splitting on miniscule details.

There has to be certain levels of dependency between each of the three components, otherwise they simply would not work together. In any individual transaction there is a particular Model, a particular View, and a particular Controller. These have to work together in order to carry out the functionality of that particular transaction, so there is some dependency. Low dependency is good, while high dependency is bad.

In my framework I have low dependency. The Views have been implemented as a small group of XSL stylesheets (about 12 in all). I have about 40 predefined and reusable Controllers. Each Controller uses a single VIEW (some do not have any View at all), but a particular View can be used by more than one Controller. My Model is comprised of a separate class for each database table and any of these classes can be used by any Controller.

I have actually paired each Controller with its particular View (XSL stylesheet) into a catalog of what I call Transaction Patterns. In my framework I have the capability of generating a transaction simply by saying “link pattern X with table class Y”.

A particular Controller is not dependent on a particular Model (table class) as any Controller can be used with any Model.

A particular View is not dependent on a particular Model (table class) as any View can be used with any Model.

A View can be used by any Model, and a View can be used by more than one Controller.

The only real limitation is that a particular Controller can only use a particular View (XSL stylesheet).

That’s what I call “low dependency”, and should be perfectly acceptable in anyone’s book.

[TomB]

@sunwukung

You two wanna get a room?

Seriously - how is this debate helping the OP?

I do think it’s a legitimate discussion regarding different implementations. At least it’s (somewhat) related to the original topic. We are discussing model implementations after all.

[Tony_Marston]

@TomB

Actually it’s this distinction which separates MVC from other architectures such as N-Tier. The controller acting as a mediator is not MVC. Push/pull certainly are implementation details but your argument here is a straw man.

I DO know the difference between MVC and N-Tier, as explained in FAQ26. Your use of the term “mediator” is a red herring. If I have three components which perform the responsibilities of Model, View and Controller as defined in the MVC design pattern, then that IS MVC whatever anyone says.

@TomB

This is non sequitur. Nowhere did I say (or even imply) that MVC mentioned these details, only that it specifies the direction of data flow.

Then in fact we are in agreement.

@TomB

Then you’re putting display logic in the model.

No I’m not. Logic implies code which manipulates the variables to produce some result. The variables for offset, limit and order simly pass THROUGH the Model to be processed by the DAO, then sent back to View where they can be displayed to and altered by the user.

@TomB

Well, is sorting or taking a subset manipulating? I’d argue not because it’s read only.

The View does not sort the data as this has already been done by the DAO. The View does not extract a subset of the data from the Model, it deals with ALL the data currently contained in the Model.

@TomB

As for highest page number in the model. The model should not have the concept of a page. It’s display logic and should be irrelevant to the model.

The current/highest page numbers are not processed in any way in the Model, nor do they affect the processing of any business rules within the Model. They are simply variables which are passed down to the DAO and back up to the View.

@TomB

Irrelevant implementation details. You don’t have to use DAOs in MVC.

I don’t have to, no, but I’m perfectly within my rights to do so.

@TomB

Then whatever is setting said message on the model contains display logic.

Then your definition of “display logic” is seriously flawed. Identifying what needs to be displayed is totally different from building the actual display, which in a web page is the HTML document. The Model tells the View “please display this message” and the View generates the necessary HTML to perform that task.

If the Model generated any HTML then that would be “display logic”.

[TomB]

@Tony_Marston

I disagree entirely. How data flows between the Model, View and Controller is NOT specified in ANY valid description of the MVC pattern.

MVC states that views access the model directly (ie not using the controller as a mediator) and that models should not know of controllers and views, so in this regard it does. If that’s not defining data flow I don’t know what is.

I disagree (again). The Model contains whatever records it has been told to contain, either by issuing an sql SELECT statement, or by having data injected into it from the Controller.

Data access in the controller and passing to the model? Definitely not right.

The View does not request any particular records from the Model, it deals with all records that are currently contained in the Model. Ordering and limiting are data variables which are passed from the Controller, through the Model and to the DAO so that they can be built into the sql SELECT statement. The View does not decide how to limit or sort the data - the data which it is given has already been sorted and limited.

Ordering, limiting and generally deciding which records to show is 100% display logic. By moving this to the model you’ve reduced reusability of the view. You now need to do all this set up in each model (or presumably pass it to the model from each controller).

Lets say I have a Table view which displays a set of data in a tabular format. I can pass any model to it and have it display. If the limiting/ordering is done in the view, then I don’t need to worry about replicating code in each controller which uses the view. In a desktop app, you get a component which you can interact with e.g. a Data Grid. You can interact with it e.g. click the column titles to sort. This is all display logic, there’s no need for it to go back to the model-- it already contains the relevant data. On the web this is slightly different (though you could do the same with javascript…). If you link the view to the model, the view can select which records to display. E.g. page 2 (records 50-100). Otherwise, the model contains the concept of a ‘page’ which is 100% display logic… or preferably in the controller in which case you need to introduce page concept into each controller that uses the view.

[webaddictz]

@sunwukung

Ah stuff this, I’m going back to spaghetti and tables

Thanks for this, you already made my Friday!

Being serious though; I can only agree with arborint when he says there’s no point in arguing further. It’s clear that you disagree with each other (a lot) and you’re now mostly confusing other people with this pointless discussion. Of course, it’s not up to me, but if it was I’d say: let it go guys.

[TomB]

@Tony_Marston

“The view gets its own data from the model” is the major point here. Whether the View “pulls” the data out of the Model, or the Model “pushes” its data to the View is an implementation detail. You could even have the Controller “pull” from the Model and “push” to the View, but who cares? That the data flows is important, but the actual mechanics are an implementation detail.

Actually it’s this distinction which separates MVC from other architectures such as N-Tier. The controller acting as a mediator is not MVC. Push/pull certainly are implementation details but your argument here is a straw man.

The data flows between the three components, yes, and each component deals with that data in its own way. But whether the data is “pushed” or “pulled” between those components is an impementation detail and not a requirement of the MVC pattern

This is non sequitur. Nowhere did I say (or even imply) that MVC mentioned these details, only that it specifies the direction of data flow.

At any instance in time the Model only contains those records that are required in the current iteration of a particular transaction. It most certainly does NOT contain all available records which then have to be filtered and sorted by the View.

Then you’re putting display logic in the model.

The View does not contain any logic (program code) which manipulates the data it has been given. It is simply given a bunch of variables which it displays. Amongst these variables are one or more database records, current page number, highest available page number (as provided by the DAO), and any other piece of information which it may require.

Well, is sorting or taking a subset manipulating? I’d argue not because it’s read only.

As for highest page number in the model. The model should not have the concept of a page. It’s display logic and should be irrelevant to the model.

The Model does not apply any filters to the sql query - it simply passes all the necessary variables to the DAO which then builds them into the SELECT statement which it then executes. The total record count, total page count and current page number are variables which are set in the DAO and passed through the Model to the View.

Irrelevant implementation details. You don’t have to use DAOs in MVC.

Wrong. The View does NOT decide which error message to display, it simply displays whatever messages it is told to display by the Model. The Model may have different messages in different circumstances, and they may be in different langages.

Then whatever is setting said message on the model contains display logic.

[arborint]

Good grief … these multiple posts feel like getting carpet bombed.

I agree with TomB that MVC does specify some clear dependencies of which someone seems to be oblivious. However, there are some discrepancies in those dependencies.

In the strictest version, the Model has no dependencies, the View is only dependent on the Model, and the Controller can have dependencies on both the View and Controller.

However, more common now is Fowler’s take on the pattern where the View and Controller are clearly in the Presentation layer and can have dependencies on each other, and any code in the Presentation layer (View+Controller) can have dependencies on the Model.

I should note for the nitpickers that it is sometimes necessary for the Model layer to have dependencies on the Presentation layer. Reality is not as clean as theory. You can find some discussion about these exceptions and good ways to handle them around the web.

I do want to reiterate Fowler’s comment that MVC is TWO separations (not three). The first, and most important, is between the Model layer and the Presentation layer (View+Controller). The Model should not have any dependencies on the Presentation. Get that right and you are 90% of the way to a cleaner application. Hopefully that independence should help guide the OP in implementing Model classes.

The second separation is between the View and the Controller. It is less important and much more controversial – so more often argued. I think as long as you draw a consistent line between the two in you application you will be ok. If you can keep the View independent of the Controller you will get some benefits. If you can keep your Controllers skinny, even better. These are lessons learned by the trial and error of many programmers over the years.

[Tony_Marston]

@TomB

Then this isn’t strictly a model. What about where you have a user and user address table?

I disagree. USER and USER_ADDRESS are distinct and separate entities (otherwise why would they require separate tables in the database?). When you create working transactions (or tasks) you need to decide what data you need to display, which therefore dictates which of these two tables need to be accessed - one, the other, or both.

It is still possible to have separate classes for each table, and reference them separately when required. There is no rule which states that if I have to display data from both tables in a single screen then I have to access a single object which contains data from both tables. That depends on the circumstances, and is therefore an implementation detail.

[Tony_Marston]

@Czaries

I think you missed the point of what I was trying to say. The “Model” layer will always consist of multiple classes - I was not advocating the creation of a single Model class. I don’t even know how that would be possible.

In that case instead of saying

The “Model” is the entire domain logic layer.
you should have said something like
The “Model” is comprised of separate classes, where each class represents a different entity within the Domain

This then allows each transaction/task to specify which class(es) it needs to access in order to perform its designated function.

@Czaries

I was saying you never name any class “Model”, because it creates confusion. If you have Entity objects that represent your data, then name them after the entity they represent (Post, User, etc), and just know that they are a part of the model layer.

I agree (you see, I don’t always disagree!). In my own framework, which deas with lots of database tables, I have a separate class for each table, and the class name is the same as the table name.

[Tony_Marston]

@Czaries

Wow, like 6 posts in a row from Tony Marston. Cool off a little bit, man. This is not a “my framework design is better than yours” contest, so let’s not turn it into one.

I have never said that the implementation of MVC in my framework is better, just different. Some people seem to think that just because it is different that it is automatically wrong. My answer is simple - it cannot be wrong for the simple reason that it works.

[Tony_Marston]

@TomB

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).

I disagree. How the View gets is data is not specified in any description of MVC, therefore is irrelevant. It is nothing more than an “implementation detail”. What the View does with the data once it has it is the critical issue.

@TomB

As for broadcasting changes, it doesn’t really apply to PHP since the view will be refreshed anyway.

I disagree. The View has to decide how to display any changes given to it by the Model, which still requires program code. The programming language is irrelevant in such a case.

@TomB

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.

I disagree (again). The Model contains whatever records it has been told to contain, either by issuing an sql SELECT statement, or by having data injected into it from the Controller. The View does not request any particular records from the Model, it deals with all records that are currently contained in the Model. Ordering and limiting are data variables which are passed from the Controller, through the Model and to the DAO so that they can be built into the sql SELECT statement. The View does not decide how to limit or sort the data - the data which it is given has already been sorted and limited.

[Tony_Marston]

@omnibreak

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

What is different between one database table and another? - try the following:

• database name
• table name
• table structure (a list of columns where each column has a name, size, type and other attributes