Designing Framework-Agnostic Models with CFCs, by Brian Kotek

Notes from Brian Kotek’s talk on Framework-Agnostic Models at Frameworks 2007. To get a good handle on what constitutes a model, Brian starts by going over just where the model lies in the MVC pattern relative to frameworks. Adding queries to your machii listeners directly, or act pages in fusebox, or controllers in model glue is a way your models bleed into your controller. Logic is only reusable by cut and paste, and it’s coupled to the database implementation. The end result is that your controller contains your model logic, when it should really only be controlling your model calls. A better way involves calling the service call here and passing in the values you need. On the other side of the coin you wouldn’t want to pass in a machii event to your model, as that couples your model to your controller as well. Passing values provides a cleaner way, and doesn’t depend on the framework. SO where exactly does the controller end? In MachII it ends at the listener CFCs. In Model-Glue, it’s the controller CFCs. As for Fusebox, he agrees it’s the Circuit.xml file (hey, that’s 3 people hinting at using circuit.xml instead of act pages). Queries, references to session scope and business logic should all be in the model. Any framework specific things like the event and the form elements should be handled in the controller with their values passed into the model. For session scope Brian mentions using a session facade in the model, which allows it to be treated like any other object. With this form, things are properly encapsulated making reuse easier, dependencies minimized and changes much easier in the long run. By adding a service layer to encapsulate a model, it exposes a set of services to be used by any external system. This provides a stable API to the model that keeps it independent of the controller. Think of it as the gatekeeper. Why bother with all this? You’ll be able to switch frameworks (as noted in Matt’s talk earlier), you’ll be able to easily allow flash remoting, web services and ajax calls using the model, as well as easier team development, debugging, testing and maintenance. In his example he uses the same model in MachII, Model-Glue:Unity and Fusebox 5.1. All of these also use Coldspring which allows for automatically creating remote facades which is very slick. Framework independent service layers that are only dependent on coldspring? I didn’t realize how this worked, but it’s actually a form of code generation. You declare a cs bean of class coldspring.aop.framework.RemoteFactory and provice the target, servicename, the relativepath (where the generated file will go), the method names and the beanFactoryName. I think Chris Scott went over this a little yesterday. His example also uses a custom made service layer, but DAOs and Gateways generated by reactor. In the end with all this almost all the code is generated! Basically you’re creating the service layer, telling coldspring how to get the supporting objects (bean, dao, gateway) and letting it go from there. I was expecting some static gateway/dao methods actually, so this was a nice surprise usage of Reactor and probably the cleanest form of a service layer I’ve seen. I’m not sure why this presentation was in the beginner room, but it’s one of the most popular talks I’ve been to by the room size and amount of questions alone.