Kiss My App

Friday, September 03, 2004

MVC Frameworks

After playing with multiple MVC frameworks, I've come to a reoccuring conclusion that they are crap. If I want to use Struts, I have to write Actions and ActionForms, if I want to use WebWork, I have to write Actions, if I want to use Spring's I have to write the same types of objects. JSF is kind of what I'm looking for. Basically, MVC frameworks shouldn't require me to write code to adapt to their framework, the framework should use the code I already have.

With JSF, I use EL-like markup in configs to modify the state of my objects and call behavior on my objects. If I were to use one of the other frameworks, I would have to script, in Java, the behavior or state changes to fit inside of their MVC framework. This increases the complexity of my application, decreases reusability, and decreases testability. I laughed to myself when I read in the struts-dev forum about people trying to expose Struts Actions as web services. Nice, I hope your company has an excellent pre-nup with the technology you married.

Some of the issues with controllers you can run into are:
  1. Changes in session variables, such as the account you are working with
  2. Caching of scoped data
  3. Testability
  4. Reusability
The holy grail of controllers? Beans. Beans have state and they have behavior. I can 'new' myself a bean in a JUnit test and I can instantiate it from any MVC framework out there. JSF promotes this kind of controller behavior through getters/setters and action methods. Behavior and state is encapsulated in units of work. Set the account id on a bean, then ask for all of the products you've ordered. Simple, plug that bean into any framework you can come up with.

One of the other points I brought up was handling state changes. Lets say I have an 'Order' bean in the user's session. I also have a global 'Application' bean that contains the current Account the user is ordering with. Being the state of the web, I could be working with the 'Order' and the Account could magically change on you. How do you suddenly respond to that when you are working with an 'Order'? Simple, PropertyChangeListeners. Refresh your state on the next request when the Account changes, no "cache the data in the session, retrieve and check the account it was good for", you will know if/when the account was changed during the lifecycle of your beans.

In summary, pull your logic out of the MVC framework you're using. Put it in a POJO bean that implements Serializable and progress with confidence through testability and reusability.

1 Comments:

Post a Comment

<< Home