Code Behind vs Template Components

原文链接：http://developria.com/2010/05/code-behind-vs-template-compon.html

I think a lot of times we as developers get caught up in our own world, and we forget how all of the things we do to make our code clean and easy to maintain for ourselves and other coders can make it completely unintelligible to people with other priorities. For instance, sometimes designers or novice developers may need to use our code. We need to consider whether the design patterns we use in those situations will, in fact, make their work flow easier or if they just seem to us as developers like they should.

Code Behind

Code Behind is a design pattern that separates out the logic and the visual representation of a View component. One reason that is sometimes given for using Code Behind is that it puts the "designery" stuff in an MXML file and the "logic" in an .as file. The way this works in practice is that the .as file will extend a Flex base class, often a Container class. This class will contain all of the wiring and functionality for the View, but none of the visual children needed to represent the View.

Instead, "someone" creates a separate MXML file that extends the .as file. This MXML file handles the instantiation and layout of the buttons, text inputs, etc., whose behavior is controlled by the .as file. You might be asking yourself how on earth the .as file is going to control components that don't even exist in that file. Even if you're not, I think it's a good bet that the "someone" charged with creating that MXML file will, unless he or she is at the same skill level as the developer who wrote the .as file. From here on out, I'll call that person a designer, for convenience.

That's because the .as file is essentially acting as an Abstract Class which contains "place holder" variables for these controls. When the designer creates subcomponents of the right type in MXML with the same id as the variable in the .as file, this will override the "place holder" variable with the instance created in MXML. In order for the designer to be able to do this, he either needs to have an intimate knowledge of the internals of the .as file and the concept of an Abstract Class or he needs to have some really great documentation that tells him exactly what to do to create the View without this knowledge.

Once this MXML file is created, an instance of the file needs to be created and added to the overall layout. So, looking at this from the point of view of the designer, you have to create an MXML file to give a layout to the View...then add that MXML file into another MXML file...? It's a lot to expect someone to get his head around, and there are a lot of things that can go wrong. Will he know what to do to fix null pointer exceptions if they happen?

But the essential problem this is meant to solve is that some controls are easier to lay out in MXML than as, especially the List based ones, but many developers don't like to mix MXML and ActionScript, because they feel that it's hard to read the two together in the same file. I find that switching back and forth between MXML and Class view in the Outline panel helps with this a lot, but I can see the point.

Could there be another solution where you could let MXML handle the more complicated parts of the layout, but make the whole process easier to understand?

Template Components

I've talked before about Template Components, where you use a subclass of Container to provide generic functionality, but the specific children that the functionality operates on can be added later, usually in MXML. The logic of the component is (or can be) still handled in an .as file, but there are two main differences:

1. The subcomponents are supplied by an instance, not a subclass. This can potentially lead to more flexibility in how the View is used, but the true advantage of this is that the component can be used in MXML just like any other component. For example, a DataGrid is a Template Component, and DataGridColumns are supplied by the instance. Since developers of all levels are already familiar with this concept, there's no learning curve to explain what needs to be done.
2. You probably should supply default instances of the child components. This means that you'll probably need to code in at least a minimum of layout. On the up side, you'll avoid null pointer exceptions if the designer doesn't provide any child instances.

I don't think that Template Components are the answer to every situation where you might want to use Code Behind, but I do think that if the reason you're looking at Code Behind is to allow a designer or someone with less experience to handle the layout of the component, a Template Component might provide a solution that is conceptually easier for the situation. What do you think?

By   Amy Blankenship  on   May 8, 2010 8:16 PM