|
Thanks a lot Arnoud! I took a quick look, and it looks great. ;) I'll
definetely check this out tomorrow!! Thank you, João Saleiro
Arnoud Bos wrote: You definitely should look at flexcairngorm in google code. Now your modules van be mvc as wel and finally cairngorm works with modules.I have to try it myself but the developers seem to know their stuff very well. Good luck! -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Namens João Saleiro Verzonden: donderdag 10 april 2008 2:06 Aan: Open Source Flash Mailing List Onderwerp: [osflash] Suggestions on the architecture of modular applications based on MVC Hey guys, I am working on a Flex application based on Cairngorm. The application will be divided in modules for the purpose of distributing only the modules clients request. There will be a configuration tool on the application to "install" new modules, and manage existing ones. The motivation for using modules is to manage properly the complexity of the application while it grows and to help managing the roles on the team assigning each module to different persons. The first question is whether I should have: a) One Flex Project that has the application and several modules; b) One Flex Project for each module and another for the application; c) One Flex Project for all modules, and another for the application; I think the best option is to go with b). What do you think? Second question: which of the following seems a preferable practice: a) Only the application uses MVC b) The application and each module have it's own MVC architecture I would go with option b). The problem is that MVC has some Singletons and that will create problems, since I would have, for example, one Controller for the application and another for each Module. To solve this problem, I can use Modular - http://lab.arc90.com/2007/10/modular_1.php Modular will work as a proxy for the Controller, allowing to register new commands on runtime on the main application controller. Those commands will be defined on my Module. In terms of use, it seems practical and logic to me, but in terms of architecture, it seems a bit wrong to me - wouldn't it be preferable if each module had it's own controller? Why should the module depend so much on the application that uses it? What happens if the module is used on an application that doesn't use Cairngorm?... It's a bit questionable if Modular should be used or not. Anyway, even if I went with this option, Modular doesn't provide a solution for the ServiceLocator. So, this leads me to another question: a) Only the application knows the backend and the services provided by the backend; So, there will be only one ServiceLocator and all the ServiceDelegates will be defined on the main application. b) Each module knows the backend, and each module has it's own ServiceLocator and specific ServiceDelegates for the remote services needed on that module. I think the option b) seems more elegant to me. The problem is that the ServiceLocator implemented on Cairngorm is a Singleton, and the same happens with the ModelLocator. Since our implementations extend the classes on Cairngorm, even if I create "different" ServiceLocators for each module, that won't solve the problem since they are all one instance - they all extend the same ServiceLocator class. And I need one ServiceLocator per module. I could solve that by not extending the same base class... but this doesn't sound correct to me, since I would have to replicate the ServiceLocator code on each module... Can you propose another solution? I think there is lack of information on best-practices for developing big modular applications using modules and MVC. I am a bit stuck right now, since I need to make some important decisions on architecture before starting the development, and I do not want to change all the architecture later. Your opinion would be extremely helpful to me! Thank you!, João Saleiro _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org |
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
