Saturday, November 26, 2005

ColdSpring: Better Model Management

I've been working for a couple of days on MachBlog, which I hope will become a great real-world sample app for Mach-II and maybe even something people will actually use. ;-) I'm also using this as my opportunity to dive in and learn ColdSpring, which if you haven't looked into it yet is an Inversion of Control/Dependency Injection framework for ColdFusion that plays very nicely with Mach-II.

Even in something as relatively simple as a Blog app when it's built with a domain model things can get semi-messy rather quickly. Just as a very simple example, numerous objects in the app of course use a datasource, and I'm encapsulating the datasource information in a simple datasource bean. The datasource bean in turn contains information such as the ColdFusion datasource name, the database type (SQL Server, MySQL, etc.), and the database user name and password in the event the app is used in an environment that requires this information.

Even if the datasource bean parameters are stored in a traditional configuration file of some sort, having to construct that datasource bean every single time I need it within my other objects can get rather cumbersome. Now imagine nested objects, for example a UserService that contains a UserGateway and UserDAO, and each of these objects needs a datasource bean. Managing even that simple scenario is already getting nasty.

Enter ColdSpring, which manages all this junk for you. By using a simple XML configuration file and in my case the Mach-II plugin, I don't have to worry about all that stuff. I just tell ColdSpring how the objects related to one another and in my CFCs I indicate that these dependent objects are arguments to an init method, and that's it. I don't have to worry about nested objects within my CFCs or even calling CreateObject() for the objects I need. Using the example above, if my UserService needs a UserGateway, and the UserGateway needs a datasource bean, all I have in my UserService's init method is the UserGateway indicated as an argument to the method. Then I can set that argument to the variables scope or do anything else I want to with it, but ColdSpring "gives" the UserService the appropriately configured UserGateway object.

I'll post more as I build this app out but I'm already seeing a huge benefit to doing things this way. It reduces complexity and increases flexibility, and your model doesn't have to know a single thing about ColdSpring to take advantage of this. In Mach-II's case the only objects that have to know about ColdSpring are the listeners. Bravo to Dave Ross and Chris Scott--keep up the great work on this!


I'm currently developing a Mach-ii application where each database record is stamped with the username and date-time when modified. I'm thinking that injecting my session facade into the DAO objects with ColdSpring might make this process a little easier.

No comments: