Enterprise Flex Development Do's and Dont's

I recently had an interesting discussion with a friend who manages a team of developers. He was complaining that although his team members are experienced Flex developers, many of them had very bad coding habits. I knew what he was talking about. Years of developing relatively small GUI applications on a very tight schedule caused AS3 developers to adopt bad habits. Poor tutorials and a lack of good professional literature also contributed to this situation. When a person dives into Flex, many of the articles he or she will view online describe solutions for small applications. In such examples MVC and other patterns are absent, layout code is mixed with functional code, and many antipatterns are applied.

I think that Flex developers who are switching to Enterprise development will find the following short list of Do’s and Dont’s very useful.

1. Do use an MVC framework/architecture and stick to its rules! An MVC framework is essential when writing large-scale applications. Such a framework will already contain solutions to common challenges and thus compel the use of common design patterns. Enterprise applications are often developed by a large number of developers. The MVC framework encourages developers to adopt the same methodology and “speak the same language”. When you write small applications on your own you can avoid using an MVC framework and get away with it, but this is not the case when you are writing a large application and sharing the task with a number of team members.

<div style="text-align: center;">image taken from Priyang Patel’s Weblog

</div>2. Forget XML handling. Flex online docs are filled with XML handling tutorials. Many developers seem to be excited by the possibility of loading and handling XML and incorporate these solutions in their code. While loading and parsing XML maybe useful in small applications, it is redundant in enterprise applications.

In an enterprise application XML may be present in the integration layer. For instance, if you are using SOAP web services, the messages to and from the server are constructed from XML. However, in an enterprise OO application, data should be handled as objects. The data might consist of XML but your code at large should not be aware of it. Your code does not need to be dependent on a specific XML structure coming from the server because a specific encoder and decoder should be handling the XML. If you are using a standard integration layer (SOAP, REST) third party solutions should be used to perform the XML-related tasks thereby relieving you from the need to write large chunks of XML parsing code. For example, the SOAP Encoder and SOAP Decoder should handle XML for you if you are using SOAP.

3. Use resource bundles Enterprise application texts should be customizable. They should allow administrators to change the content, or even the text language, when necessary. Large organizations in many countries (the EU for example) require the applications that they purchase to be entirely (100%) in their native language.

4. Stay away from the Flex Builder WYSIWYG Editor Flex WYSIWYG Editor (design mode) can be used to drag and drop or resize components on the application screen. This method is really efficient when you need to create something quickly and can compromise on it being dirty. Unfortunately the Flex WYSIWYG Editor generates code that is very difficult to maintain. One symptom is the hard coded x and y values of each component on the screen, which will be problematic when you need to resize or scale your screen.

5. Don’t mix AS with MXML MXML is used to describe your application layout whereas AS is used to create business logic, and the two should not be mixed. A number of methods are available to help you keep the two separate and the View Helper pattern is one of them. By sticking to this rule you will be able to create a clear separation between layout and functionality. It will also be easier to manage and your code will be readable to others.

6. (Rob’s addition) - Maintain a library of reusable generic UI components such components should not be dependent on your application code or used only in a specific scenario. Instead they should be generic and available for all team member to be used in different scenarios. Try to determine where a piece of UI code can be separated and isolated for reuse and make that piece a separate component.

These are my do’s and don’ts feel free to comment and add yours..