I stumbled across a blog today...

Written by a former co-worker. Turns out he wrote the blog application using machii. As i dug down into the application, i was pleased to see so many best practices in play. Just a few:

the application uses filers and plugins wisely, uses event-args in view pages, this creates a single point of edit - so we always know where to find variables defined in view pages in the event that is including the event.

view, controller(s) tightly coupled, along with the plugin and filter CFCs - they are part of the application.

A sub application to handle administration duties.

The model layer contains the listeners, which i prefer to store in a separate physical folder - since they are part of the application, not part of the model. The *entities modeled in the application are organized by entity folder with a bean, manager (i would have used service) DAO and Gateway in each folder. One of the entity folders did not contain a bean, so the developer was not blindly following the 4:1 design pattern, thats a good thing. He could have had combined service or manager responsibility for a couple of the entity managers. They are similar and both are a little light.

The listeners seem to be only passing control along to its respective manager, while the managers are instantiating their dependent DAO and Gateway objects. There is no ColdSpring or other model manager at play. As a consequence, the collaborating components have knowledge of each other sprinkled in to each other. Listeners are instantiating managers, managers instantiating DAOs, Gateways and other managers.

Listeners are referencing controller properties to pass along as args to managers. If a model manager was in play, it would be doing this, promoting lesser coupling between the listener and manager (application and model).

Objects treated as objects, passing by reference. The DAO is passed in a reference to its bean and uses it when updating the database.

Filters with configure methods, like listeners, they use configure not init for initialization and reference controller properties, since the filters, plugins and listeners are all registered in the controller - they all can access the properties. One difference is listeners extend listeners, filters extend filters and plugins extend plugins, all different parts of the machii framework. Remember to think of the plugins as cross cutting - or needed across all events in the application. In the plugin configure method, there is a UDF object created that is called in the pre-process of each event to get a tick count - what a geek. Interesting too that the developer stored the UDF.cfc with the views?

Remember each non-correlation table *should have its own bean to represent a record from the table when that record is in play. That bean should contain its own validation logic, avoiding the lean bean syndrome. A gateway to aggregate larger number of records from the table and a manager to handle requests of the bean, DAO or gateway.

In summary, lots of abstraction and encapsulation - promoting reuse and ease of maintenance.