SitePoint Sponsor

User Tag List

Page 2 of 5 FirstFirst 12345 LastLast
Results 26 to 50 of 118

Thread: The MVC's model

  1. #26
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I disagree. The only real difference between web and a desktop environment is the fact that the view does not need to be refreshed automatically (an active model) when the model is updated. On the web the view is refreshed on every call to the controller anyway so there's no need for the trigger in the model (a passive model). This is the only real distinction and has no impact on the MVC architecture.

    The flow is identical: controller updates model, view refreshes from model. The fact that the controller has to re-initialise the view and model each time is irrelevant.

  2. #27
    SitePoint Zealot
    Join Date
    Sep 2009
    Posts
    117
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  3. #28
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,192
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by TomB
    I disagree. The only real difference between web and a desktop environment is the fact that the view does not need to be refreshed automatically (an active model) when the model is updated. On the web the view is refreshed on every call to the controller anyway so there's no need for the trigger in the model (a passive model). This is the only real distinction and has no impact on the MVC architecture.

    The flow is identical: controller updates model, view refreshes from model. The fact that the controller has to re-initialise the view and model each time is irrelevant.
    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.
    The only code I hate more than my own is everyone else's.

  4. #29
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    919
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #30
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tsalagi View Post
    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.
    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.
    Yes, I blog, too.

  6. #31
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by omnibreak View 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
    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

  7. #32
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by oddz View Post
    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.
    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.

  8. #33
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

    Quote Originally Posted by Tony Marston View Post
    I disagree. The Model is not the entire domain logic layer. You do not create a single Model class for the entire application, you create a separate class for each entity within the application. For a database application this equates to a separate class for each database table.
    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. 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.

  9. #34
    SitePoint Zealot
    Join Date
    Sep 2009
    Posts
    117
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #35
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tsalagi View Post
    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.
    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.
    Yes, I blog, too.

  11. #36
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by omnibreak View 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
    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

  12. #37
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

  13. #38
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    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.

  14. #39
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    That depends on what your going to base the definition of pattern on.
    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.

    Quote Originally Posted by oddz View Post
    If your strictly basing the pattern on the coupling than they are similar. However, the flow is what requires the different approach. For example, in a traditional Java Environment for desktop development the flow is circular whereas the flow is linear due to the stateless nature of the web. The inventors of rails didn't approach the situation the same way as a desktop application because it would be impossible given the shift in paradigm between a circular state based flow and linear non-state based flow. The need for a modified MVC approach for linear environment is a result of shift in paradigms between traditional app and web based development as Czaries pointed out very well. I just really think people need to stop referring to the web interpretation as MVC and something else entirely to create a clear distinction between the web interpretation and traditional one.
    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.

  15. #40
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tsalagi View Post
    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?
    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

  16. #41
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    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 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.

  17. #42
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    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.

  18. #43
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    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.

    Quote Originally Posted by Czaries View Post
    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.

  19. #44
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    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.

  20. #45
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Christopher

  21. #46
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    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.
    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.

    Quote Originally Posted by TomB View Post
    Data access in the controller and passing to the model? Definitely not right.
    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.

    Quote Originally Posted by TomB View Post
    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).
    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.

    Quote Originally Posted by TomB View Post
    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.
    This is called pagination and is automatically built into each of my Transaction Patterns, so absolutely *NO* extra code is required. EVER.

    Quote Originally Posted by TomB View Post
    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.
    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.

    Quote Originally Posted by TomB View Post
    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.
    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

  22. #47
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint View Post
    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

    Quote Originally Posted by arborint View Post
    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.

    Quote Originally Posted by arborint View Post
    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.

  23. #48
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    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.

    Quote Originally Posted by 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.

  24. #49
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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

    Quote Originally Posted by TomB View Post
    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".

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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.

    Quote Originally Posted by TomB View Post
    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*.

  25. #50
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    "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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •