Wednesday, August 20, 2008

Frameworks, MG, Machii or Custom

I've been messing with MG the past couple days. I have a small application im working on, and decided to give MG a go. Things were going fine, it was taking me longer to solve the problem because i was learning the framework. This is ok, acceptable when learning a new framework. I spent a bit of time listening to podcasts, reading blogs and looking in the official Model-Glue documentation center. Once i turned the corner on getting the MG controller to set the args properly from the event - i was on my way. From this point, MG facilitating communication between my gui and model just fine.

It was about this time that i started to feel like it was a bit overkill, the framework is pretty light, lighter than machii, but i still was not feeling good about the use of it in this case. I just was not doing that much and felt like the overhead and increased complexity was not worth the cost. Like a big brick, the vision of a streamlined *custom framework hit me in the head. I could hear Simon Horwith whispering in my ear. So, i decided to scale back a bit. I used the index.cfm file to handle the bootstrapping and the rest of the setup work. It reminded me of the fusebox settings file, where application level variables and pointers are set up.

Index.cfm is now responsible for creating the object pointer into the service and also listens for actions (*events) such as insert, update or get. Thats about all this GUI is doing. Depending on which action is executed (listened for) i am calling the appropriate service method and passing along form or URL vars appropriately.

These are the following design principles adhered to:

*MVC design pattern
*separation of concerns (view just reacts to what is provided via the controller (index)
*encapsulation of bus. logic (all in CFCs)
*asynchronous calls, where helpful to user
*no SQL in the views (see above)
*safer from spammers and hackers, SQL is down stream protected by the service layer.
*no extra overhead (MG or Machii or Fusebox)
*intuitive - less complex

tradoffs

not as scalable as MG, Machii or fusebox

If the requirements dictate, and a more scalable framework becomes necessary, i can simply trade in the index.cfm with its event and listening responsibilities for a MG or MachII framework, where we can use an XML style central controller with specific listeners or messages. Since i put the bus. logic in the services and the database interactions in the DAO, Gateway - its a can of corn.

No comments: