Inversion of Control and ColdFusion: Using ColdSpring Dave Ross CFUNITED – The premier ColdFusion conference www.cfunited.com

Framework? Not like M2/MG/FB4 – it’s not involved with http requests “Container” may be a better descriptor – but ColdSpring is really about how you structure and manage your application’s model June 28th – July 1st 2006

“Spring is the best thing to happen to programming in 20 years” – Antranig Bassman, RSF Lead, SEPP Conference Vancouver 2006 ColdSpring was “inspired” by Spring – we’re not porting all the functionality, but solving the same problems. June 28th – July 1st 2006

“A Rigid Model” In a rigid (inflexible) model, a given component creates all of the other components it needs. You’ve effectively hard-coded the implementations to each other, and as your model grows in complexity this exponentially becomes more difficult to maintain. A flexible model contains communication within – components use each other, but nothing else. How do we facilitate an environment like that? June 28th – July 1st 2006

How do we set up a flexible model? Someone has to do the “creation” for your components – this is where the term “inversion of control” comes from. When one component need to use another, we call it a dependency (and the two components are known as “collaborators”) ColdSpring, as an inversion-of-control container, “injects” one component into another. Thus “inversion of control” can also be called “dependency injection”. June 28th – July 1st 2006

Collaboration in Software We often strive to reduce the coupling between components (tenet of good Software Design) It’s difficult to reduce coupling and still have your components collaborate (duh) Dependency injection helps reduce coupling by eliminating the aforementioned “creational” burden on components – no longer do components have to create and configure each other… they just use each other. Also, because components are not creating each other, the actual implementation (the actual type of the collaborator) becomes unimportant - as long as the methods are there then the dependent component is happy. (“program to an interface”) June 28th – July 1st 2006

Tenet 2 – up the cohesion We also strive to increase cohesion – make our components do one thing and do it well. Dependency injection encourages cohesion by eliminating “situational” burden. Creating and configuring other components is outside the scope of what your component is meant to do - much better to just give them only the things they need. More cohesion means a higher percentage of the code within a component is focused on solving the business problem at hand. June 28th – July 1st 2006

Tenet 3 - polymorphism Again, components don’t care about their collaborators implementation, we have a perfect environment for “swap-ability”. I can swap one implementation of a component out for another and collaborators wouldn’t know the difference. You can either have components extend an abstract “psuedo-interface”, or use “duck-typing” (type=“WEB-INF.cftags.component”). June 28th – July 1st 2006

Dependency Injection: how it works at a glance One form is called constructor-argument injection In the animation below, UserService needs to use the EmailService to send some email. With that in mind, first we create the EmailService, then pass it as an argument to the UserService’s constructor (in ColdFusion we use init() for a constructor ) UserService EmailService EmailService Remember, components are passed by reference, so the UserService isn’t the only component that could potentially “use” the EmailService. June 28th – July 1st 2006

Another form of DI Called “setter-injection”, we expose our dependencies via a setter-method (e.g. setEmailService(emailService) ) Supports “circular dependencies” – watch below UserService EmailService UserService EmailService <cfset EmailService.setUserService(UserService)/> <cfset UserService.setEmailService(EmailService)/> June 28th – July 1st 2006

Configuration is a dependency You could think of simple strings used for configuration as collaborators as well (especially when they become structs, arrays, or full-blown cfc’s) Passing in configuration values to the constructor of a component (or via. setter-method) has long been “best-practice”, a dependency-injection framework like ColdSpring just makes it easier. June 28th – July 1st 2006

So ColdSpring does dependency injection, how do I use it? You create a xml content that defines your components and their configuration. We refer to the content as “bean definitions” or “bean defs”, but “bean” is interchangable with “component”. You create a ColdSpring “BeanFactory”, and then pass in your bean definitions. June 28th – July 1st 2006

Ok, now what? When you need a component, you ask the BeanFactory for it via the getBean(…) method. You ask for it by the id you gave it in the <bean/> tag. You then use the component how you would anywhere else. We’ll just <cfdump/> them for our example June 28th – July 1st 2006

<bean/> syntax <bean/> defines a component within a ColdSpring BeanFactory id=“something” the name/identifier you are giving the bean within the factory class=“path.to.cfc” the actual cfc type you want ColdSpring to use. June 28th – July 1st 2006

Children of <bean/> Dependencies are then expressed using the child-tags: <property/> (for setter-injection) and <constructor-arg/> (for constructor-arg injection) Children of <property/> and <constructor-arg/> can be <value/> (arbitrary string value) <map/> (struct) <list/> (array) <ref bean=“idOfBean”/> to reference another <bean/> in the factory <bean/> to define another explicitly within an enclosing <bean/> June 28th – July 1st 2006

