Here’s the problem I have with so-called Model-View-Controller frameworks like Rails.
They seem geared towards a single application per implementation.
What do you do with a request that wants to work with multiple components? Or perform multiple actions.
Then a REST-style request such as
falls flat on it’s face, because you’ve either got a bunch of complex logic, or actions loaded as parameters:
You could get it from the session, configuration, or whatever, but then you end up coding in XML or whatever.
<result condition=”success” action=”doY”>
And then you’ve got to worry about templating, localization, etc.
And you still need a front controller to handle things like user authentication, session management, request routing, etc.
You could have a page (request) controller extend a base controller, but it’d be nice to take things like authentication a la cart, and not need to load it on every request. Appservers handle this by loading everything and holding onto it, but this is resource intensive. You think a mod_perl app can get ugly, but pushing everything to tomcat, websphere, or mongrel gets just as ugly, though the separation is sometimes cleaner. FCGI forces you to separate your ruby out, but the temptation with mod_perl to put it all in the front end is dangerous. Or you end up on the other end, like so many java apps, duplicating stuff over and over in multiple layers of abstraction on multiple servers. You could just as easily mod_proxy to your mod_perl appserver just as easily as you mod_jk to tomcat or FCGI to mongrel though.
But back to MVC frameworks. How do you handle multiple action requests without getting ugly? And how do you provide helpers and components and templating without forcing one way to do things?
One answer is CMS frameworks: CMS being short for “admin user interface, layout template, and component library”. And that leads to my next post:
The problem with CMS frameworks.
One thought on “The trouble with MVC frameworks”