Flex Best Practices - Multiple Flex Projects or 1 Project, multiple Application MXML files

Question

Having seen several different ways of setting up larger projects in flex, I'm wondering what your opinions are of how to organize projects that are going to require 2 or more different applications. For example a public and private site within the project.

The two main ways that I know of would be first, creating one flex project, and then adding different mxml application files. Both applications would be able to share code.

The other way (which I currently like, but have no way of justifying), would be to create a different flex project for each application, and any code that needs to be shared could be part of a shared flex library. I guess something about the separation of the applications I like more, especially since I'm either working on one or the other at a time.

What are your opinions, and do you have any reasons for doing it one way or the other?

Answer 1

I have used common library approach, it gives more decoupled code. Common library can also be used by some other projects later. Two applications in one project are mix and poor organisation for me.

Answer 2

I recommend the library approach. That said, you can still use multiple applications in one workspace (and I do), but it's handy to keep the "one project, one application" rule. My workspace might have 5 projects, each of which has an MXML application, and 4 library projects, which have none.

Answer 3

One project with per application. I agree with everyone else. I would add that common libs are a good way to go as well. If you are working for a client that is having you build 2 or 10 applications then you will for sure want to reuse features as you are likely going to do this to save time and also so that the applications share common themes and functionality.

I find that a good rule to follow is if you tend to use a feature more than two or three times then it is a good candidate to be placed in a common lib.

I usually structure my projects by features. and example would be something like ... take an MP3 player application.

I would have the following packages

com.yourdomain.applicationname.mp3controls com.yourdomain.applicationname.albumlistings

each feature would contain commands, model, view packages to start.

then maybe you find that you really like the mp3controls feature and you can use it on some other apps like say a video player application. The mp3controls could then be put into a common lib and then maybe renamed to something like "mediacontrols" or something.