Evolution of a MVC application

I have been tasked the honor of bringing others into or up to speed with a big MVC application. That's ok, i used to be a teacher and trainer, part of my brain enjoys the mentoring role.

I have been studying the architecture of the application, doing some reverse engineering for awhile and have a little summary i would like to share. Blogging this stuff helps me internalize and forces me to think more critically.

In the beginning our application did not use services. Most entities were created following the

Bean
Manager
DAO
Gateway

design patten. Which is fine, except the managers are actually the listeners, they are extending the mach-ii framework listener. All of these files are located in the root of the application in the model folder. Object instantiations to the DAO/Gateway occur in the managers (listener) constructor. The manager is trying to act like a manager (service) by creating its dependency objects (DAO, Gateway) in its constructor. Thats fine, good practice.

As the application grew, real managers started appearing, but not in the model folder (that should just be listeners) in a org. path. The idea of the org. path is to promote the concept that the model or bus. layer is application agnostic. It should not live in the same file structure as the applications listeners. Ill buy that.

The managers, playing the service role, live in the org path along with the other depenency objects, DAO, gateway and Bean (value bean). The managers (services) are responsible for instantiating their dependency objects (DAO, Gateway and bean). The listeners in the model path are only instantiating their manager or service object.

As sub applications start appearing, listeners are where they should, in the model layer and in a couple cases, the related bus. logic (bean, service, DAO, Gateway) appear in a folder beneath the model layer. This is ok, but does not seem to promote the idea of reusable model layer components or agnostic model layer.

In most cases, the listeners are instantiating their service object in their constructors while the service is instantiating their dependent objects in the init functions.

Eventually, ColdSpring was introduced to start managing all these object and dependency object creation. ColdSpring is a framework that abstracts the knowledge of dependencies from the actual objects. Ill study more on this as it appears some objects are not yet utilizing this feature.

Most of the application is following OO practices, meaning that object references are being passed along to service and DAO funtions that are requiring them and using the reference to the bean to handle updating or persistence requirements. Gateway functions are typically accepting values, not references and returning queries.

Some of the application functionality, like the stuff i wrote, is using object wrappers but is too often using procedural pass by value and not object reference. It was not until recently that i really started looking critically at this and reading in blogs why this is problematic.

As i continue to stretch my brain and teach others about this application architecture, i will continue to re-factor and implement OO practices.