SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 49
  1. #1
    SitePoint Zealot mr_jeep's Avatar
    Join Date
    Feb 2004
    Location
    Canada
    Posts
    131
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    MVC is the "buzzword", but does he really worth it ?

    Well, for the past month, I worked hard to understand this thing everybody's talking about.. the MVC pattern. I think I understand it now but it's still hard to me to figure how to apply it to the Web.

    Yhea I understand this is good to split logic and content presentation and use the reusability of class but I'm wondering if the MVC patterns really makes it easyer on the Web. This is an exemple. If a web page is 1 action having a view, It means each view must contain the code of the header, the navigation menus, the general layout of the website and a footer (well some </body> tags). If I have something like 30 pages, it means (or please correct me if I'm wrong), I'll have to copy/paste the general stuff 30 times within the 30 view's object. This is not quite re-usability and still, it doesn't seems more clean to me. Every page has something like 5 files which is finally (well I think) more complicated. I'm beginning to think this MVC patterns apply to web application and not WebSites .

    Tell me if I'm wrong or please, tell me other ways to build website using classes.

    Thanks
    I'd appreciate if you would tell me if something I wrote is spelled wrong

  2. #2
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First, there may be a situ where a web page is actually built up from mutliple views. Looking at the Java site, you have View Helper's which could be implemented for this ?

    On the otherhand, have a look at the script I posted yersterday in another recent thread, in response to a member request. I have the one main view, but I also create mini-views, which are later added to the main view before output

    I'll have to copy/paste the general stuff 30 times within the 30 view's object.
    Again, not really pratical as you point out, so what you have is a Base View class to handle the house keeping tasks, then you extend a sub view class which actually handles the model data on a per page basis.

    Fair enough, you still have x number of classes, but having a Base View which does the bulk of the repeatitive work for you does reduce maintenance.

    I still think the pattern has a lot going for it for web, both on site and off site development, but on this matter, I now implement a FC with off site (administration) and a PC for on site, for me this works out to be easier to develop with

  3. #3
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I may have a problem with my Controller - or is it my Model? - but my View is that MVC is a confusing choice since it does not express the fundamental structure of web apps clearly.

    Straight off, it over-emphasises the client output. The pattern suggests that there's only one model and view: the page served up to the browser. In fact there could be several models and views in addition to the client output.

    Furthermore, client output is just one task of possibly many in a script. There could be a variety of pre client-output tasks (authentication, sessions, etc) and post client-output tasks (file logs, emails etc). You could view this as a 3-stage structure or maybe as a whole series of tasks on an equal footing. If you don't, there's a risk that the design will be overpowered by the client output, with no proper place for the other tasks.

    MVC has nothing explicit to say about that. "The controller accepts user input, manipulates the model and updates the view". Ah. Great. How many times have you heard people ask: "does this bit go in the model or the controller?" A bad definition generates questions; a good one creates solutions.

    A lot of this has surfaced in previous discussions. Not everyone will agree but perhaps there should be some kind of workflow manager to call all the separate tasks, and any MVC stuff (print something, somewhere that will eventually be viewed) should be safely quarantined from the rest of the app in printer classes. The controller - now a PrintManager with a single model and view to manage rather than the whole damned app - will thank you for it. Embed MVC in web apps, not entire apps in MVC.
    Last edited by McGruff; Feb 27, 2004 at 09:13.

  4. #4
    SitePoint Zealot patrikG's Avatar
    Join Date
    Aug 2003
    Location
    Sussex, UK
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Straight off, it over-emphasises the client output. The pattern suggests that there's only one model and view: the page served up to the browser. In fact there could be several models and views in addition to the client output.
    As far as I understand MVC it doesn't care whether, but does cater for when you have multiple or, indeed, nested views.
    While I don't believe that one pattern alone can really be the alpha and omega of a web-app, the MVC is a step towards a fundamentally "cleaner" PHP code. And that is to be applauded. MVC does not answer all questions, nor does it structure you app when user-management, sessions etc come in. All it does is to logically simplify the app.

  5. #5
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by patrikG
    While I don't believe that one pattern alone can really be the alpha and omega of a web-app, the MVC is a step towards a fundamentally "cleaner" PHP code.
    That's the root of the issue for me: patterns are usually something people apply to problems within apps but, uniquely, MVC is supposed to encompass the whole app. Doesn't that sound fishy?

    The model and view are fine but I don't like the controller as it is normally conceived.

  6. #6
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A bad definition generates questions; a good one creates solutions.
    Would recommend M Fowlers book to absolutely anyone

    You'll find all the definitions you need in the book, failing this, dare I say it, have a look at Microsoft's site for their definitions of Design Patterns.

    But be warned, they're geared towards DotNet

  7. #7
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Doesn't that sound fishy?
    Nope, what your problem is, is more to do with software layering, rather than the MVC pattern specifically.

    ...the MVC is a step towards a fundamentally "cleaner" PHP code. And that is to be applauded.

  8. #8
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Nope, what your problem is, is more to do with software layering, rather than the MVC pattern specifically.
    No my issue is with MVC as it is commonly applied to web apps. MVC is used as a blueprint - it's not a very informative one. I'm sure you can shoehorn programs into MVC, but I don't think you should.

  9. #9
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with McGruff: Using MVC for web applications is a bad smell.

    First of all there's the confusion about MVC itself: the original pattern (MVC1) is intended to be used in (Graphical) User Interfaces, and contains specifications on how the three elements should communicate. Then there's Model 2 (MVC2) which describes a software concern: the separation of presentation and business logic. People refer to both of these as 'MVC', so it's never clear which of the two they mean. Furthermore, some people who appear to mean MVC2 when they use the term 'MVC' sometimes mention the communication restrictions of MVC1. For this reason alone we should avoid the use of the MVC terminology, IMO.

    Next, the MVC pattern was intended for GUIs, not web applications. It has been taken out of it's intended context, rescaled to fit an application's entire architecture instead of part of it, and copy-pasted into a new context. A number of frameworks and applications claim they use an MVC architecture. But I believe that none of them really do: they use an architecture that resembles some parts of the original MVC pattern, and they use MVC terminology to name or describe their application objects. The original context also leaks through: I see quite a number of people talking about their View layer as if displays HTML output to a user. But it doesn't.

    Then there's the problem of vocabulary. MVC is a pattern that describes a possible solution to the GUI problem. The pattern itself does not describe the problem. Most MVC enthusiasts, however, use the terminology of MVC to describe the problem domain of their application. So instead of discussing and analyzing the real problem, they talk about how it can be implemented in this single solution (ex.: "How do I display multiple Views?"). MVC also offers a very restricted vocabulary: 'Model', 'View', and 'Controller'. Since these have little or no relation to the problem domain, people often attach alternate meaning to them ('Controllers are basically actions', 'The View layer consists of a template parser and templates'). These alternate meanings can vary from person to person, which makes communication difficult.

    Finally a lot of people see MVC as the best and only architecture for web applications, and believe separation of presentation and business logic can only be achieved through MVC. So they're not looking for the best solutions to problems, but for solutions that fit into MVC. This means that whenever a problem can be solved by MVC, it is seen as proof that MVC is the right architecture. And whenever it can't be solved, the problem seems to be unsolveable.

    There is nothing wrong with the MVC pattern itself. I think the problem is that 'MVC' has become the sole architecture for web developers, as well as their vocabulary to describe the problem domain, when it was never intended to be either of these.

    Just my two cents.

    Azmo

  10. #10
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  11. #11
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yup, here's the follow-up:

    The WARS Architectural Style

    I don't fully argee with his architecture though.

  12. #12
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the two java.net links - very interesting.

  13. #13
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interesting view from Azmo, although the way I look at it, is this:

    If MVC2 wasn't intended for web applications, then how is it, that on the Sun Microsystems web site, there is a whole chapter on how to implement the pattern ?

    Fair enough, the original MVC pattern wasn't intended for the Internet, and fair enough that some folks refer to the original, in regards to MVC2 - that is their mis-understanding, doesn't mean that MVC2 is flawed does it ?

    For code re-use, and rapid development, MVC - the idealology - has become vastly popular, and would be totally reckless just to disregard the pattern now.

    Now, I'm off to look at the link Harry posted

  14. #14
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Next, the MVC pattern was intended for GUIs, not web applications.
    I dont know about yours, but my users only interact with my web applications through a GUI. Do yours use a touch-tone phone?

  15. #15
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As far as I know, here is where the MVC pattern originated:

    http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

    IMHO, I don't think that the MVC pattern is described poorly. It is more of a general architecture and doesn't tell the developer what to do in every situation or where to stick every little bit of code. I think the main idea is: separation-of-concern promotes reusability and maintainability. Microsoft chooses to do more of an N-tier approach for their enterprise apps (although more recently they have gotten into specific "patterns" such as Front Controller). In an application that is primarily data-driven, typically you will have a data access layer, some sort of business or application logic layer and a presentation layer on top of that. There are no absolute rules on how the system should be partitioned. Some applications may put more logic in the presentation layer (fat-client) and others may put more in lower layers (thin-client). One other thing to note is that MVC was the originally the central concept behind Smalltalk-80 GUI applications. We are trying to force Web-based applications into this model. In some cases this will be successful in others it will fail miserably. I guess what I am trying to say is that I don't blame the pattern(s). They are what they are... Reoccurring solutions to common problems which are attempting to promote reuse.

    JT

  16. #16
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    If MVC2 wasn't intended for web applications, then how is it, that on the Sun Microsystems web site, there is a whole chapter on how to implement the pattern ?

    Sure, but Sun does Java, not PHP. And these two are completely diferent.

    I found this chapter about MVC and Enterprise Applications on the Sun site. Particularly interesting are Figure 11.7 and Figure 11.9 (these links suck: you need to scroll up a bit to see the diagrams). They both depict an application where the client component is part of the application. This is not the case for PHP applications, which rely on separate client software (webbrowser) to act as the View, and which use the webserver as a (Front)Controller.

    I prefer to see PHP applications as part of a three-tier system: client software <-> webserver software <-> application software. If MVC has any pace in this system, it would be in the client software (usually a webbrowser). From the webbrowser's viewpoint, the two lower tiers are a remote extension of its Model layer. The job of the web application is to perform the correct Action for each Request, and return a relevant Document to the webserver.

  17. #17
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    I dont know about yours, but my users only interact with my web applications through a GUI. Do yours use a touch-tone phone?
    No you're right, all users use a GUI to access my application. But not all my clients are users. Some of them are RSS aggregators, or search engines. And both our users use special client software to access our applications. This client software is what we communicate with, not the user.

    Seratonin: I agree (as will anyone who is opposed to MVC as web application architecture) that the patterns themselves are fine, the way they are used is not. But you just said it: MVC was intended for GUI applications, and for web applications it's failing in some (too many) cases. As for "separation-of-concern promotes reusability and maintainability", nobody will disagree here. But MVC is not the only solution for this issue when web applications are concerned. It most likely isn't the best solution. It may even be a quite poor solution.

  18. #18
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    No you're right, all users use a GUI to access my application. But not all my clients are users. Some of them are RSS aggregators, or search engines. And both our users use special client software to access our applications. This client software is what we communicate with, not the user.

    Seratonin: I agree (as will anyone who is opposed to MVC as web application architecture) that the patterns themselves are fine, the way they are used is not. But you just said it: MVC was intended for GUI applications, and for web applications it's failing in some (too many) cases. As for "separation-of-concern promotes reusability and maintainability", nobody will disagree here. But MVC is not the only solution for this issue when web applications are concerned. It most likely isn't the best solution. It may even be a quite poor solution.
    I think that MVC may be suitable for solving some well-constrained problems. I have used it quite successfully on several projects. There are some heuristics to follow, though. If you are constantly asking yourself "Where should I put this (M, V, or C)?" you are probably using the wrong pattern (or maybe the right pattern incorrectly). Apply the pattern to the problem, don't try to fit the problem into the pattern (does that make sense?). MVC is extremely general. If you look at it as an example of separation and then taylor it for your needs, you will be much better off. I agree that there are definitely many different ways to support reusability and maintainability. Some patterns which I can definitely say are useful for Web-based software applications are:

    Factory Method
    Command
    Facade
    Strategy
    various Data Access Patterns

    I'm sure there are many more that can be added to this list.

    JT

  19. #19
    SitePoint Member
    Join Date
    Apr 2003
    Location
    Argentina
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Azmo, no mean to be offensive here, but which one you thinks it's a less "poor" solution for this?

  20. #20
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webstudio
    Azmo, no mean to be offensive here, but which one you thinks it's a less "poor" solution for this?
    Do you mean if I have a better solution than MVC? Well, my application is structured in a way that is similar to the 'MVC' architecture in a number of places. Instead of naming things aftef MVC terms, I try to give a name to each of my components that describes what it does, what its responsibilities are, or which problem it solves. I also do a couple of things that would be considered bad when done in the MVC context (my 'View' layer sometimes calls 'sub-Controller' components, and everyone knows this should only be done by the 'Controller' ).

    I use an architecture that is very different from what most people on this forum use (it's configuration driven), so even though it solves quite a few problems, I'm not sure these problems can be solved if you use the same layering and structure as my application, but a different architecture. I also use a data-centric approach, so there is no Domain Model, nor Domain Objects. My application's primary responsibility is to manage data, and to return it to clients by using Documents. That's it. KISS (Keep It Simple, Stupid).

    I don't really care what kind of structure and architecture people use for their web applications. I just wish they would stop talking, thinking, and coding in MVC, and instead start talking, thinking, and coding in terms of the problems they're trying to solve, and the solutions they are using.

  21. #21
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I may have a problem with my Controller - or is it my Model? - but my View is that MVC is a confusing choice since it does not express the fundamental structure of web apps clearly.
    Nice one Perhaps we can summarize this discussion that some concepts in the pattern that some people encapsulate as 'MVC' (including me ) are good patterns but need better terminology and constraints on 'what goes where'? If so, I fully agree.

  22. #22
    SitePoint Member
    Join Date
    Apr 2003
    Location
    Argentina
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    I also do a couple of things that would be considered bad when done in the MVC context (my 'View' layer sometimes calls 'sub-Controller' components, and everyone knows this should only be done by the 'Controller' ).
    Well, we may not be thinking too different to some concepts, then. I also think that, when it comes to "views", and particularly sub-Views or Composite Views, the MVC patterns isn't as suitable as I believe in the first time. And from a time I've been wondering which could be the best way to let "sub-views" handle their own 'logic' (instantiating and getting the required Model Data they need to render) without breaking MVC.

    Maybe this was what it led you to your architecture, not caring too much on Code 'purity' but most on getting the results you need?

    anyway, I'm still seeking som solution to that problem. Maybe stop calling our 'Views' that way, and renaming those to 'ViewsControllers" ? (I believe I read something like this some days ago in the forum)

  23. #23
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by mr_jeep
    This is an exemple. If a web page is 1 action having a view, It means each view must contain the code of the header, the navigation menus, the general layout of the website and a footer (well some </body> tags). If I have something like 30 pages, it means (or please correct me if I'm wrong), I'll have to copy/paste the general stuff 30 times within the 30 view's object.

    Thanks
    No. include() is your friend. You can have files that contain headers, or footers, or whatever, that are common to many views/templates.

    --ed

  24. #24
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Such as what I have at the moment for example

    PHP Code:
    class ViewGenerator {
            var 
    $header_;
            var 
    $footer_;
            var 
    $template;
            
            function 
    ViewGenerator$filename ) {
                if( !
    file_exists$filename ) ) {
                    
    ErrorReport::Invoke200 );
                    die();
                }
                
    $fp = @fopen$filename'r' );
                
    $template = @fread$fp, @filesize$filename ) );
                @
    fclose$fp );
                
                
    $this -> template = &$template;
                
    $this -> Header();
                
    $this -> Footer();
            }
            
            function 
    Header() { 
                
    $fp = @fopen'templates/header.html''r' );
                
    $header = @fread$fp, @filesize'templates/header.html' ) );
                @
    fclose$fp );
                
                
    $this -> header_ = &$header;
            }
            
            function 
    Footer() {
                
    $fp = @fopen'templates/footer.html''r' );
                
    $header = @fread$fp, @filesize'templates/footer.html' ) );
                @
    fclose$fp );
                
                
    $this -> footer_ = &$footer;
            }
            
            function 
    Replace$tag$string ) {
                
    $this -> template ereg_replace$tag$string$this -> template );
            }
            
            function 
    Finalise$header ''$footer '' ) {
                echo( empty( 
    $header )? $this -> header_:$header );
                echo( 
    $this -> template );
                echo( empty( 
    $footer )? $this -> footer_:$footer );
                die();
            }
        } 
    PHP Code:
        function UserLogInView() {
                
    ViewGenerator::ViewGenerator'templates/login.html' );
            }
            
            function 
    Render() {
                
    $fp = @fopen'templates/login-header.html''r' );
                
    $header = @fread$fp, @filesize'templates/login-header.html' ) );
                @
    fclose$fp );
                
                
    $fp = @fopen'templates/login-footer.html''r' );
                
    $footer = @fread$fp, @filesize'templates/login-footer.html' ) );
                @
    fclose$fp );
                
                
    $this -> Finalise$header$footer );
            }
        } 
    Works fine so far

  25. #25
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like to use the Content Aggregation Pattern for composite views. Where I basically build an "object" model of document which aggregates content from different sources. Then I transform this "document-centric" model into the equivalent XHTML representation or whatever other document type I desire. Content aggregation with DOM is going to be an even more viable option in PHP 5. I like what Terence Kearns is doing over at:

    http://xao-php.sourceforge.net

    JT


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
  •