So how is ColdSpring used in a typical application? When your application starts, a BeanFactory is created and supplied with bean definitions. The BeanFactory is placed in a persistent-scope, like application, so that the <bean/>’s within the BeanFactory are true singletons. In an MVC application, the controller layer would obtain the component(s) it needs from the BeanFactory (typically during startup) ColdSpring is not usually involved with the creation of transient or value objects, because that would require “knowledge” of the framework by other components. The idea is that your Model has no idea it’s “managed” by ColdSpring. June 28th – July 1st 2006

Tiers, Layers (typical architecture) June 28th – July 1st 2006

What else can the Bean Factory do? Auto-wiring Let’s ColdSpring figure out which components should be injected where (“wiring”) by looking at the method-signatures of the components you define and seeing if it has any matching bean definitions Two settings: byName or byType Can be set on all <beans/> via. default-autowire=“” attribute or on an individual <bean/> using autowire=“” For example, if autowiring is “byName”, and ColdSpring sees a setBob(…) method in your component – if it knows “Bob”, then it will perform the injection. Pros: Less typing and less xml – just add a setterMethod/constructor-arg to your component and the dependency is there upon next reload Cons: Loose track of which components are getting injected where June 28th – July 1st 2006

What else can the Bean Factory do? You can use your own factories (objects that create other objects) with ColdSpring First you create the factory like any other ColdSpring <bean/> To define other <bean/>’s that are intended to be created by your factory, instead of class=“” you use factory-bean= “idOfYourFactory” factory-method= “factoryMethodThatCreatesObjects” <constructor-arg/> children of a factory created bean will be supplied to the factory-method as arguments. <property/>’s are injected into the resulting object as normal. June 28th – July 1st 2006

ColdSpring AOP In a sentence, AOP allows you to apply a piece of code across the rest of your codebase in logical places, like before or after a method call or when an exception is thrown. There is a lot of confusing terminology in AOP, but it’s not that hard to use once you see some examples. June 28th – July 1st 2006

ColdSpring AOP To use ColdSpring AOP, you write “aspects” which extend some of the frameworks base “advice” classes, the names should be self-explanatory: BeforeAdvice AfterReturningAdvice AroundAdvice aka MethodInterceptor ThrowsAdvice June 28th – July 1st 2006

ColdSpring AOP Next, set up an “advisor”, which contains your advice and the method names you want your advice to be involved with using coldspring.aop.support.NamedMethodPointcutAdvisor Set up a “proxy” for your target component (the one you want to apply advice to) using coldspring.aop.framework.ProxyFactoryBean Supply the proxy with your advisor and the target component June 28th – July 1st 2006

What can I use AOP for? Quintessential examples are logging and security. More advanced: Transactions Caching Workflow (we are doing “declarative programming” with XML) June 28th – July 1st 2006

How does ColdSpring do it (in color)? Method Call Returning Value catalogDAO (the Proxy) 6 catalogDAOTarget loggingAdvisor loggingAroundAdvice LoggingAdvisor: “Does this method call match my mapped names?” LoggingAroundAdvice logs the method call catalogDAOTarget (the real catalogDAO) executes the method call June 28th – July 1st 2006

AOP Advantage Like dependency injection, AOP can vastly increase cohesion For example, things like security, logging, workflow or caching would be sprinkled into many components. AOP allows you to extract this code into a single component and broadly “apply” it to the others Again, your code becomes more focused on solving the business problem at hand (logging is not a business problem). June 28th – July 1st 2006

Remoting and ColdSpring The old way: Use a “remote façade” (thrown away after each remote request) which forwards method calls to the appropriate component by accessing the BeanFactory in a shared scope (usually application-scope) The new way: ColdSpring’s AOP framework can automatically create remote stub objects for whatever components and methods you want. This means you can turn remote access to any part of your Model on and off declaratively June 28th – July 1st 2006

ModelGlue and ColdSpring ModelGlue 2.0 is the first framework to use ColdSpring as the default IoC container for users and for the core framework itself (meaning ModelGlue 2.0 is actually itself put together with ColdSpring). This means you could swap in your own implementation of core ModelGlue classes – change functionality without modifying the codebase. June 28th – July 1st 2006

More info Website: http://www.coldspringframework.org JIRA Issue Tracker: http://code.coldspringframework.org (report bugs/request features) Blogroll: http://www.d-ross.org (Dave Ross) http://cdscott.blogsport.com (Chris Scott) http://www.corfield.org (Sean Corfield) http://www.jroller.net/kdub (Kurt Weirmsa) http://clearsoftware.net (Joe Reinhart) June 28th – July 1st 2006