"We aren't dealing with ordinary machines here. These are highly complicated pieces of equipment almost as complicated as living organisms. In some cases, they've been designed by other computers. We don't know exactly how they work." - Westworld (1973)
If there's one thing about humans, it's that we are incredibly good at making simple things complicated. A few examples come to mind. We can take simple activities and make them into highly competitive spectator sports (see: ping-pong, poker, rock-paper-scissors). Heck, Starbucks has made it a skill testing question to answer what size of coffee you want.
Inevitably, this same uncontrollable, instinctive human urge applies to software design.
Decisions, Decisions
As our Flex practice matures here at 4Point, the scale and complexity of the Flex-based projects we are developing are increasing. It's an exciting time. It's also a time for important decisions to be made.
Here are a few:
- What formal(ish?) development methodology should we adopt?
- Should we move to test-driven development?
- Would we benefit from setting up the infrastructure and process for managing continuous builds?
- What framework(s) should we use as the foundation of our Flex applications?
- What should be our preferred back-end technologies? Java? .net? Ruby?
That said, I was tasked to do some research into implementing a test-driven Flex development environment. I have looked at and tested some of the currently available unit-testing tools (FlexUnit, ASUnit, MockAS3, etc.) and have tried using Maven for continuous Flex build management. Given my background in test-driven Java, it has been quite an eye-opening experience (but that's for another post).
Enter Mate
Until now, different frameworks have been considered for use in upcoming projects. You know, the usual suspects: Caringorm, PureMVC, etc. However, since I watched a video presentation of Mate, my professional curiosity has been piqued. It seems to me to be an elegant answer to the challenges of formally structuring a Flex application. By using dependency injection and implicit invocation, code and components are decoupled and lend themselves to unit-testing. All-in-all, my sensibilities as a software designer make Mate a very attractive option.
I've read various reviews of Mate, principally Tony Hillerson's framework throwdown at InsideRIA. I've watched various videos by Laura Arguello from ASFusion. I've talked to other developers. One big question still remains.
The Big Question (tm)
As we debate the benefits of the different frameworks here at 4Point, some concerns have been raised by reports from some quarters that Mate may not be well suited for larger systems. Supposedly, Mate's use of "bubbling up" events and numerous open listeners (that may or may not be used) leads to major memory issues in larger-scale systems.
Does anyone out there have any experience building complex/large applications using Mate? If so, can you please answer this question:
"How well does Mate scale?"
Even if you're using a competing framework, I'd love to hear your 2 cents on Flex scalability best practices. Please post a comment or drop me a line. Any and all input is greatly appreciated.
Thank you.
Now back to perfecting my rock-paper-scissors technique.
Hi Taylor,
I just finished working on a mid-sized (2400 files) CRM application, for a large company; that was written using the Mate framework. I have to say that the application has the cleanest and most intuitive code base that I've ever seen.
As a long-time Cairngorm user, I was skeptical of Mate at first. However, I now find Mate to be a far superior choice for MVC. In addition to dependency injection, managers and event maps, if you also implement the use of presentation models, you get a very loose coupled application, that is easily unit testable. As a side benefit, you actually create less byte code; since you're not forced into using a lot of boiler-plate code that some other frameworks advocate. All in all, I have to give Mate a big thumbs-up.
Concerning scalability, I haven't seen any significant memory issues. Of course, as any application gets larger, you're going to experience scaling issues; regardless of which framework is used. At that point, you just need to start considering breaking the application into modules.
Anyway, that's .02.
Cheers,
-TH
TH,
Thanks so much for your input. I am encouraged to hear that Mate has helped you accomplish exactly what we aim to do: provide a framework with minimal overhead that guides/helps developers to follow best practices. That Mate has scaled well for your project defuses some of the concerns we've had with choosing it over Cairngorm or PureMVC.
From my experience in a multiple-developer projects, in order to "homogenize" code written by varied developers, you have to set -- and more importantly, have people follow -- certain standard coding practices and common design goals. Since you can't be lurking over people's shoulders all of the time, if nothing else, a framework can help a lot in keeping the code consistent.
I know that my own coding habits benefited quite a lot by working on a test-driven Java project using the Spring IoC framework. Thanks to that experience, even though I'm not writing test-driven code at the moment, I have become much more disciplined in organizing my classes and methods to be decoupled, readable and (in the end) testable.
Taylor
Is this real?
sounds like a marketing exercise. :)
Ha ha.
Thanks for coming by, George. I'm not sure if you're referring to my original post or Tim Hoff's comment... but if it's the post you're referring to, well I'm no marketing guy, just a software designer who enjoys writing (or is it the other way around?)
As an update, I'm currently in the middle of our first Mate project here at 4Point. So far, despite the expected growing pains with learning any new framework, all is well. It's still too early to evaluate how Mate will serve us in the end, but I was able to put together the basic building blocks fairly quickly to hand off as examples to the more junior Flex developers. How the performance will play out is yet to be seen, since we have a long ways to go still.
One thing's for sure, the code is very well organized. The app is broken down into modules with their own local even maps. Developers generally work within the structure of one module at a time, rarely touching any global constructs (e.g. the global event map). That makes for less conflicts/merge issues. One challenge is getting developers of varying experience levels to follow a consistent code style/structure... but that has nothing to do with Mate, of course.
I'll write up a post-mortem (positive or otherwise) once the project is complete.