When to Use ColdSpring: one example

  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 ColdSpring Example Transaction  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.


5 Responses to When to Use ColdSpring: one example

  1. Peter Bell says:

    I honestly can’t think of any downside to using ColdSpring. Core requirements:
    1. You use CFC’s (without them CS is irrelevant)
    2. Your CFCs need to talk to each other (if you only have two CFCs and they don’t speak, an d you’ll never have any more, you don’t need CS).

    Once you hit those, use a DI framework like ColdSpring.

    Key benefits:
    – Easy creation of unit tests – you just pass the dependencies in manually so you can use mocks or stubs if appropriate.
    – Clearly documented dependencies so it’s easy to see architectural decisions in a single XML file (unless you use autowiring).
    – Handles dependency chains – if you have a bean that depends on other beans and so on, initializing them in the right order is a real pain. CS takes care of that for you automatically.

    Additional benefits: you get AOP and remote proxy bean creation for free. I haven’t seen a downside at all. As your OO apps get bigger, you’ll get more and more benefit from CS.

  2. howardscholz says:

    Well, I can speak from experience of a situation where ColdSpring can be a headache. I was on a contract where the “architect” had decided it would be using ColdSpring and ModelGlue. And he thought Duck Typing would be a good idea too, because it was “faster”. Great. The way things were set up for development, all of the cfc’s were cached, so to test a small change required re-iniializing the whole system. It made tracing and debugging more difficult as well. Mind you, there was more going on in the environment culturally, that made addressing any of these issues head on difficult. The “architect” was rarely available for questions, and would get defensive if anyone questioned “why” things were done in any particular way.
    Knowing that ColdSpring and ModelGlue were foisted upon the system, without any sort of understanding or thought behind it, kept me from being critical of the frameworks in particular. But it did show how any of these frameworks or tools can be misused and become an anathema to developers who were “doing just fine” before.

  3. Well, it sounds like you weren’t doing unit testing – that’s how to perform isolated testing of changes without having to reinitialize the entire website. But, yeah, it sounds more like cultural problems than a real problem with ColdSpring.

  4. howardscholz says:

    No, unit testing was not optimal. Despite all that went wrong, I learned a lot in that project about the importance of process, unit testing, project management and so on. I share to hopefully spare someone the lesson(s).

  5. Cool! Every project – no matter how bad – can be an opportunity for learning and improvement! :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: