Introduction
Recently there seems to be a trend towards using metadata in actionscript to do everything. In particular some frameworks and libraries use metadata for internal application wiring. You just need to look at Parsley and the Cairngorm Navigation Library to see this.
There is nothing wrong with metadata as such, but because of the weak way in which it is interpreted and controlled by the compiler and runtime player I feel it is a very inappropriate (dare I even say, dangerous) choice of technology to be used for this. I would actually go so far as to say it’s a step backwards. Allow me to explain.
Actionscript Has Improved
Since the introduction of Actionscript in September 2000, it has evolved through several version: 1 (AS1), 2 (AS2), and 3 (AS3). Each version has improved on the maturity of the language. So much so that, combined with a large set of supporting libraries and technologies (Flex, FlexUnit, FlexPMD etc…), we are now at the point where Actionscript 3 can be used to develop enterprise levels applications using Flash as the underlying technology.
I do not believe this would have been possible without the introduction of two core features as the language has evolved.
1) Type Checking
In AS1 and AS2 you can write the following code
function add(a,b) { return a+b; } trace(add(3,4)); trace(add("3",4)); trace(add(null,4)); trace(add(createTextField("Hello", 0, 0, 0, 100, 100),4)); |
This code will compile and run without any errors. The output is
7 34 NaN NaN
We can see that any object what so ever is being added to any other, even though in the fourth example a textField is being added to a number. I once spent days trying to fix a bug where a string was being passed into a method where I was expecting a number – very very hard to find.
This is all that you can do in AS1 as it has no concept of type checking.
In AS2 and AS3 you can enhance the above example by adding type checking and specifying what types the passed in parameters should be.
function add(a:Number,b:Number) { return a+b; } trace(add(3,4)); trace(add("3",4)); trace(add(null,4)); trace(add(createTextField("Hello", 0, 0, 0, 100, 100),4)); |
Now, because we have specified that numbers must be passed in, this code will not even compile and produces the following error message when set to compile as AS2
Scene=Scene 1, layer=Layer 1, frame=1, Line 7 Type mismatch.
This compile time type checking is a good thing as it improves the reliability and predictability of our code, even before we are able to run it.
2) Run Time Error Checking
In AS2 you can write the following code
function addLengths(a:Array,b:Array) { return a.length+b.length; } trace(addLengths([1,2],[2])); trace(addLengths(null,[2])); |
This code will compile and run without error producing the following output
3 NaN
The second result isn’t really what you would expect as you can not tell if an operation succeeded or not – no error is thrown when you try to find out the length of a null array.
AS3 introduced a fantastic new feature – run time error checking. In this case if you run the code above as AS3 in a debug version of the player you will see the following error message pop up
TypeError: Error #1009: Cannot access a property or method of a null object reference. at AS1and2pt2_fla::MainTimeline/addLengths() at AS1and2pt2_fla::MainTimeline/frame1()
This is fantastic as we can now see that somehow a null value got through to our addLengths method. This happens at run time and is no longer hidden from us by the flash player.
I was under the impression that most developers were very happy with these additions to the language, and in my opinion these two enhancements have helped massively to move Actionscript from a ‘toy’ language to something that could be used for much larger applications.
So…
Enter Metadata
Metadata was introduced with the mxmlc compiler when flex 2 was released. It is a mechanism for adding extra information to a class similar in style, but very different in execution, to annotations in Java.
A lot of standard metadata is defined by Adobe and the flex compiler is able to interpret some of this at compile time. For example the [Bindable] metadata tags causes the generation of binding source code in your class before it is compiled. This is not a bad thing, as this metadata is understood at a compiler level.
Java also has the concept of metadata. In Java it is a very powerful mechanism and you can also add you own custom metadata tags. This ability has been responsible for many fantastic technologies that are now almost completely standard parts of java: Spring, Hibernate etc.. Metadata is used and trusted in such enterprise level frameworks because java custom metadata is is dealt with via a special mechanism called the Pluggable Annotation Processing API. This API means that custom metadata processing becomes part of the compile process and that metadata can be checked for sanity and validity before the application is even run.
It is also possible to add you own custom metadata in actionscript, for whatever purpose you require. Unfortunately in actionscript custom metadata is totally ignored by the compiler and the runtime. You can get the metadata to be compiled into your swc/swf class files but no checking of the metadata or its validity is performed by either the compiler or the flash player. The only way to check the metadata is at runtime and requires using the expensive ‘describeType’ call along with your own runtime code to check it.
So, to reiterate, custom metadata is neither compile checked, nor runtime checked. Even though most people would agree that type checking and run time error handling are great improvements to actionscript, there is now a mechanism for completely throwing that away – custom metadata!
This would not be an issue if custom metadata was only used as a descriptive helper layer, but unfortunately there seems to be a tendency towards relying on it for very inappropriate purposes.
I suppose I had better show an example.
Parsley Command Handling
Parsley is a framework that relies almost completely on allows you to use metadata for almost everything. At the last count it had over 40 custom metadata tags, most of which are to do with how an application wires itself up. In my opinion this mechanism completely circumvents the compiler and the runtime and creates very very fragile application.
Lets look at the login command from the Parsley documentation
public class LoginCommand { [Inject] public var service:RemoteObject; [Command(selector="save")] public function saveUser(event:UserEvent):AsyncToken { return service.saveUser(event.user); } [CommandResult(selector="save")] public function handleResult(user:User, event:UserEvent):void { //Handle result here } [CommandError(selector="save")] public function handleError(fault:FaultEvent, trigger:UserEvent):void { //Handle error here } } |
So what’s wrong with this picture? I can’t state this strongly enough – ALL of the information about how this class functions is stored in the metadata and not in the implementation of the class itself. The methods that get called when the command is executed, finishes successfully or fails are controlled by metadata. So if I misspell any of the method names ‘saveUser’, ‘handleResult’ or ‘handleError’ the code will run as expected. They might as well be called ‘splurge’, ‘splat’ and ‘bang’ for all the control that the method names have over what gets executed.
Conversely, and rather perversely, if I misspell any of the following strings: ‘save’, ‘CommandError’, ‘CommandResult’, ‘Command’, ‘selector’ then the code will still compile and run without any reported errors, even though the application will probably no longer function correctly.
So the code has gone from being strongly typed to Stringly Typed.
If i write the same class using standard actionscript all the meaning of the class becomes implicit in the code and not the metadata
public class LoginCommand implements IResponder { [Inject] public var service:RemoteObject; public function execute(event:UserEvent):void { service.saveUser(event.user).addResponder(this); } public function result(event:ResultEvent):void { //Handle result here } public function fault(fault:FaultEvent):void { //Handle error here } } |
The code is far cleaner and if I change any of the method names, the code will not even compile. Surely this class is much better than the metadata controlled one. Surely using metadata for the wiring in this case was a real step backwards for the robustness of our code, and yet this seems to be a mechanism that is being promoted for wiring things together.
Conclusion of Pt 1
This article is now a little too long and so In Part 2 I explain why metadata used in this manner in an enterprise environment has even more issues. I will also show where the Cairngorm navigation library exhibits the same weakness.
I believe that unless the next actionscript compiler has a similar processor plugin architecture to java for metadata, then any usage of metadata for internal application wiring will always be far more fragile, prone to error and will fail far later. All bad things.
Pingback: Tweets that mention The Problem With Metadata – Part 1 | DZ-015 -- Topsy.com
Nice. For added impact I’d remove the [Inject] metadata from your final example, and specify the service as a constructor argument instead.
I have similar feelings about AS3 metadata. Some rough thoughts posted here: http://pbking.com/blog/?p=209&cpage=1#comment-20461 – the gist of it is that I’m OK with metadata tags that are somewhat “standardized”. With that in mind I started this document:
https://github.com/darscan/AS3-DI-Metadata
Parsley as other IoC frameworks help developers to keep more framework APIs out of application code. This works very well when objects are configured completely externally with i.e. XML as frameworks such as Spring AS (Prana), Parsley 1 have done for many years in Flash/Flex. Metadata is another optional configuration option that applies some configuration inline which can improve showing the indent of the code (I believe Swiz was the first IoC framework that applied this option to Flex). You’re right that using metadata comes with a little cost of type safely and I’d agree in lobbying towards the Flash player team to help us here more. Did you already file or vote for an enhancement request on it? In the meantime, we can either choose another configuration option or/and try to keep our custom metadata definition APIs relativley simple.
You might want to suggest another additional, more type-safe configuration option based on interfaces. This would compete with the first goal I mentioned above and depending on the use case might also be quite cumbersome but as an option why not? I wouldn’t be surprised if you could write one as an extension to Parsley. Would you like to try?
Maybe suggest it to the Parsley forum first? Up to you.
Regarding your comment: “Parsley is a framework that relies almost completely on metadata for everything. ”
I don’t think this is a correct assessment. Metadata is just one way in to describe an object in Parsley. AS, MXML, XML are others to achieve external configuration. Regarding your example of commands, you can go a step further than external configuration and follow convention over configuration using DynamicCommand. Check out http://www.spicefactory.org/parsley/docs/2.3/manual/
So, I’m looking forward to hear your take on the navigation lib, but please keep my comments in mind as same applies to the Nav lib. As IoC framework extension it would support alternative configuration options if the underlying IoC framework (Swiz, SpringAS, Parsley) supports it. You don’t have to use metadata if you believe the loss in type safety is too much of a concern.
Regarding errors that can only be detected at runtime: IoC frameworks should try to fail fast with descriptive errors and in recent versions Parsley usually does that AFAIK, but if it doesn’t in all cases, probably best to file a bug/ECR.
Shaun,
I deliberately left the [Inject] tag in there as I am not completely against Metadata – only really worried about it when it is used for wiring up things that ought to be left to the compiler and linker.
Your link was excellent – funny how you’ve never pointed me at it before
I shall ponder more
Alex,
As Shaun points out quite rightly in his link, you ARE tying yourself to a framework –
“So, when you depend on complex, un-standardised metadata you are binding yourself to a particular version of a particular metadata parser, but you can’t specify which version that is. What if something else parses that class and interprets the metadata differently?”
This to me is an excellent point.
WRT interfaces – I did show an example, I used IResponder to deal with an asynchronous response – standard, well understood and robust.
WRT Parsley – Have you ever tried to use it without using metadata?
You also point out that Parsley now has the dynamic command. Yes it does, but my example is from the documentation, and I believe Parsley now has far too many problematic ways of doing the same thing. If it only had DynamicCommand (which was the only kind of command I used when using parsley) and got rid of all the rest then I would consider that an improvement.
First, I’d really like to dispel a myth here which is your statement that: “Parsley is a framework that relies almost completely on metadata for everything”. This is clearly and evidently wrong, like Alex already hinted at! The truth is, it is the far opposite: Not a single feature of the framework requires metadata in any way. It has a core that offers all the features around Context creation, object lifecycle management, messaging, commands, etc. based on an API (a set of interfaces along with a set of default implementations that you can swap out). Nothing in this core implementation knows anything about any of the available configuration options (metadata, MXML, XML, a programmatic DSL). All these configuration options exist as a thin and optional layer on top of the core implementation and metadata is simply just one of them. So you pick the mechanism that suits your needs best and ignore the rest. It is probably more a problem with the Parsley documentation that kind of helps keeping the myth alive as it favors metadata over other options for many of the examples. But this in turn is caused by the fact that most Parsley users seem to prefer metadata for many use cases. That being said: if you are member of the No Metadata Fundamentalist Party, then go ahead and use Parsley without any of its metadata tags. You still get the full power of all its features with a comparable ease of use. In chapter 6 (Messaging) in the manual for example, you’ll see simple MXML and XML examples for most of the metadata tags shown.
The example you picked is also not the best choice. I think this is not taken from the documentation unmodified and thus misleading. I think you merged several snippets taken from the messaging chapter into one class. But this is not how these metadata tags are getting used. You normally use the [CommandResult] metadata for a *decoupled* result handler, meaning another class, not the command itself, listens to the result. No matter if you like that feature or not, an IResponder would not help much in such a case, as you’d still need to specify *which* result you are interested in. You cannot call addResponder(this) in this case, as you are decoupled from the executor. If you handle everything in one place, yes, then simply using an IResponder like in your example *is* a perfectly valid choice. I just think it does not really help supporting your argument.
Now about metadata. There is certainly one thing I do agree with: the way metadata works in AS3 today is indeed very poor compared to annotations in Java. No compiler checks. No namespaces to shield tags from different frameworks from each other. It would indeed be a good thing if we’d jointly push Adobe to consider robust, type-safe metadata in the next major language revision. I wrote a paper about one year ago that I also passed to Adobe: http://www.spicefactory.org/parsley/docs/Issues-Flash-Player.pdf. It does not consider additions like the new describeTypeJSON function, but most of it still applies. The proposal for type-safe metadata is in section 6.1. When you look at the new Dependency Injection standard in Java EE 6 for example (CDI/JSR-299), you’ll notice that they achieve a good deal of type-safe configuration within class definitions through the use of three Java language features: type-safe annotations, generics and enums. Interestingly none of these features are available in AS3. So as IOC container creators in the Flex and Flash world we are currently forced to compromise and improvise due to several deficiencies of the AS3 language.
But the thing I disagree with is the conclusion to avoid metadata at all cost until these things are fixed. I think that the price in many cases is too high. If you wire everything programmatically, you are often either coding against a framework API or tightly coupling objects of your application which should better not depend on each other. And I disagree that metadata creates the same level of dependency on the framework like coding against its API. I’d say it’s more like a “weak dependency”. It can be completely ignored, you can use the class in a Unit Test without firing up the container (and without even having the framework SWC in the classpath). And this is not an exotic scenario.
So I think that attempts to avoid metadata at all cost often lead from bad to worse. This is particularly true for Parsley which adds some degree of type-safety *on top* of the use of metadata. Consider this example:
[MessageHandler]
public function handleMessage (msg:LoginMessage) : void
This declares an interest in any LoginMessage (including sub-types). The type is determined through reflection and when this method gets invoked you can rely on the type being the right one. Now what are the alternatives? Using an interface with a method like this:
function handleMessage (msg:Object) : void
Well, first welcome in casting hell, and if you are interested in more than one event in the same class, welcome in switch/case hell. Or using classic Flash Events like this:
someObject.addEventListener(LoginEvent.LOGIN, handleLogin);
This is highly problematic in multiple ways: It does not match by type, but instead by that string based constant. And also of course no compiler check that the signature of that handleLogin method is even remotely suitable to act as an event listener. Finally it couples the source and target of that event, something an IOC container is supposed to help you avoid.
Finally, as I already said, Parsley allows you to avoid metadata and use something like MXML:
The advantage over metadata here is that the compiler detects typos in the tag or attribute name. But the method name “handleMessage” is now a string which will be evaluated at runtime, so it’s not ideal either. In fact, the major advantage of this declaration is primarily that you can have different configurations for the same class, which is not possible with metadata. So I usually recommend this approach just for these types of use cases.
So my personal opinion is that while metadata is indeed quite problematic in AS3 and I even strongly dislike using it in some scenarios myself, the position to strictly advocate against its use appears to be quite unbalanced to me and ignores many of the problems associated with alternative architectural approaches. For me, there is no black and white in that respect and even with the current problems, metadata is often a good choice for decoupling. Like everything it can be overused, and then it does cause problems of course. But that is generally the case when using IOC containers: you need to use them judiciously. When you exaggerate with decoupling, no matter if with metadata or without, your app becomes fragile, fragmented and hard to understand and maintain.
Unfortunately the MXML example got swallowed. Trying again here:
<Object type=”{SomeClass}”>
<MessageHandler method=”handleMessage”/>
</Object>
I’m with you on this Conrad.
Short justification: There is no limit to the simplicity of things I can screw up.
I love the compiler for being able to tell me exactly where I’ve made a dumb error. I’ll go to some lengths to limit the number of dumb errors I can make without getting a CTE or RTE to give me a clue that they’re there.
The robotlegs tags are simple. To be honest I only use [Inject]. I still occasionally manage to screw up by doing this [Inject]; – that semi-colon nervous twitch thing I’ve developed over the years. But that’s rare.
I did some metrics that indicate that I spend more than 95% of my time not writing code. Cognition and error finding are always the bottlenecks. Robotlegs is simple enough to not get in my way cognitively, and doesn’t leave me much room for errors that slip past the compiler.
Maybe I’m just more stupid than average – I’m the kind of person who can write a clever legal letter and then forget to post it. Having given up on the idea that I’ll ever change, I like to make my work processes robust to my ‘duh’ moments.
The post is good but again we go to the point that all enterprise developers know – that flex compiler sucks. The language and vm goes forward but the compiler stands where it was at least 5 years ago and not much has changed. Bah moreover there is now more and more complexity and compilation time in it and it’s even not scaling. I’m still waiting for the new improved compiler from Adobe cause this one written in Allaire/Macromedia is far beyond the standards as compiler should be now.
We are writing about enterprise but tell me why my enterprise project with all the tricks done is still compiling at least 1 minute ?
@Alex @Jens don’t get me wrong but you wrote I don’t have to write the metadata to work with Parsley but tell me why should I ? Why I need to resign from metadata that helps me clear my code? Why should I always and always step backward got dammit ? Cause the language / vm sucks ? Why I need to do the performance tricks myself ? Why one person can write better compiler, or language extensions then whole company and it’s resources (HaXe Nicolas Cannasse). Why one person can write better optimizer then whole company (Apparat Joa Ebert) That’s sick since writing compiler now is even not much complex as it seems to be having all that Visitor Combinator design patterns, examples etc.
I know only one answer – cause the compiler have not selling / marketing price. Am I wrong ?
There is at least an issue logged in the Flex SDK issue tracker related to this: https://bugs.adobe.com/jira/browse/SDK-26041
Thanks everybody for interesting comments and links. I really appreciate you all spending the time to put forward your thoughts. I’m going to have a good think before I respond, and I also have to get on with part 2 – which will definitely be influenced by what people are saying.
First, to say Parsley is dependent on metadata, is incorrect, and as Jens pointed out you can choose not to use it I believe this is true to most the popular frameworks(Swiz, Robotlegs, Flex).
Second is this a discussion about not understanding what the metadata is doing or is it about making metadata a first class citizen? Because many times when I have been involved with this discussion the topic first is “well I don’t have type checking or error handling” then it seems to evolve to “well it seems magical and I want to know what it is doing”.
If it is the first scenario then you have one option I currently know of Sourcemate, which among other things, allows you to create compile time type checking rules for metadata.
Now if you are part of the second scenario well then feel free to write you own binding, injection framework, or all the neat things that Parsley does for you. But maybe, once that “magic is gone” or you are sick of typing the same change watchers for the umpteenth time, you realize that [Bindable] or [Inject] will speed up your time.
But I do believe once metadata is a first class citizen like it is in Java these discussions will be much less common because metadata is not going anywhere.
Josh,
I have to respond to one point in your comment quickly.
1) Neither Sourcemate nor even flashbuilder Burrito create compile checking of metadata, they only give you visual clues in the IDE as to whether or not your metadata matches some criteria specified in an external XML file. When your build server comes along and compiles your code it will still not (and still can not) check you metadata for consistency, and the build server build is the only build that matters.
2) Just because a system ‘speeds up your time’ does not necessarily mean that it is good. In my opinion good clean code (even if it is slightly more verbose) is better than something that loses compile and run time checking. On top of this metadata does not always make for less typing – if you look at my second command example that does not use metadata it is actually shorter than the example that does.
3) Just because a system ‘speeds up your time’ when you write it does not mean that ‘it speeds up your time’ when you have to fix it because it is broken. Have you ever had to track down broken metadata?
3) Bindable is already a ‘first class’ citizen in the flex compiler and so is not really included in this discussion, which is about custom metadata.
Just in case my answer was not clear enough (you keep referring to your sample command, so I assume you did not fully get my point).
Your second example of your command is better than the first one because in the first example you are simply using Parsley in the wrong way. This is not how it is documented to be used. Yes, you can code it like this and it will work, but it is pointless. Every framework gives you some rope to hang yourself with, but you should not use examples like this to demonstrate that you can do better without.
So again, I think your sample does not proof your point at all. When metadata is getting used in an IOC container it is primarily used for some sort of decoupling. When you do everything in one place you don’t need to decouple, and thus don’t need the help of an IOC container, neither with nor without metadata. When using the [CommandResult] tag, you use it when some other object (*not* the object executing the command) is interested in the result, and then you cannot simply redesign in the way you did for the second sample. This is why I think your example is just misleading.
SourceMate solves part of the problem:
http://www.elementriver.com/sourcemate/features/metadata-tag-validation
http://www.elementriver.com/sourcemate/features/metadata-tag-content-assist
I can’t imagine using a framework that depends on metadata and not using SourceMate’s metadata features (but of course I’m biased).
Conrad,
1) I completely agree I should have clarified myself when mentioning Sourcemate and true your build is the only thing that matters.
2) True to Uncle Bob again I agree that less code does not make it clean code. But as for “speeding up time” yes it may not in all cases, but as a generalization it does for me when used in conjunction with unit tests( or I just wouldn’t use it).
3) Again the speeding up time is ,I think, a pretty accurate generalization when using metadata with the correct framework. And yes it is a pita to track down misspelled metadata for example.
3) Just to correct you [Bindalbe] or [Event] is not a first class actionscript citizen. You do not get either CTE or RTE .
Again I will still say that making metadata first class will alleviate most of these issues I haven’t heard much on the Java side with annotations being a problem.
Hi Jens,
I didn’t mean to upset you in any way, and my post is not meant to be an attack on Parsley, although I do personally think it relies too much on metadata. I will edit my post to not indicate that in Parsley you don’t always have to use metadata, however the parsley documentation for Parsley does promote the usage of metadata extensively (just look at section 1.1).
So my Parsley example: I have seen Parsley used in that way many times now, and therefore I thought that was quite a common usage pattern. However, even if you split the handlers into different classes you still have the same issues with the metadata being a very weak kind of wiring.
WRT Unit testing: This is one of my other big issues with metadata, it is not as easy to safely test code that uses metadata as you seem to imply. Please wait for part 2 to see my points.
WRT coupling to frameworks: I personally believe that if you are going to use a framework then it should be sparingly and deep in the heart of your application. You should code in a way that shields you from the particular framework you are using, but I do not think you should be scared of ‘coupling’ to it – Otherwise why did you choose it in the first place?
Otherwise I tend to agree with a lot of what you say.
Hey Conrad,
sorry, I’m not upset. I’m not a native speaker, so probably some of my phrasing does sound more dramatic than intended.
It’s good to know that you have seen examples like in your post. This means I have to work on the documentation.
Your 1st version of the command is indeed far from being elegant.
Regarding documentation I agree, it is not as balanced as it could be. I’ve put it onto my todo list to make it clearer that metadata is always optional (but still recommended from my side for many use cases).
Regarding metadata being weak wiring: yes, but that is what you want when you decouple. Decoupling always means that you add a level of indirection and that not everything can be caught by the compiler. Leaving some wiring to the container means you are up to some runtime surprises if you do it wrong. This is even true for simple event handlers like I’ve shown.
I’d be interested to see how you’d prefer to wire a distant result handler. Distant in a sense that it is in a different architectural layer or in a different functional area of the application. Because only then you would want decoupling and use something like metadata. If the two pieces are “close” to each other anyway, then of course you would not use metadata or any of the decoupling features that IOC offers to you, but instead let them talk directly with each other, ignore the framework’s features and simply apply sound object-oriented principles.
I admit that I’ve seen bad coding in Parsley applications myself. But the major design flaw was often that there was too much decoupling. When for example one object sends a Parsley-managed message to another object although it also directly talks to that other object’s API in other places, then there is something fishy. That’s pointless. Bad Parsley apps I’ve seen had more these types of problems. These classes also tend to have too much metadata then, but that wasn’t the root cause of the problem, but instead merely one of its symptoms.
“I’d be interested to see how you’d prefer to wire a distant result handler. Distant in a sense that it is in a different architectural layer or in a different functional area of the application.”
Personally I would try to avoid it due to it making the application flow complex to follow and I don’t think I’ve ever came across a need. I would simply update a model on a result or a fault. If something else in the application is interested, it would be watching the model via an Event or Signal.
If I then want to find out what’s using the property thats updated, I can go an stick an extra character on the end of the property name in the model, save and I’ll get errors everywhere its being used.
So you are tightly coupling your components. If you are working on a smaller app that might be fine. But in a big, modular app this would exactly mean what I described with trading the bad for the worse. I’m talking about apps with 50+ developers for example, a scenario where Parsley is often used in.
If you don’t believe in the value proposition an IOC container gives you around decoupling or you don’t need it due to simpler requirements then you should avoid using such a framework and probably stick with classic MVC microarchitectures. But you should not expect that an IOC container avoids features and patterns which are actually needed when true decoupling is desirable.
Indeed, the weak wiring is the whole point with an IOC container. Consider Spring in Java – Using the xml config is as weak a wiring that you can get. Admittedly you’re able to configure Spring using annotations and dsl config as well, but these two approaches gets a lot of criticism in the java community for tightly coupling the application to the ioc container.
It appears to me that the lack of compile time checking for annotations, although annoying and brittle at times, also has some benefits, in allowing a completely implementation independent configuration api. This is indeed a far leap from previously popular flex MVC frameworks, such as PureMVC and Cairngorm 2, where the coupling to the framework was considerable.
And as Jens has pointed out repeatedly, if you don’t like metadata you don’t have to use it.
E:)
Espen,
by weak I mean fragile, prone to error and likely to break. This is very different to decoupled.
WRT Metadata – It is not that i don’t like metadata, it is that I feel we are trying to run before the compiler can walk.
Hi Jensa
I think you misunderstood my response. I’m not suggesting the tight coupling of anything. I would use IOC to inject the model mapped to an interface into both the command and any component that needed to know about the result or fault, I just wouldn’t want all sorts of parts of my application to handle the result/fault, making the handlers difficult to locate and over complicating the architecture.
The bigger the team, the more important this is. If you working on a small project , and there is few devs working on it, then maybe its ok to handle this all over the place and obsfucate your architecture. If there’s a large team each member needs to be able to track down this stuff quickly and efficiently.
Injecting the model in some cases is certainly fine, but I don’t understand why you generalize it that way. Does it mean you never use messaging? Injecting and using interfaces is one form of decoupling, but messaging is a different form which is even stronger (you only couple to one simple message type, not to the entire API of the interface and are more resilient to change – which is desirable in *some* use cases).
I have the feeling that some things in this discussion got over-simplified and over-generalized. I still fail to understand the problem of having metadata on a message handler for a message coming from a distant part of the application. (And the CommandResult we discussed here is just a short-cut for a custom message that the command could otherwise send after completion, thus a completely optional pattern).
Yes I avoid messaging. Decoupling has its place, but isn’t the holy grail, it does have its drawbacks and messaging creates a spiders web of communication throughout the app.
“I still fail to understand the problem of having metadata on a message handler for a message coming from a distant part of the application. ”
I don’t think anyone said that this is a problem. You asked how people would achieve it, and I merely explained that I try to avoid it. That said if you have an explicit user case where that was the only, or much better solution I’m all ears. Just haven’t ever required it.
I don’t have such a strict preference for patterns and think that messaging often avoids unnecessary plumbing. The spiders web sounds more like a misuse of messaging. So sometimes I do exactly what you described, but sometimes I really prefer to use a message.
Injection is often fine, but like I said, you couple to a full API then. Often all you need is a some sort of simple signal, particularly in a large app where one module reacts to some state change or action in another module that is not closely related.
Another issue with injection and state changes is that it’s easy to bind to an injected model in the view, but if you need to do something in a PM, you often need to add (and remove) listeners to the injected model (or I even often see ChangeWatchers in PMs…). So in some cases not using messaging simply creates more plumbing and thus more potential causes for errors.
Parsley offers three base techniques for decoupling: Dependency Injection, Messaging and Decoupled Bindings (the Publish/Subscribe mechanism). Other IOC containers offer similar things. I see it as a toolbox and always pick what solves the problem in the cleanest and most efficient way. I would not want to reduce myself to just one major pattern applied to all aspects of a large app.
“I don’t think anyone said that this is a problem”
Sorry, I was a bit unclear. I was starting to get confused as to how our current discussion relates to the intent of the blog post that kind of considers the use of metadata for application wiring evil on a general level. We are now discussing what type of pattern we’d apply in what situation, but not how to configure it. My question “how would you do that” was more focusing on “how would you configure it”.
Its an interesting discussion, one of the things I am feeling more and more, is that we are getting away from clean code in many instances. Don’t get me wrong I love DI as a solution to many of the issues surrounding isolation and testing of classes, and I understand the large team needs that Cairngorm 3 and Parsley are designed to address. I think my disquiet in this area is nearly always one of maintainability and clarity after the framework superstars depart. If I pick up an area of the codebase which I am not familiar with, or even far more likely, return to something I wrote 6 months ago, (thinking “Which idiot wrote this? O’h actually I did!”). What I want in these circumstances is a clear transparent path through the code. External configuration abstracts us away from the code, and you lose to some degree the immediacy and “hands on” feedback that the compiler gives.
I am not expressing this very well, but I have many examples where people use a technology just cause it look good on their CV, piling in complexity for its own sake.
In many smaller apps 300 – 500 classes you could probably get away with Dependancy Injection alone (say SwiftSuspenders ) providing you thought the structure out an followed Cairngorm 3 principles of separating the vertical and horizontal concerns within the code.
Do we still need to be mindful of the size of the finished app? Keep the framework classes we import to minimum? How about “Just enough code”? Just enough code to get the job done.
I personally rather like the Robotlegs idea of a context, and doing all the application mapping there. But that does not mean that I have to use the full MVCS framework, if I have to roll my own for some reason. I really like ASSignal over “magic strings” but thats another post ;0)
Pingback: The problem with metadata, reposted… « journeysinflexland
Everyone is entitled to their opinion, and those opinions amongst other forces end up guiding our architectural decisions on projects.
I have worked on projects that have used flex metadata to great effect.
I have worked on projects that haven’t.
I have worked on projects where they didn’t use metadata and they sucked.
Lots of good discussion at the top of this thread, but now it just looks like postulating. Right tools for right job, plus personal preference. A lot of this discussion and article looks like FUD, sensationalism and reactionism : None of which lead us to better engineered systems.
The problem with custom metadata really doesn’t have to do with compile-time type checking or run-time type checking. It has to do with performance hits caused by all those describeType() calls. Sure, caching the derived descriptors helps mitigate secondary calls on most of the metadata based IOC and Event mediation frameworks, but the first time an application encounters a class using runtime metadata you still have to make that expensive top-level call.
Secondly, the metadata the frameworks use is unnecessary to achieve their intended results: Inversion of Control can be implemented by using interfaces. Loose component coupling can be achieved by following most of the Gang of Four’s original Design Patterns. Dependency injection is implementable by avoiding passing arguments to the constructor of a class, declaring a public setter for an encapsulated property, and calling that method after the class is initialized. Event mediation via metadata can be avoided by registering a class with a central event dispatcher+mediator pair at runtime, but even that shouldn’t really be necessary as the behaviors of an object that are externally controllable should be public methods anyway and thus part of the object’s callable interface. Any delegate class or client should be able to call that method. Individual event handlers really only belong in delegates or mediators instantiated by domain specific controllers. If you can’t roll your own of those what business do you have writing an application anyway (perhaps reworded as: if you can’t roll your own control flow logic you can’t make an application’s business logic work and thus cannot write a working application, so how is using a third party generic mediator/controller class going to help)?
I think custom metadata has its place, and that place is during authoring and producing parametertized boilerplate (which is what the metadata reliant frameworks like Parsley and Swiz use it for at runtime, anyway) using the code model to extend Flash Builder with custom plugins. Yes, I realize that that precludes using it for runtime purposes or for using it in non-Flash Builder based build environments. But unless we can extend the a/comp/mxml/c compiler, we shouldn’t be forcing costly describeType() down users’ (developer’s) throats.
Another point many have made is that the metadata-based IOC frameworks make users’ development productivity improve and code-reusability improve. You can do the same thing without metadata. Define an IInjectable and IMediatable set of interfaces that do the same thing the metadata frameworks do with the metadata tags and use them in the same way you would the metadata. You will achieve your loose coupling and code productivity.
The final point many have made here is that using the metadata keeps the framework APIs out of an application and its libraries. That is completely incorrect. The use of custom metadata explicitly binds a given project to a given framework API. It imposes certain interfaces upon your classes. That’s ok, and is to be expected, given that the definition of a “framework” is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user (developer) code, thus providing specific functionality. You aren’t keeping the framework out of the library/application code by using a metadata framework.
In all the metadata frameworks, I have yet to see something that would be impossible to achieve with OOP best practices, DPs and literal code, which is logical because the metadata tags are stand-ins for literal code classes.
The metadata framework designers understand this, as most of the frameworks are internally well-designed and well-written, and compact OOP best practices and DPs into bite-sized, and useful flexible libraries. I just want to use their knowledge and code without the performance penalty of using describeType() at runtime.
I got this cat that needs skinning, any ideas?