Think of modules as a deferred class loader. It isn't like java where you reference a class and it is magically there. You have to request the load of the classes and wait for them to arrive before using. But that difference aside, you put things in modules and get them later whether they are UIComponents or data, and you pack classes into modules based on optimization of load time and development and maintenance hassle.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Rodseth Sent: Monday, August 25, 2008 10:38 AM To: [email protected] Subject: [flexcoders] Modules vs MVC I'm not sure how much this is a Flex question, as opposed to an MVC design question about approaches to composing MVC and where to put view factories. I've successfully built pseudo-modules which instantiate a model, view and controller triplet in MXML. I've also nested this pattern. But in these cases, all views of the module were contained within the module itself, if you know what I mean, so the fact that the (pseudo) module was a UIComponent was fine. However, if a conceptual module defines several views which don't get laid out in a common container (well, other than the application), questions arise as to where the view factories belong. Make the module an invisible component which instantiates a model and can spawn MVC triplets with that common model on demand? Let the module represent one "main" view, but still with the ability to spawn others? Make the module itself a non-UI entity, and store a collection of them as part of the application model, independent of UI layout? In Flex, Modules are UIComponents, but I see that ModuleBase is also available, so I know if I go with something like the last-mentioned approach, I won't be stuck if I need to convert to actual Flex modules at some point. Comments?
