I had some time this weekend to do more on the scaffolding project. I know its been slow but I seem to have too many things to do and often when there is time there may be none of the inclination which is needed for good code.

Anyway for an update I decided that Reactor was a problem with no solution in many ways. There is really no way to do some of the things I wanted to in Reactor, so I decided to take another route and generate all the DB access code myself. I've spent a few days over the last three weeks creating templates for all the usual DAO, Gateway, object, service and so on.

[More]

Chris Scott gave a very detailed review of ColdSpring and how to use it with Flex. Unfortunately there was so much content I did not get most of the detail in my notes so I just have the bits that really interested me here.

[More]

When building MVC applications it's possible that the model can bleed into the controller. For example this can happen when a listener is being created in MachII and it seems easy to add SQL to the listener. Other Frameworks can have the same problem.

The other thing that can happen is with persistence or caching which gets hard coded as session or application scope and is difficult to change.

It is important to keep the controller and model separate. Controller should be as dumb as you can make it. The model should be able to be used by any framework and the controller should be able to use any model.

Ideally your model CFCs should be able to be used by any framework and one way to help is to ensure that they only do a single thing.

Services layer should be used to encapsulate the model and prevent the controller from bleeding in to the model or vice versa.

There are some big advantages for the Framework Agnostic Model.

Possible to switch frameworks
Use with CF, Ajax and Flex
Easier debugging
Easier testing
Easier maintenance

Brian has created a sample bookstore application that is built with three different frameworks, Model-Glue, Fusebox, MachII. The application also uses ColdSpring and Reactor to create and organise the model and can be downloaded from his site.

ColdSpring is also used in the examples to create a remote façade for Flash Remoting or web services.

There was an interesting discussion on the code in the example and how it worked with the different frameworks to move data from the model to the view.

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.