8:00am Kurt Wiersma - Leveraging ColdSpring To Make Better Applications

Kurt told us that you won't really know you need ColdSpring until you see one of the problems that it solves. It's good to think of ColdSpring as a big box of objects. You can use CS to to assemble your objects. CS is smart and can prepare objects in advance. It makes sure that there is only one instance of each object.

Typical Application Architecture contains Business Objects (or Beans), Service Objects (The API for the application eg. GetUser), DAOs which do single record access to the database, Gateways which do multiple record access, Controllers, which handle http requests, and Views which present the data.

Kurt's experience was of having lots of service objects and wrote remote services manually. Flash remoting CFCs were separate from the main services CFCs. It was difficult to test the DAOs and Gateways.

Using ColdSpring Kurt was able to use an object factory for creating objects and most of these issues went away.

With CS the objects are configured with an XML file, which tells CS what the dependencies between CFCs are. It will set up the required dependant CFCs and pass them as parameter. Doing this is known as Dependency Injection or Inversion of Control (IOC). The Hollywood Principle (Don't call me I'll call you!)

By default all objects created by CS will be singletons and will get cached in application scope. You can specify that beans will not be singletons by adding a parameter to the bean tag.

CS supports AOP, and generation of remotely accessible objects. Plug-ins exist for Fusebox 4/5, MachII and Model-Glue. It also has support for integration with other factories through the factory method attribute. This allows integration with a factory that will create DAOs and gateways.

You can configure the ReactorFactory as a coldspring bean so that you can use ColdSpring to create Reactor objects.

Aspect Oriented Programming allows you to intercept method calls and act before and/or after the call. It is completely transparent. Used for security, caching, logging and generation of remote services.

This can be a very good way to debug an application where logging can be set up to log the calls to a particular CFC or even all CFCs. This will work both with CF and Flex based applications.

Remote Facades can be generated to support Flex. This is done with a remote Proxy Factory. This was much easier than doing it manually.

The service layer should contain all the business logic rather than in the controller, this makes moving from a CF to Flex application easy.

AppBooster is a sample application using MachII and ColdSpring.

Provides a simple model for users, addresses, and roles and can be used to form the basis for a typical application.

What tips are there for new ColdSpring Users.

  • For a new ColdSpring application its recommended to do a simple project first to get to know it. Eg a ToDo List. Build one set of screens to create and update a task.
  • Brian Rinaldi has a great code generator on RIAForge.
  • Favor setter injection over constructor injection when setting up your services. CS finds it easier to call setters. This uses property tags rather than constructor-arg tags in the CS XML.
  • Join the ColdSpring mailing list.

http://coldspringframework.org
http://cdscott.blogspot.com/
http://www.d-ross.org/
http://jroller.com/page/kwiersma/

You can download appBooster from the blog. Kurt will update it with the flex interface soon.

Another good code generator is cfcPowertools.

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.