PureMVC Architects Lounge

Hello,

I have been trying (and failing) to grasp MultiCore architecture but want to use it badly in my current project.  However, having other deadlines, I cannot in good faith push it on my team leader yet (also I don't want to work horrendous overtime if something goes wrong).

However, we have a serious problem.  Our current app has tons and tons of classes, many of which do not get used during the operation of the application.  In fact, many of the Mediators, Proxies, Commands are not used because most users do not have have account settings permitting their use.  Nonetheless, for the application to be usable by everyone, those classes are included.

I desperately want to end this.  Eventually, I want to use MultiCore, but I just don't have time to completely scrap our existing code.  So I am looking for an intermediate but progressive solution.

Here's what I have so far:

First I want to organize the start-up logic so that it is less monolithic.  I will break up the start-up command so that it no longer registers every possible Proxy and Mediator.  I will have it simply check the account information for the user and then dispatch service-specific start-up commands that the user actually has access to.  So far, this is a no-brainer, right?

But, even doing this, I guarantee that references to unused classes will still persist in the final bytecode.  If a particular service is ever deleted, reference errors will occur in the project, headaches will ensue (because spaghetti will creep in no matter what). 

So next, without going full-barrel MultiCore, I am hoping that I can use BaseModule as a way to compartmentalize Proxies, Commands, and by extension Mediators and their view components.  I think I should be able to have a command simply load a service-specific module (BaseModule) whose only code is to then immediately register and fire its corresponding service-specific start-up command.  Remember, this command presumably holds references to proxies and mediators which will bring with it any view component code and what-not for that service.

The final trick is then to watch that class casting and constant references do not exist in the "shell" code but are really actually confined to code related to one service.  ServiceAMediator should not communicate with ServiceBMediator by doing something like this:

var o:IServiceA = IServiceA(facade.retrieveMediator(ServiceBMediator.NAME)).doSomething()
//by calling NAME on ServiceBMediator, I guarantee it gets compiled with ServiceA
//even if the above logic never actually gets executed...
//this may seem stupid, but this actually happens in our app
or

var o:ServiceBMediator = ServiceBMediator(facade.retrieveMediator(AppConstants.ServiceBMediatorName))
o.doSomething();
//obviously, casting with ServiceBMediator includes it with ServiceAMediator when compiling.
//better to use an interface if the above logic might not be executed based on account settings.
Instead, we will need to use common interfaces when necessary and preferably find solutions for our current (bad) code using Notifications rather than direct references.
Anyway, this is what I am thinking of proposing as an intermediary solution until me and my team feel confident we can re-write the current application in MultiCore.  BTW, it's not just that we don't understand MultiCore, but also Pipes, Ant, and Flex Builder project organization.

What I would like to know is if there is any thing I've missed.  Is the above a good strategy in your opinion?  Any feedback whatsoever appreciated.

So next, without going full-barrel MultiCore, I am hoping that I can use BaseModule as a way to compartmentalize Proxies, Commands, and by extension Mediators and their view components.

Please resist the urge to do this. You will simply be trading one undesirable architecture for another. The existing architecture is burgeoning, but still following best practices. The new architecture you propose will leave you with spaghetti. Lots of things were tried before If you're going to go modular, use MultiCore. Think of those who inherit the application, particularly if it's you.

Either
1) Make a refactor to MultiCore a '2.0 priority', and proceed with best practices for the Standard version
2) Step away from the project for a day or two, do study MultiCore and the available demos, posts and articles and then proceed with an orderly refactor to MultiCore.

Number 1 is what to do if you really can't spare the time or you know for a fact that the refactor would take too long.

Number 2 would be a speedbump, but if you are chugging along fine with Standard, I guarantee you that MultiCore will not be that difficult to understand, the challenge is in coming up with your modular architecture, a simple module loading and caching mechanism (hint: Mediator is a good place to start) and decide if you want to make your modules talk to each other. 

I gather that you just want to 'snap in' a UI and the attendant PureMVC classes when needed. So that sounds like you might not have much intermodule communication, so probably interfaces are best for you to get going).

There is the pipes utility if there will be lots more routes than just from the child to the parent and back. There are interfaces where the parent and/or child have references to each other and communicate via interface methods. The big problem people run into is timing and protocol. Being sure a module is loaded before sending it a message (hint poke in and out pipes into it and listen for an 'i'm listening' message before sending anything).

There is also LICS, a new approach to doing MultiCore that's meant to be easier than pipes, but I've not investigated it. And there is Fabrication, which is probably a bit more of a bump than you want to hit this week, but offers a lot of functionality for intermodule communications.

HTH,
-=Cliff>

Thanks for the advice Cliff.
I'll follow it.
I'll try taking #1 tack with my supervisor.   During my downtime, I will continue to try to come up with a MultiCore app that uses interfaces to handle the modules as a proof-of-concept type thing to show him later.

Because of the way the application is currently put together and the structure of the data that is used, I know I am going to have to have communication between the shell and the modules.  Pipes is far more complex than I want to get involved with right now, especially for the task at hand.  I did take a look at LICS a while back and it is closer to what I would come up with naturally on my own but there were some things I didn't like as well (can't recall what).  Anyway, I think I can get what I want with a few interfaces and then if more complexity creeps in later, we can re-evaluate pipes and LICS.

PS

Btw, what do you think of this idea:
Most of our Mediators instantiate their own view component upon registration.  What if instead they first loaded a module and then instantiated their view component from the module (upon registration)?  Of course, this still requires the Mediator to access its view component through an interface or it's meaningless.

Most of our Mediators instantiate their own view component upon registration.  What if instead they first loaded a module and then instantiated their view component from the module (upon registration)?

If the Module only contains view components and methods to get them, then yes, it's reasonable. But if you're going to have PureMVC classes in that module, please refer to my earlier advice and don't do it. You need MultiCore and a strategy for communication or you'll regret it.

-=Cliff>