Best practices for large Flex applications?

Question

I am in the middle of creating a fairly large flex application, and over time it began to give way to unsupportability.

I use 3 external library projects that are still small enough to remain maintainable and reusable, but the main project seems impossible to organize in an organized way.

Part of the problem is that I have about 30 objects that inherit from one abstract object such as a superclass. All child objects have both a logical component and a ui component that are closely integrated with each other. A superclass object has about 60 common methods and properties, most of which can be overridden in any of the child classes, some of which must be overridden in all child classes.

To add to the complexity, they must communicate with each other, and usually this happens through the container object in which they are located. In addition, the main project must create value objects from them so that they can be sent to the FlourineFX server for storage and additional authentication / authorization logic.

I created much larger projects in languages ​​from old MS BASIC (pre VB), Ada, VB (from 3 to .Net 1), C ++ and C # without this problem. (well, the old VB tended to this problem due to the same close integration between the UI and the logic) So, is there something that I don't see, or are there any best practices that I can implement? (even if it means rewriting entire lines of code)

And yes, it could be an extension for this conversation.

Answer 1

Do you use any frameworks in this project? A framework would help modulate much of this complexity and hopefully remove many of the dependencies that you have between application logic and views.

I am an active proponent of the RobotLegs framework , which implements the mvcs template and offers dependency injection for use throughout your project. There are others like pureMvc , Cairngorm , Mate . Take a look around and see what works best for your project.

It seems to me that you really need to do a lot of refactoring, which is a risky process in such a big project. It might be worth it if you are trying to save it. If you are going to refactor refactoring into a framework. This is probably the area that will give you the best chance for your dollar (pound for the British;))

Answer 2

James Hay's starter starter is good, but for HUGE applications, it will take me a while to check and consider memory management for some of the sentences in this answer / talk. RobotLegs is great and all, but I will worry about the “excessive syntax” and possible memory management problems that it will create (although I must admit that I never used and never avoided robotLegs due to the use of single player games). If you were thinking about IoC and dependency injection (for example, what robotLegs provides), I would suggest looking at swiz - I really like that the new example-direction training is taken. My only problem with it (in the current beta version) is that they have some problems with cleaning, although these problems are easy enough to fix (look at their source and at any time when you completely remove the component from the scene, you we’ll have to play the game’s profiling and make sure everything is removed - we had to create temporary functions to remove changewatchers and destroy the “display list of bean instances” until they fix this material).

The project I cited had many potential problems that you should worry about. There are thousands of modules in our ERP application, and everything runs on client computers every hour / day, constantly loading and unloading modules. Garbage collection and memory management were and are problems.

Regarding the use of an assistant annoying carhorn or pureMVC, we created our own structure two years ago. He borrowed ideas from cairngorm, but in general my suggestion is to use everything that you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules), and this has simplified usability and code readability.

Hope my blabbing helped at least a little. Good luck.

Answer 3

It seems you just need a clean separation of the interface and domain components. Take a look at the component recommendations and discuss the Martin Fowler presentation templates , especially the Presentation Model .

To assemble these things, you can use an IoC container like Spring ActionScript . This is a non-intrusive structure that allows you to separate layers.

Don't let the infrastructure get in your way. I have seen massive abuse of frameworks like PureMVC and Cairngorm, mainly because they use them on an all-or-nothing basis.