hard core refacoring

I have spent the past 2 days retooling the model layer of a mach-ii application.

I have renamed numerous listeners and moved then into a new listeners folder. I am really trying to promote the idea of model and application autonomy.

/listeners/ objectNameLister1, ... objectNameListerx

/model/objectName/ service, bean, DAO, Gateway

Each time i renamed a listener, i did a careful search of the controller to update all instances of the old listener name. In some cases, this was only a couple instances, in others, there were many. This also gave a sense of what parts of the application are more widely used.

In a few cases, i renamed a manager that was really a listener, moved it into the listener folder and created a new service cfc. The new listener should only speak to its registered service, so i had additional refactoring to do in the listener. I updated methods that had knowledge of the DAO and Gateway moving that into the respective service. This supports best practices of the listener being coupled to the application and bus. logic living in the model layer, not the listener.

Think about the model layer as application agnostic. Your model layer should be usable by another application. Imagine there is no mach-ii framework with listeners to invoke services. Another application may want to use the objects in your model layer. I moved ALL knowledge of DAO, Gateway and other services from the listeners into their service. The service is the king of the jungle, not the listener. The listener just passes things along.

There were a few listener methods where i left bus. logic in place, but that logic is dealing with announcing of events, making it application logic, which belongs in the listener NOT the service.

Changing the location of the listeners required me to update the path in one place, the mach-ii listeners configuration. If i changed the location of the model classes, i had to change the path of the object invocation (init) method in the service, DAO and Gateway. After doing this a few times, i really stated to see the beauty of the coldSpring layer, which encapsulates this type of change into a single entity, the coldSpring.xml file. I also saw that some of the objects are not taking advantage of the coldSpring framework. These are candidates for coldSpring.

When i encountered listeners and services that had an empty configuration or init method, at least in terms of object creation, and i would see pointer references in class methods, i knew those pointers were defined somewhere, who would have knowledge of such pointers? I also noticed a set method that accepted the object itself at the bottom of those classes. Each of these things is a clear indicator that there is an object management framework in play.

I am still getting my head around how coldSpring is doing things, i thought i would deploy all these changes first, then work on a coldSpring deployment separately.

Things are jelling now, jellin like a felon, architecturally speaking.