This post originated from an RSS feed registered with Java Buzz
by a san juan.
Original Post: When is NOT having a Front Controller a good thing?
Feed Title: small devices in my dandelion patch
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: J2ME, emergent software and other tiny things.
The clean separation of business logic from presentation is the one aspect of MVC that everyone agrees is a good thing, and of the lot using Front Controllers (such as servlets) to separate out control from the view (in this case JSP pages) IMO creates the most maintainable and elegant solution. The servlet (and there could just be one main servlet) not only controls the flow of execution, but handles access to the underlying business objects.
In the java world, this is preferable to using a JSP only approach, where both control flow and access to business objects is dependent on the provider of the view.
But when is having a Front Controller pattern a problem?
Well, it seems that this is exactly the problem in PHP, which is arguably the most popular scripting language in use today to create web sites. PHP has no equivalent to servlets, and each request initializes a fresh PHP environment. Thus, PHP is limited to using so-called Page Controller designs, which basically is equivalent to a JSP-only solution.
Instead of lamenting this fact and arguing for a better solution, some PHP developers have instead argued that this inability is actually a virtue. One website notes:
Does this reloading of all data on every HTTP request mean that PHP is not scalable? Fortunately, as I've said before in other posts, that's a superficial view of things. The reloading of data is precisely the reason why PHP is scalable. The way PHP works encourages you to code using state-less designs. State information is not stored in the PHP virtual machine, but in separate mechanisms, a session variable handler or a database.
I could argue quickly that storing state information in a database is not exactly the best way of going about getting performance and scalability out of your web application, or that having no clean separation of MVC will sooner or later create huge, unmaintainable code for any massive project, but I'll instead point out that this guy basically highlights one big difference between Java and PHP: Choice.
PHP was originally meant to be a fast and dirty way to create web pages, and the negative effects of this origin still shows years after it popularity has boomed. By developing in Java, I have the choice of either using the PHP type design pattern and incur maintainability problems in future, or use the more reasonable front controller approach via some third party framework (the prefered method) or one of my own devising.
Previous Topic
