An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Mach II: Some Advice

May 24, 2006 ·

So you're building a Mach II application and you're figuring out what code should go in your filters and what code should go in your listeners and you build it all out in a nice, modular fashion and it works and you're very pleased with yourself. And then you need to put a Flex front-end on your application. That means you need to expose your model as a set of remote methods. If you got your application design right, that'll be easy: just open up your model CFCs and change the access attributes and you'll be done, right?Well, a lot depends on how you built your Mach II application. If you built a service layer that is independent of the framework that orchestrates actions taken against the model and then you built one or more listeners that mostly just delegate to that service layer, you'll be in good shape. But I'll bet money you didn't do it that way... I'll bet you have core business logic in your filters and listeners. I'll bet you have decomposed listener operations into private methods within the listeners... that take MachII.framework.Event type arguments and therefore contain calls to arguments.event.getArg(). Why am I so certain? Because it's so easy to fall into that trap - because the alternative is, frankly, a bit tedious and involves quite a lot more typing. Another reason that I'm so certain you've fallen into this trap is that, despite my recommendations on listeners and models developed for our own applications, we've done it too. Yup, right now I'm analyzing a couple of applications that we built back in 2003/2004 and have hardly touched in about eighteen months - applications that we want to put Flex front-ends on - and I have to admit it's a bit painful. I'm going to have to retrofit remote facades onto these applications and either heavily refactor some of the filters and listeners so that they have a cleanly separated model, which will require completely re-testing every aspect of these happily working production applications, or simply duplicate enough listener code into my facade to achieve the functionality my Flex applications require. Don't think it won't happen to you! I guarantee that you'll find yourself putting a Flex front-end on a legacy Mach II application at some point and you'll wish you too had done a better job of separating your business model from your listeners! Oh, and don't think I'm just picking on Mach II - this is a trap Model-Glue developers will likely fall into as well I expect, although tempered by the later uptake of that framework and the more experience we all now have building better CFC-based applications (right?). Of course, if you're religiously using ColdSpring to manage your service layer, you probably don't have much business logic in your controllers / listeners. Another good reason for using ColdSpring! And, yes, this means that I'm laying the groundwork for some public-facing Flex 2 applications on in the not too distant future.

Tags: architecture · coldfusion · machii

10 responses

  • 1 Sami Hoda // May 24, 2006 at 10:20 PM

    Something I've always worried about, glad you brought it up. Would you be willing to provide some dumbed down examples of how your created this intermediary layer to interface with Flex? Im always interested in your code I suppose! :D
  • 2 Sean Corfield // May 24, 2006 at 10:32 PM

    Maybe I'll talk at MAX about how to convert legacy applications to Flex applications?

    Yeah, I'll definitely be blogging some of my findings and experiences about this. It'll be a while tho' and it'll be very circumspect until our new "stuff" is actually out there in production...
  • 3 Dante // May 24, 2006 at 10:36 PM

    I'd have lost that bet! Very timely post Sean. I've been struggling with the same thing myself recently. Only instead of the Flex front-end, a basic SOAP integration api to a Mach II app.
  • 4 Sean Corfield // May 24, 2006 at 11:04 PM

    Right, a web service front end will also show the same issues. And just to be clear, Flex, Flash and Web Services all rely on the model portion, the CFCs, and not Mach II (or Model-Glue) which is why separating the framework from the model is so important.

    Good luck on creating your Web Service front end - I hope you'll blog your experiences for others.
  • 5 Andrew Fedorchek // May 25, 2006 at 4:26 AM

    Our team would have lost the bet too. We converted to Mach-II 1.0 in the summer of 2004. As you say, much of the code written then has the business logic in the listeners. We've gotten better about it each year, and we've also spent time refactoring, in our case also for SOAP integration. We've looked carefully at ColdSpring and plan to convert to using that as well. However, we are being careful about the timing of when we adopt ColdSpring for a number of reasons, one of which is waiting for the 1.0.
  • 6 Matt Williams // May 25, 2006 at 5:59 AM

    Good advice Sean. Perhaps we should be advocating the idea that you should be able to test your model independent of a Framework. You can test either by just writing enough code to invoke methods on your model and cfdump any returned variables or use something like CFCUnit.
  • 7 Matt Woodward // May 25, 2006 at 7:08 AM

    This is exactly how MachBlog ( has been constructed--the listeners have as little logic in them as possible (already a bit of refactoring to do on some of them) and we have a service layer in place so it'll be easy to slap a different front-end or even framework on. Hopefully it will serve as a good example of these principles. My older code definitely suffers from what you describe here.
  • 8 Sean Corfield // May 25, 2006 at 9:16 AM

    Matt Williams, yes, if people get into the habit of testing code outside a framework then they will more naturally build a model that is independent of their framework.

    Matt Woodward, nice to see even hardcore Mach II developers stepping up and admitting to the same mistakes!

    I've been listening to a lot of Helms and Peters "Out Loud" lately (catching up) and they hammer this point home over and over again: the framework is just the glue, the model is the important part of the code (and the view is the important part of the application - because that's what the client sees). If we build our views as a prototype to get signoff with the clients and then write test cases and then write model code against those test cases and then glue things together with a framework, we'll be in better shape.
  • 9 Kurt Wiersma // May 26, 2006 at 2:00 PM

    I focus on making sure my listeners only do things that are http specific. That thinking seems to help me keep business logic out of my controllers/listeners and in my service cfc's.
  • 10 Kurt Wiersma // May 26, 2006 at 2:01 PM

    I have a good example of this three tiered structure on my sample/start application Appbooster. It available from my blog but I am not sure I can post the link here.