[osflash] Suggestions on the architecture of modular applications based on MVC
João Saleiro
joao.saleiro at webfuel.pt
Thu Apr 10 08:18:15 PDT 2008
Modular is an extension to Cairngorm to allow modules to register
commands on runtime on the Controller of the main application. The URL:
http://lab.arc90.com/2007/10/modular_1.php
João Saleiro
sLangeberg wrote:
> Our sub-apps were indeed Module classes. Only coupling was on the
> ServiceLocator, but as I said, in our example, it was a pretty small
> file, anyhow.
>
> I'm not sure what you're referring to, by Modular. We didn't have
> problems with Module(s) accessing Delegates, as they were defined in
> the Module.
>
>
>
> On Thu, Apr 10, 2008 at 5:02 AM, João Saleiro <joao.saleiro at webfuel.pt
> <mailto:joao.saleiro at webfuel.pt>> wrote:
>
> Thank you for your answer. When you said you had several
> "sub-apps", those were Modules or Applications? I have seen people
> using Applications instead of Modules, because they felt more
> comfortable while testing - but this way they end up with bigger
> SWF's.
>
> Having the services on the Main App won't create a tight coupled
> architecture between the module and the app ?
>
> In your architecture, have you used Modular? If yes, when you need
> to have a command (which is defined on the module) that calls a
> ServiceDelegate (which is defined on the application) how do you
> solve the problem that the Module doesn't know the ServiceDelegate?.
>
>
> Thanks,
>
> João Saleiro
>
>
> sLangeberg wrote:
>> We had no problems implementing a system similar to your
>> description: One 'portal' app loads multiple mudular 'sub-apps'
>> at runtime. Each is standalone cairngorm app. As you said,
>> however, the biggest gotcha is one big shared ServiceLocator at
>> the main app level. In our case, wasn't big deal, as I think
>> there's only about one remote object per module, for us. Not much
>> more, anyhow, as each is a full controller / for the respective
>> service on the back-end. Wouldn't be hard to implement your own
>> ServiceLocators that impl same interface, but allows you to have
>> one per module, and could be their own Singletons. It' just an
>> odd setup, as they wanted to implement an MXML definition for
>> services.
>>
>>
>> On Wed, Apr 9, 2008 at 7:05 PM, João Saleiro
>> <joao.saleiro at webfuel.pt <mailto:joao.saleiro at webfuel.pt>> wrote:
>>
>> 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 <mailto:osflash at osflash.org>
>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>
>>
>>
>>
>> --
>> : : ) Scott
>>
>> Helping your grandma on the interweb
>> at: http://blog.criticalpile.com
>> ------------------------------------------------------------------------
>> _______________________________________________ osflash mailing
>> list osflash at osflash.org <mailto:osflash at osflash.org>
>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org <mailto:osflash at osflash.org>
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
>
>
> --
> : : ) Scott
>
> Helping your grandma on the interweb
> at: http://blog.criticalpile.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/osflash_osflash.org/attachments/20080410/8b13f524/attachment-0001.html
More information about the osflash
mailing list