[osflash] Suggestions on the architecture of modular applications based on MVC

[Arnoud Bos]

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: osflash-bounces at osflash.org [mailto:osflash-bounces at osflash.org] 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
osflash at osflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org