SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    SitePoint Guru Nick Carlson's Avatar
    Join Date
    Aug 2003
    Location
    Denver
    Posts
    644
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Anything better than MVC?

    Ah yes, the ol' "what's best" question.

    I couldn't think of a proper title for this thread, but here is my basic question: Is MVC the most appropriate pattern for web applications? For you CS buffs out there, can you think of any pattern more suitable for the trials and tribulations of the average web application?

    Thanks.

  2. #2
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Happy New Year!

    Several candidates:

    1) real MVC (as in smalltalk-80) instead of webMVC which is not MVC at all. Not saying that webMVC does not have its merits (it has) but MVC e.g. still offers better composability.

    2) Continuation based apps may also at some point develop into something useful. Right now it's not without its problems, but it could percievably allow for a more simple state management model.

    3) More elegant workflow integration for the stateful flows, e.g. user registration, surveys, checkout etc. This could be form the "model" part of (real) MVC and thus be complementary. This could also allow MVC to be used only where it makes sense. Workflow may actually be considered a form of "manual" continuations.

    IMO you often have this problem with MVC that it invades your site. Rather than the comparatively simple and decopuled model of plain old HTML pages hyperlinking to eachother you are required to follow rigid procedures for link generation. Many sites are more site at the top with some individual parts/pages actually forming small applications at the "leaves". I find that MVC often forces me to consider the entire site an application - or - follow rigid rules for how to link into the "applications" from the outside. Larger sites often has several independent "application pages" and many, many semi-static, independant pages which do not take part in any application or workflow.

  3. #3
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There's the Event Driven Model >.>

  4. #4
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    There's the Event Driven Model >.>
    ?

  5. #5
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chris Corbyn View Post
    ?
    Event Driven Architecture

  6. #6
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    I understand what Event Driven development is, however, it's definitely not an alternative to MVC. The two are different things.

    EDIT |

    Sorry, I feel almost like I didn't finish this post. To clarify; event-driven design is related to program flow, MVC relates to separating concerns.

  7. #7
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The alternative is not using MVC.

    You can just use OOP with some common design patterns.

    Checkout EllisLab's ExpressionEngine.

    http://expressionengine.com/

    It does not follow any strict MVC rules yet it is a lot quicker and easier to use for development.

  8. #8
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    MVC separates the program into three distinct parts: Model, View and Controller. One alternative is to merge Controller and View, so you get only two layers; Model and Presentation. This makes it harder to reuse controllers with different views, but has the benefit of making it less complicated to integrate the two. For many web applications, this is a good trade off.

  9. #9
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "Anything better than MVC?"

    Yes. Sometimes I think anything is better than MVC. The term has become a virtually meaningless buzz word in php with a thousand different definitions causing endless confusion for people learning about OOP. If there were a forum banned words list, I'd put "MVC" in it.

    Here's a piece by Fowler on GUI Architectures.

  10. #10
    SitePoint Enthusiast
    Join Date
    Mar 2007
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think most if not everyone can agree that the model layer should stay. So the question is if you keep bothering to seperate the view and the controllers.

    The problem with php is that almost nothing is persistent so you end up rebuilding pages over and over again. You cant make useful actionlisteners and other pretty things to make interaction with the View easy. Basically you are just reading a request and building a page on that info.

    So in my eyes the best thing to do is to find a simple way of constructing and re-use pages/templates.

    So you end up with a data layer, domain objects, Some kind of Request reader (Dispatcher to controllers) and some kind of presentation builder.

    Now this isnt really MVC but it is inspired by this. Seems to me its just a clever batch proces based on the request information.

    Then again i could be doing it all wrong though.

  11. #11
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aso View Post
    I think most if not everyone can agree that the model layer should stay. So the question is if you keep bothering to seperate the view and the controllers.
    This is called the document view pattern. Its a commonly used and is described in a lot of desktop MVC implemetations.

  12. #12
    SitePoint Guru Nick Carlson's Avatar
    Join Date
    Aug 2003
    Location
    Denver
    Posts
    644
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aso View Post
    The problem with php is that almost nothing is persistent so you end up rebuilding pages over and over again.
    Is smalltalk the answer? Python perhaps?

  13. #13
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by optimus prime View Post
    Is smalltalk the answer? Python perhaps?
    I reckon he didn't mean problem as in "weakness", but rather as in "doesn't fit with the traditional MVC pattern". The do-and-die nature of PHP, is its greatest strength.

  14. #14
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally I've been moving away from the "classical web-mvc" with a monolithic controller that contains things such as editAction(), deleteAction(), etc. towards a more document/page centric approach with a page controller instead of a front controller (albeit I have kept some type of dispatcher for loading page controllers and a router to get those cute URLs)

    I've always felt a great mismatch between PHPs run -> exit / share-nothing architecture and "the monolithic classical web-mvc controller". While on the topic of "to mvc or not" there is another thing that's been disturbing me for a great while (talking about web-mvc here, not classic mvc from desktop apps):

    The naming of the controller tier to just "controller" and "action" suggest, or at least it seems so that many people that come to web-mvc reads it this way, that the controller should be responsible for a major part of the business logic - when in reality it shouldn't. A more appropriate name, imho, is "View" since it should forward a View of the model to the template, sort of like what a View is to a Table in a relational database, and not be responsible for any business logic.

    A more correct naming should be something like Model(M) - View(C) - Layout(V), with their "classic" abbreviation in parenthesizes.

  15. #15
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have seen a framework that just uses a action chain. It basicly does every from the chain. It will make a database connection, load configuration values, handles the request, displays the page etc..

    Is this a good way of structuring a framework?

    It does not seem like MVC and has quite a lot of benefits.

  16. #16
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The main benefits to MVC are related to maintenance of the system. In PHP, the architecture itself does not make much theoretical sense, due to the previously mentioned do-and-die mentality of PHP.
    In JSP, the modules are loaded and will stay loaded until the server closes them. This allows for more "natural" MVC-behaviour. In PHP, the module is at the mercy of each request, and this basically turns MVC into an action chain for each request, where (potentially) huge portions of the loaded code is never even used. But the simple layout of the architechture eases maintenance.

    If you're going to have a huge-traffic website, and insist on using MVC, then you should learn Java/JSP. Otherwise you'd be better off with optimising your architecture towards different requests.

  17. #17
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't get that. How is Java/JSP (struts?) different from PHP in this matter? In JSP the servlet class may stay loaded, but no state pertaining to the user survives from request to request, except for the "session" scoped values - like in PHP. How does this make JSP more suited for webMVC than PHP?

  18. #18
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I reckon he didn't mean problem as in "weakness", but rather as in "doesn't fit with the traditional MVC pattern". The do-and-die nature of PHP, is its greatest strength.
    I'm not certain that having to reload your entire application on every request should be considered a strength; It certainly isn't ideal in terms of performance. The main advantage to killing the script at the end of each request is that it makes coding easier, as you don't have to worry as much about memory, and indeed PHP is currently ill suited to making long running processes due to the design of the garbage collector.

  19. #19
    SitePoint Member RH-Yan's Avatar
    Join Date
    Jan 2008
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know that web based MVC frameworks makes coding a lot easier and faster. However, my only concern is are there performance tradeoffs? I mean if I create a site with a custom CMS using CakePHP, will there be any performance defects due to perhaps any float in the frameworks?

  20. #20
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by honeymonster View Post
    I don't get that. How is Java/JSP (struts?) different from PHP in this matter? In JSP the servlet class may stay loaded, but no state pertaining to the user survives from request to request, except for the "session" scoped values - like in PHP. How does this make JSP more suited for webMVC than PHP?
    JSP can use "real MVC" (reload per code update). PHP can only use "web MVC" (reload per request).

    Remember that MVC is practically a Java pattern.

    In JSP the request is handed to a pre-loaded method, which is among other things already connected to a database (already here we have a significant performance boost compared to php). This method then parses the request and performs the desired operations on the already loaded code, which means there are _NO_ instructions between parsing the request and executing the desired code, whereas in PHP, there are possibly several includes and requires just for the request code, not to mention all the libraries that have to be included and executed, BEFORE you even get to the real code you want.

    I'm not saying use JSP for all MVC, but just be aware of how "ease of maintenance" affects the performance of your PHP app...

  21. #21
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    I'm not certain that having to reload your entire application on every request should be considered a strength; It certainly isn't ideal in terms of performance. The main advantage to killing the script at the end of each request is that it makes coding easier, as you don't have to worry as much about memory, and indeed PHP is currently ill suited to making long running processes due to the design of the garbage collector.
    Quote Originally Posted by Athox View Post
    In JSP the request is handed to a pre-loaded method, which is among other things already connected to a database (already here we have a significant performance boost compared to php). This method then parses the request and performs the desired operations on the already loaded code, which means there are _NO_ instructions between parsing the request and executing the desired code, whereas in PHP, there are possibly several includes and requires just for the request code, not to mention all the libraries that have to be included and executed, BEFORE you even get to the real code you want.
    You can use APC to cache opcodes. That way, the only overhead in PHP, is that each request must spawn a new process. On the other hand, this allows for a much simpler memory-management, which beats the socks of even the smartest garbage-collector.

  22. #22
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    You can use APC to cache opcodes. That way, the only overhead in PHP, is that each request must spawn a new process.
    1) The overhead of creating a new process and destroying it in each request is considerable, especially compared to architectures where requests can be served a pool of threads.

    2) The only overhead is misleading. PHP is really only one big script (which may include/require subscripts) in one monolithic namespace. Any code may change or add to the definitions preceding it. Any class which is defined may be altered by any code which execute at a later state. Thus, an opcode cache cannot cache class definitions without violating the PHP semantic.

    While APC can cache the opcodes, it must still execute them and build up the classes on each and every request, it must build the methods/functions etc. As I understand it, even plain old method definitions must be "executed" to have the function defined. So what APC can save is really only the parsing and the file IO overhead. It must still execute the opcodes, juggle symbol tables etc before reaching the real logic which may use these definitions. With Java, .NET and even Rails (in production mode) the classes need not be built on each request. Compared to those architectures PHP does not scale well with complexity/number of classes.

    Quote Originally Posted by kyberfabrikken View Post
    On the other hand, this allows for a much simpler memory-management, which beats the socks of even the smartest garbage-collector.
    Huh? It's not like PHP can skip its own heap memory management. PHP must still allocate and reclaim individual objects from its allocated memory (or does PHP simply not deallocate?). So, the fact that the OS deallocates PHPs allocated memory en block at the end of the process does not free PHP from the overhead of object level memory management. It's not like PHP is a simple stack based language; it still needs a heap. I fail to see how this is any advantage at all? And on top of that PHP suffers the additional overhead of OS level memory allocation/deallocation upon each request. How does that beat the socks out of anything?

    No, I suspect that PHP is forced into the process create/terminate on each request because PHPs memory management is simply not reliable enough to be used in a longer running process.

    Modern, generational garbage collection is very well suited to a web environment. All the objects allocated and discarded during a request will live in the first generation and will be collected very fast.

  23. #23
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by honeymonster View Post
    No, I suspect that PHP is forced into the process create/terminate on each request because PHPs memory management is simply not reliable enough to be used in a longer running process.
    Well, I think the truth is the other way around: that PHP was originally intended to process small scripts, and the memory management was designed to support that scenario. The possibility of long running processes was not taken into consideration, as the garbage collector currently has no way of handling circular references. With the trend towards frameworks and bigger applications, I think it's inevitable that the memory management will improve; I know that there was a google summer of code project to change that, but I'm not sure what came of it.

  24. #24
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    Well, I think the truth is the other way around: that PHP was originally intended to process small scripts, and the memory management was designed to support that scenario.
    Yes, you are probably right. But I suspect that it was not so much an informed decision as much as it "just happened".

    Quote Originally Posted by 33degrees View Post
    The possibility of long running processes was not taken into consideration, as the garbage collector currently has no way of handling circular references.
    So, the PHP GC is reference counted? The circular reference problem is common with ref counted GCs. They are also not as efficient as generational GCs. This is especially true in scenarios where most of the allocated objects end up being eligible for GC (as is the case with web scenarios). Here, the “reference walk” is comparatively short, and the unreachable objects are typically freed and merged in one pass.

    Clearly the “allocate and discard everything” on each request is not a performance advantage. PHP needs to deallocate everything on each request simply because if you did not the process/site would become unstable. That is not an advantage of the architecture, that’s compensating for a memory management which is not up to the task.

    Quote Originally Posted by 33degrees View Post
    With the trend towards frameworks and bigger applications, I think it's inevitable that the memory management will improve; I know that there was a google summer of code project to change that, but I'm not sure what came of it.
    You may be right. I think they also need to look at the language design. It seems to me that the very dynamic nature of PHP does not sit well with the need for every request to have a deterministic starting point. On the other hand, much of the same problem exists for Rails where classes can be cached by the server. Rails can change classes by mixing in modules (or simply changing the definition). But somehow it doesn’t seem to be that big of a problem, perhaps because of a rigid framework?

  25. #25
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By "Rails", you mean "Ruby", right? (Funny how you can't say the one, without the other ..)

    Yeah, PHP is using reference counting, rather than GC. That's what I was getting at. I must admit, I don't really know how the benchmarks looks, but since reference counting is a much simpler scheme, than a garbage collector, it's bound to be simpler. Or am I completely off track here?

    Anyway, subjective perhaps, but performance is far from my main concern, when it comes to PHP. There are plenty of large sites, running on PHP.


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
  •