Best Practice: Code Behind versus MXML Script Blocks versus View Helper

Often I see the question coming up on whether to use MXML Script blocks, Code Behind or Helper classes.
I think the question behind the question we’re addressing here is not whether to use Code Behind, MXML Script blocks or View Helpers, but is actually where is it best to place functionality in a Flex application.
But first of all, let’s have a quick rundown on what Code Behind, View Helper and MXML Script blocks actually are:


If you come from the ASP world you might be familiar with Code Behind, if not more information about Code Behind can be found at the livedocs and at the devnet.
The Script block is the part of an MXML file dedicated to ActionScript methods and properties.
For example:

<mx:Script>
private function doSomething() : void
{
blah…
}
</mx:Script>

For a View Helper, people might have different definitions. Personally, I’d define a View Helper as an ActionScript class that a MXML can call and listen to directly. Typically it contains the code related to the accompanying MXML and might even simply contain the functionality that developers otherwise would put in MXML Script blocks. It can have references to the view, such as the Cairngorm View Helper (which are not a recommended approach). I’d call ActionScript classes that help the view with more defined and fewer responsibilities utility classes. Utility classes usually don’t have references to views. They could i.e. be formatters.
Personally I find Code Behind is indeed a nice and quick way to organize functionality. However, I’d argue that if you would move code from a MXML Script block into a Code Behind class, you’re just changing the location and potentially rough syntax of that code. After this “refactoring”, your code still lives in the same context.
In a middle and larger scale application i.e. using Cairngorm, I’d advocate extracting functionality from views into unit-testable model and utility classes. IMHO such classes are best created when they don’t contain any references to views and few responsibilities. They should be simple ActionScript classes without dependencies on other contexts such as view components.
I’m not saying you couldn’t unit-test Code Behind classes. It is like unit-testing Cairngorm View Helpers, people have done this and are doing it successfully. However, I just find it easier to unit-test and also reuse classes that contain defined functionality adhering to OOP rules. If you keep your functionality in view code, this functionality often has much more responsibilities to keep track of.
Once you’re focusing on extracting the right functionality from your views and commands into unit testable utility classes and an application model deciding if you’d rather have Code Behind, View Helper or an MXML script block becomes less of an important decision to take. Once you’ve extracted functionality out of views, the view code left, isn’t usually that big. Just converting this view code into a different syntax (Code Behind, View Helper or MXML script block) doesn’t necessarily make it much better.

12 Responses to Best Practice: Code Behind versus MXML Script Blocks versus View Helper

  1. Scott says:

    Any chance you’d be willing to post a small before and after code example, to illustrate your methodology?
    Thanks,
    -Scott

  2. A small example would be really helpful. I’m trying my hardest to use best practices when writing Flex applications.
    I’m not entirely sure what you mean by “I’d advocate extracting functionality from views into unit-testable model and utility classes”.
    Do you mean creating several models, one for each view?

  3. AlexU says:

    Hi Ed and Scott,
    I hear you and I plan on making this a focus on this blog in future. For now however, you can read this series of blog entries
    http://cairngormdocs.org/blog/?p=20
    Best,
    Alex

  4. Borek says:

    Hi, we are new to Flex development so the separation of MXML and ActionScript code is an important issue for us now. I have some experience with ASP.NET (not ASP as you suggest) so code-behind looked familiar to me but then I asked – what’s the real advantage of code behind when compared to mx:Script source=’…’? I was able to come up with this:
    * The same for both approaches is that ActionScript now lives outside of MXML which is a good thing
    * Disadvantage of code behind is that you are creating 2 classes instead of one. You do so only to separate code from MXML, not for any other “valid” OOP reason.
    Surprisingly, I was not able to find any advantage to code behind so we deprecated this approach as smart but nor really useful or adding any value. What do you think?

  5. Biometric says:

    Thanks for your sharing!

  6. Tink says:

    “I’d advocate extracting functionality from views into unit-testable model and utility classes. IMHO such classes are best created when they don’t contain any references to views and few responsibilities. They should be simple ActionScript classes without dependencies on other contexts such as view components.”
    With that said why not just use the source property of a script tag and external AS files not classes. I know you don’t go into implementing code-behind here but Adobe officially suggests inheritence, and because of this it seems the standard way Flex developers are now approaching it.
    This fails in seperating logic from view. An AS file containing all logic, bindable properties an no references to the view is a much tidier approach IMO.

  7. Buy photo says:

    Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks and Greetings

  8. Thanks a lot for this article.

  9. sharp aquos says:

    A small example would be really helpful. I’m trying my hardest to use best practices when writing Flex applications.

  10. Webdesign says:

    Many thanks for share us the Code-Link on Livedocs and devnet. Very usefully!
    thanks from Germany, Werbeagentur

  11. JTtheGeek says:

    I agree with your ideas big time, but I think you went a little astray trying to draw a line between code behind and the importance of refactoring logic into separate classes, at the expense of the code behind method. Done correctly, you need both. In practice it necessary for the code behind as there is logic / code that is tied directly to that page, and can not be de-coupled as it’s view specific logic, that belongs in the code behind. Anything else definitely, belongs out of the page and either in utility classes or controllers, and one should always examine their page/component code to look for places to refactor.
    Additionally there are a couple of other advantages to using the code behind or the view method over the script blocks; multi-monitor systems with the design on one, and the code on another typically doubles my development speed, ability to use a different ide for design than for coding such as flash develop which is WAAAAAY better at code completion and intellisense, and finally the ability to seperate the design and logic allows multiple people in a source control environment to work together more efficiently.
    My $.02

  12. AlexU says:

    What I describe above as “utility” methods has been define clearer by the Presentation Model pattern: http://weblogs.macromedia.com/paulw/archives/2008/04/unit_testing_us_1.html#trackbacks
    The biggest advantage is that these objects don’t have a direct reference to views and are therefore much easier to unit test.