Reflecting on MVC
I've probably written a half a dozen solutions to MVC. All of them a discarded in a folder on my G: drive, never touched again. Every once and a while, after sitting with a notebook, I'll add another one to the G: drive. Maybe the 'G' stands for graveyard.
The other night, I watched a DVD documentary on the band, Keane. It rambles on to a comment from Tim Rice-Oxley about writing songs; how before they had a hit, he could sit down and just let the ideas flow-- how now there's an expecation that everything he writes has to be a hit. It's just not the same anymore.
In some foreign form, I think we can feel the same way. We work so hard to have that one hit, to create that solution that everyone loves.
I know that I will forever adding more ideas to my G: drive. It's not that the solutions are bad, just that the bar has been set. Everything evolves into some form of what's in place with JSF. Of course, each person has their own ideas as to what the perfect solution is, but JSF is my benchmark right now.
All the solutions start out with the idea of having a tree of components that operate on the model. Simple enough. My definition of a component is something that can be evaluated as part of a greater whole or separately. They also participate in all parts of MVC-- rendering, validation, updating, decoding, etc. The important thing is that they can be evaluated independently, and JSF already captures this with it's naked approach to exposing the whole component tree to the developer.
This is usually where I get frustrated and stop.
Everyone's so concerned about overhead of JSF and component solutions. Again, every ounce of data I've seen showed that JSF performed closely with solutions like Struts. At JavaOne, in the 'MVC Bottlenecks' BOF, early releases of MyFaces 1.0 were only had 6% less throughput and results like this make me scratch my head-- most graphs show only a few millisecond difference. I know some had mentioned scalability issues, but what was the real issue?
What about the comments that there's no front-controller, like Struts, for JSF with GET requests. Again, I reflect on how I've found myself using Action frameworks. I guess having that front-controller helps if I need to deliver an alternate view. Truthfully, I find that I really only have one view I ever associate to GET requests. All other conditions are considered errors or my single view displays the appropriate message. Authentication/Security is usually handled on a global level... so I've basically lost my need for a front-controller for GET requests. Yes, I do run into cases where I need to deliver alternate pages, but their all part of some transaction via POSTs and JSF has that covered.
Let's keep that ball rolling. Lets say you want to go from a GET request to another GET request with JSF? No one says you can't simply render an HTML anchor tag with a 'hand' generated URI. It's the same thing you would do with Action frameworks.
Despite all of this, I don't expect everyone to use JSF. Most people question the scalability of JSF, but again, I haven't seen actual benchmarks that proves it was an unsolvable issue either within the guts of a particular JSF implementation or within the hardware running the application. Is it even an issue when there's only a 4-6% difference? I guess to me, it's not a question of how easy a framework can scale on the hardware, but how easy it can scale use case requirements. Why do you choose full-ORM solutions over straight JDBC? I guess one could reach a point, just like with ORM, where performance starts to degrade. Is it the ORM's fault or is it because the ORM allowed you to easily do overly complicated things? Could the same be applied to component frameworks for all they provide to you?
JSF will always be a work in progress, just like every other framework out there. Even today, I got excited about JBoss's Serialization announcement since it could allow for an improved, plugable StateManager. So many times this evolution of enhancement has already occured in different ways with JSF-- but the tune is still the same.