| SitePoint Sponsor |
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.
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.
There's the Event Driven Model >.>
?Originally Posted by imaginethis
Event Driven Architecture
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.
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.
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.
"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.
working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
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.
This is called the document view pattern. Its a commonly used and is described in a lot of desktop MVC implemetations.
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.
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.
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.
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.
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?
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.
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?
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...
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.
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.
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.
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.
Yes, you are probably right. But I suspect that it was not so much an informed decision as much as it "just happened".
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.
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?
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.
Posting Permissions
Bookmarks