There was a time in the push for a Robotlegs 1.0 that a nometa implementation existed. Robert Penner still uses it, if I’m not mistaken. It doesn’t have as much convenience as the regular meta-loving MVCS implementation, meaning it doesn’t inject a bunch of classes into the MVCS base classes. Is that bad? Not really. I find myself rarely using the injected classes anyway. At the time I pushed back on the nometa implementation and its inclusion in the core. I still think that is proper, because it would just tend to cloud the implementation and make it more difficult to document and support, both of these being key pillars in making Robotlegs a successful project that people will actually use. The concept of using as little metadata as possible in my applications is very appealing.
SwiftSuspenders beautifully supports constructor injection. This means that you don’t need to annotate any methods or the class with metadata for it to honor injection into the constructor. With the [Inject] tag, you are marking required dependencies. They aren’t optional. If there is no rule to supply the injection you will get a runtime error saying as such. So, given these non-optional dependencies, injecting them into the constructor makes a lot of sense. One drawback to this approach is that if you are injecting a lot of dependencies your constructor might get really big. In fact, the limit is 10 parameters. Guess what? If your class requires that many dependencies, it already smells bad. Clean it up and think single responsibility. For the love of Uncle Bob, keep it clean.
To illustrate this point I have refactored the Image Gallery example. It was my first example for Robotlegs almost a year ago. The original version resides in the Robotlegs Demo Bundle. In this refactoring I removed all occurrences of the [Inject] metadata tag. In addition, I removed all of the extensions of Robotlegs mvcs implementation sub-classes with the exception of Mediator. There are no Actor or Command subclasses. So what you end up with is a Command, Model, and Service tier that is completely meta and framework free. That rocks. It is just AS3 code doing its job. I love that.
Here’s a link to the source for this project on Github.
Tooling is very lacking for metadata in all of the IDEs currently available. The SourceMate plugin from ElementRiver is a nice addition to Flash Builder if you make use of metadata. It actually gives you code completion, which in and of itself is a huge improvement over… nothing. I hope to see more IDE support for metadata soon. It would really make it a lot easier to manage.
In my professional life, I use all of the Actionscript DI frameworks (Robotlegs, Swiz, and Parsley). They are all great, when used appropriately within a defined set of patterns and practices. I worry about the trend for increased use of metadata. I think the complexity overhead is large. Sure, you get it, but there is a responsibility to build systems that can be understood by a wide range of developers without weeks of remedial training on a complex metadata based DSL. The less complex we make our complex systems the better. They are easier to train for, document, and build.
The Do we really need THAT much metadata in AS3? Not with Robotlegs… by Joel Hooks, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 United States License.