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.