programming problem solving

I have been working on my little developers application, with the intention of implementing pure OO techniques and coldSpring. I am also implementing machii framework version1.6. I will start to exploit the new machii features later in this process. For now, its more about proper modeling of classes or components. Keeping things where they belong. I mean keeping the model layer agnostic of the application that is using it, keeping bus logic in the service or model layer. Keeping validation logic in the beans, avoiding anemic bean syndrome.

Initially, i put the object creation code in the service for its dependent dao and gateway objects, got that working, then plugged coldSpring into the machii framework, ensured that was ok by creating the pointer object into the coldSpring bean factory (the CS black box). Once that worked, i added the acual bean creation code to the services.xml file (thats the one cs consumes to read your component definitions. I defined the service, DAO and Gateway components in the services xml file, with the DOA and Gateway as ref. objects within the services object. I then added the setxxx methods to the service object and finally removed the code from the init method in the service.

Once that was working, yea! I ran across a blog where someone mentioned creating a utility debugger and using it to dump from within a cfscript block. I probably read something like this before, but i was not ready to grok it. Now, i groked it. I set up a utility cfc and registered it in the coldSpring container (services.xml) and referenced it from the bootstrapper object, Application.cfc. I created a application scope on it, so i could reference it from any objects in the model. Ive used it a couple times already, and find it very useful. Brilliant!

Think of coldSpring as an attachment to the model layer. At application start, there has to be some instruction that says reference and scope the beans that are defined by the coldSpring framework in the services.xml file. This does create a thin layer of coupling between the application and the model layer, but its contained to a single bootstrapper object that has the knowledge of the coldspring framework.

Think abstraction. The more abstraction, the better. Abstraction = less knowledge of the collaborating entities. There will always be some coupling, but it is favored to reduce that coupling to its purest form.