CFUNITED - Coldspring and AOP Made Simple

CFCs objects have the very useful ability to utilize other CFC objects within themselves. For instance, I may have a USER object that handles all aspects of a user, and an EmailServices object that handles aspects of email for my application. By creating an instance of my EmailServices object inside of my User object, my user object can, internally, utilize whatever methods EmailServices provides. In order to accomplish this from a coding perspective, however, we essentially have to do one of the things that OO says we shouldn't: hard code the relationship. This is the niche Coldspring fills.

Coldspring is a framework that is essentially an object factory. If you're using Coldspring, then whenever your app needs an object it asks Coldspring to instantiate it rather than the code instantiating it itself. In our previous example, rather than have our User object creating an instance of EmailService, Coldspring has already been informed via an XML file that whenever we ask for a User object it should ALSo include an instance of the EmailService object within it. Coldspring has just allowed us to keep our components decoupled, and this is a very good thing. Now, if my EmailService changes the way it is instantiated, I don't need to go into every other component that utilizes it and alter the instantiation code. Since Coldspring will be the one creating the EmailServices object, it will deal with those changes alone. By passing the control of object creation to our Coldspring factory we have implemented the buzzword mentioned in this session's title: Inversion of Control.

Dependency Injection is another buzz phrase associated with this topic, and essentially refers to the scenario where one object is depending on another (our User object depends on our EmailServices object), and the fact that Coldspring is 'injecting' an instance of the EmailServices object into our User object...Dependency Injection. There are two types of dependency injection, each one differing only in the way that the User object internally refers to the EmailServices object. The first type, called "Constructor-Argument injection", means that the EmailServices object will be passed in via the constructor of the User CFC, in the init method. The second type of injection is called "Setter Injection". With this one, rather than passing in the EmailServices object during instantiation, we're simply going to "set" it as a variable within one of the User object's methods. Here's why two methods even bother co-existing: circular dependency.

Circular dependency is another way of saying that object 1 uses an instance of object 2, and object 2 uses an instance of object 1. If you tried to use Constructor-Argument injection, CF would not allow you to have this circular dependency. By using Setter Injection, however, you can.

Lastly, Dave Ross elaborated on another facet of Coldspring called Aspect Oriented Programming, or AOP. In a nutshell, AOP is what allows you to take one method from a given component, let's say the LogIt method from the LOG.CFC, and cause that method to be executed at various times and places throughout your application. As an example, let's say that you wish to log every action executed against a user record, as well as when logging in or logging out of the application. Old-School style, you'd have to go to each of those methods and add a line to perform the logging. Ah, but with the beauty of Coldspring and AOP, you simply set up logging within the XML configuration file that already defines the relationship between CFCs, adding a few more definitions telling Coldspring to execute the logging before, during, or after the execution of other CFC's methods. Niiiice.

Setting up Coldspring is not or the faint of heart or those who are convenience enthusiasts, but if you will take the time to learn and implement it, you'll find yourself a better programmer for it.