|
MVC is about loose-coupling, and Modular Programming takes that concept to the extreme. A modular application can dynamically load and unload 'modules' at runtime - completely separate applications in their own right, which interact with the main application and other modules to perform some set of tasks. The MultiCore version of the PureMVC framework for AS3 (which has recently been promoted to 'production' status), enables developers to create modular applications in Flex, Flash and AIR. Each 'Core' in a MultiCore app is a complete application, either the main application, or a loaded 'module'. A Core can be a regular Flash movie or a Flex Module. Options for Inter-Core Communications
Currently, there are two demos for MultiCore, Modularity and PipeWorks. The demos illustrate different possibilities for communication between Cores. Study these and feel free to mix and match these options within any MultiCore app. Modularity focuses on the interface-driven approach. It defines two interfaces IWidget and IWidgetShell. The IWidget interface defines all the methods that the main application (or 'WidgetShell') can expect a 'Widget' to expose. Conversely, the IWidgetShell interface defines all the methods that the 'WidgetShell' must have. The Widget is given a reference to the WidgetShell, and visa-versa. This is a good approach if you want synchronous communications between Cores and don't mind them having references to each other. PipeWorks takes a different approach altogether. Utilizing the new MultiCore Pipes Utility, it creates even more separation between Cores by creating named pipes and using them to connect the Cores together. The Cores then send messages to each other for communications. Since the Cores don't have references to each other for method invocation, the communications are asynchronous. This is a good approach if you don't want to use interfaces and give Cores a reference to each other.
The Pipes utility defines a number of 'pipe fittings' including Pipes, Tees (merging and splitting), Filters, Queues, etc. These fittings can easily be assembled to create any sort of configuration you wish. Filters allow you to modify or reject messages passing through a pipeline based upon custom logic and parameters. You can dynamically change a filter's parameters at runtime by sending a special message down the pipeline targeted to the filter in question. For instance in the PipeWorks demo, many modules generate log messages, and send them on a pipe to a logging module. You can change the 'Log Level' in the main application and cause the filter to reject messages below a certain level. Queues allow messages to accumulate until a special flush message is sent, and the messages in a queue can be sorted by priority. MultiCore and the Pipes utility both have been thoroughly unit tested. In addition to all the functionality of the Standard version, MultiCore has a new method for removing an entire Core at runtime. Which Version of PureMVC Should You Use? With two versions of the framework available for AS3, everyone is wondering which one they should use for their new deveopment, and what the differences are. For those just learning, I suggest beginning with the Standard version, since all the documentation is based on it and there are many more demos. Once you've mastered it, using MultiCore is extremely easy. Technically, the differences are minute. Rather than using Singletons for the main actors, MultiCore uses Multitons. So each Core is referenced by a unique string called a 'multiton key'. Even if you are writing an application that doesn't load any modules, it still needs a key, like the name of the app. This key is used when you call the factory method of the Facade, and it in turn creates Model, View and Controller instances using this same key. Also, all Notifier sublcasses (Mediator, Proxy, Command) do not receive their reference to the Facade immediately, and so you cannot reference the Facade inside your constructor, you should wait until initializeNotifer or onRegister to perform any facade interaction. These are really the only differences. So if your application is simple and you don't forsee it ever needing to work with multiple Cores, then the decision to use Standard or MultiCore comes down to unit testing really. It turns out that unit testing a MultiCore application is much easier than a Standard version app because you can get a new Core for each test, alleviating the need for per test cleanup. So if you plan on unit testing your app then you still might want to choose MultiCore, just for cleaner tests. Once you begin to work with MultiCore, you'll probably wonder why we even need to keep the Standard version around. The main reason is that while MultiCore might be the only solution you'll ever need for AS3, other languages and platforms that don't support a modular paradigm would find the MultiCore version overkill; it just wouldn't make much sense. Therefore, these two versions will both continue to be supported in the same manner going forward, and their functionality (where it makes sense) kept the same. Enjoy, -=Cliff> PS: Thanks to my good friend Tony Kirman for his orignial photo, used here with his permission.
|
