I have conversations with people I work with, regarding the pros and cons of employing a framework like Coldspring. Well, ColdSpring in particular, actually. While explanations of its benefits have been present, there has lacked a concrete example that I could share with with my coworkers and comrades. The benefits realized from loose coupling of objects have been demonstrated, and ColdSpring is a way of moving toward that end, but that is fairly abstract. Also, as trends in OOP have moved away from inheritance and have leaned toward composition, the process of decorating or injecting the objects in this model, is also worthy as part of a prevalent approach, but it remains too abstract. The notion of logging, or security, or changing the DSN does not get people too excited about putting ColdSpring into place. Instead, Coldspring could be the source of a whole new batch of problems without even giving any benefits in return. And the notion that everyone is doing it, brings requests for a new glass of Kool-Aid.
A real example that can be seen by our organization comes with the wave of demand for Dashboard enabled applications with analytics, and metrics that could never be satisfied. (I will lay aside for this writing, my thoughts and concerns on Dashboards, and the dangers of their overuse). So, in this perhaps hypothetical situation, we have a customer who uses our eCommerce application, and decides that he wants some real time metrics, of things which do not neatly fall into one table or another, and might require some data consolidation, or something, to pull what he wants to see. Let’s say he wants to know what aisle of the store people spend the most time in (category), and of those, how many buy product. For people that hang out in category A, how often are their carts abandoned. Do people get lost in aisle A? Questions like that bubble through the storeowner’s head, and he pictures a dashboard, with a realtime visualization as solving the problem. Now, it could have been anything. We don’t track which aisle people are in, only what they put in their basket. And we don’t pair that with the cross sells. How can we get the data that he wants without making huge changes?
The important thing to note is this: The huge changes that need to be made to facilitate this customer’s desires do *not* benefit the shopping workflow at all. They are a separate concern. A possible solution, with ColdSpring, would be to introduce an AfterAdvice, which would feed the desired data into a log, which would be fed to the dashboard, and so on. So, this could be done without any major impact on the workflow code itself. This is huge. This could have made the shopping cart code just a little bit more complicated. Instead, it has left it alone.
In some ways, having programming in database scripts, Oracle PL/SQL procedures and triggers, this dependency injection is not so different. It is just happening at a different layer in the process. In fact, I had thought of using database triggers, at first. It took a little while to realize that this would be a decent situation for using ColdSpring, and realizing some tangible benefit from it.
Now, with a concrete example in front of me, I can think of another situation, which again, could have been dealt with using database triggers, that could benefit from this architecture. Stepping back, I think that will continue to be the case. The immediate solution that jumps out in response to the problems that ColdSpring addresses could often be taken care of with the application.cfc (security), or by the RDMS (logging). Caching goes in the middle there somewhere, in certain situations, but even that for some situations, has solutions easily employed at different layers. So, part of the difficulty is beyond the abstraction, and in the realm of problems which we have already solved in one way or another. And while that may be so, as customer demands shift, we must at least be prepared to shift our strategies and solutions to problems.