MVC design philosophy
Hi Everyone,
This is not exactly a "Soma release", but I would like to share with you my last work so we can talk about: A new AS3 MVC Framework with its own design philosophy.
Why another AS3 MVC Framework?
I've been working with different Frameworks in the last years, such as PureMVC, Cairngorm and Mate for the well-known. I've always knew that I would write my own "MVC design philosophy", without taking big words, because I would have some needs that existing Frameworks wouldn't completely fill.
That's what happened. I needed a Flash lightweight framework, not DI, event based, working both for Flex or Pure AS3. The biggest inspirations have been PureMVC for the proxies and mediators, and Mate for their event system.
I'll be starting an interesting AIR Modular app and I needed something that will easily allow me to have views and models free of Framework code, without creating tons of files or use any injection. I also wanted a Framework very flexible, so I can use it even for smaller project, being sure I'll be effective in terms of development time.
Free the views and models
First problem, free the views and models of Framework code (loose-coupling). It seems there's a wave of DI Framework but... I've never really been into DI Framework, because they tend to control the way you're doing things. If you stick to it, it is fine, but I've always felt more freedom with framework like PureMVC. I might be wrong, it is just an opinion and not even entirely true as I didn't felt that problem with Mate.
So, to solve this problem, I used the events Mate concept. A basic Flash Events that has a bubble property set to true can become Commands when they are mapped to a Command class. Those events can be intercepted, stopped and processed by the Framework (execute Commands). The great thing is, views and models are free of Framework code and can use Commands because they are just Flash native events.
Wires introduction
Second problem, was to "update" data or states in the views and models. PureMVC is using proxies and mediators and I like that approach. However, you end up by creating tons of files for the sake of loose-coupling pratice. So I've created something that I call "Wire". Now software engineers or PureMVC adept might say that what I'm doing is wrong. I have no idea, I'm no computer scientist, I do what I feel and I'm sharing it with you.
Wire are classes that can contain Framework code and they will be the links between the models, the views, the Framework and... whatever you like. Wire can be proxies, they can be mediators, but they can also be both and handle more than one view or model.
Basically, they are as free as you want them to be. They can even be optional if you don't care about good practice or loose-coupling programming. Wires have easy access to all the framework, models, commands and views. They can register create models, views, register commands or create other wires.
Update from comment:
So far I saw two ways to inject/update information into views without having framework code inside:
- Dependency Injection
- Buffer classes (such as Mediators and Proxies in PureMVC for the analogy, respectively for Views and Models). I mean "buffer" by classes that act as steward of other classes.
I've chosen the second way, and I've created a "buffer" class that I called a Wire.
Wires are completely free classes. I won't tell you how to use them (because that's up to you) but I can tell what you can do with them. Wires can be used to update views and models but they are not tight to anything. They are not even only tight to one tier. To create a wire class you extend Wire and implements IWire, and here are the roles they can take:
- a wire can act as steward of a view (such as Mediator in PureMVC)
- a wire can act as steward of a model (such as Proxies in PureMVC)
- a wire can manage both a view and a model
- a wire can manage multiple views and/or multiple models
- a wire can be considered as a subdivision of the framework and create its own views, create its own models and register its own commands. Much like you would create a specific package to hold a specific matter.
When I build something, I always try to keep a good level of freedom to handle problems how I like but most importantly, how they should be. If you like to have the framework telling you (or forcing you) how to build your application, fair enough but you won't like it.
The wires are the free elements that will let you built your application the way you like or the way it is required to be. They can make your application rigid, segmented, flexible or centralized, depending of the role you are going to give them. They are so free that I believe remove (or lesser) what I call "Framework Fight".
Let's take an example, the Cafe TownSend below.
There are 2 wires: the LoginWire and the Employee Wire. They both register their own commands to control their views and models.
The Login Wire only handles a Login View.
The EmployeeWire handles 2 views: a list of employees and an employee details. But also 1 model (the employees data), all of them only related to employees matter.
SomaCore
I temporarily named this framework SomaCore and it has nothing to do with the Framework I released on this blog (Soma). However, this framework might become the core of what will be Soma v3.
I post this code hoping to get your feedback or point of view of what might be great or wrong in this framework.
Here is a diagram:
Click here to download a zip file containing the Framework sources code (classes and SWC).
And here are some demos. I made a Flex Cafe TownSend demo and a pure AS3 demo.
This is a very early state, this Framework has not been used yet in a real project beside the demos above. Have a look and please let me know what you feel is good or wrong in the core concept.