MVC design philosophy
Posted by: Romuald in experiments, talking, tags: as3, class, data management, experiment, flash, flex, frameworkHi 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.
 |
 |
| View Demo View Source Download Source |
View Demo View Source Download Source |
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 comment what you feel is good or wrong in the core concept.
Romu
Entries (RSS)
October 6th, 2009 at 12:51 pm
[...] This post was mentioned on Twitter by Romuald Quantin. Romuald Quantin said: sorry wrong link, here the direct one http://is.gd/40bM9 Flash MVC AS3 framework experiment, need comments on the concept #as3 #flash #mvc [...]
October 6th, 2009 at 7:32 pm
why don’t you explain the idea a bit further? What makes Wires and how do they relate to PureMVC? You cannot think the people to look though all your code to find the needle. But best wishes for your framework – why not?
October 6th, 2009 at 10:41 pm
There’s no direct relation to PureMVC. But if you need one, I can make an analogy for you
I’ve updated the post above but I paste there the additional information as well:
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 above.
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 view and an employee details view. But also 1 model (the employees data), all of them only related to employees matter.
I hope it is giving you some lights on what I’m trying to do, or at least, on how I’m trying remove the problems I encounter.
Romu
October 8th, 2009 at 8:29 am
Romu,
You are very brave to take this on and I wish you good luck. You say you are trying to avoid hundreds of classes. That’s got to be good. MVC is something I would very much like to do but finding the time to is a problem.
I like your drawing and, as a visual learner, I would encourage you to provide some diagrams and SWFs of those “Wires” (I do like that name) so that we can find an easier way to understand the interactions that occur between elements.
October 23rd, 2009 at 11:36 am
Just stumbled upon this post. I was using PureMVC/Fabrication for my last project and wandered how much code is needed for a modular application. I will definitely take a look on SomaMVC.
October 23rd, 2009 at 11:48 am
Sure feel free, let’s just call it SomaCore as it is only an experiment for now. Soma MVC is another framework released on this blog (www.soundstep.com/somaprotest) and it has nothing to do with SomaCore, both in terms of purpose and code.
Soma MVC is not really good for loose-coupling coding, that’s why I’m experimenting with SomaCore. Soma MVC has been built upon Cairngorm while I’ve built SomaCore from scratch.
Please feedback if you test SomaCore.
Romu
November 25th, 2009 at 1:26 am
[...] 者思想和Mate事件系统的优点的充分发挥Flash体系的超轻量级框架。在这里， [...]
November 29th, 2009 at 12:02 am
Thanks for this. I share your sentiments about the verbosity and boilerplating that DI and PureMVC tend to bring, and would like to find an option that makes this an unconscious process. Will be looking at this and RobotLegs for future projects.
Thank you.
January 27th, 2010 at 2:53 pm
Looks interesting! But one Question: Why does Soma require “stage” to be Stage (exept for the name
) and not only an IEventDispatcher or DisplayObject. If you try to host more than one “Somas” of the same type in your application, those instances just react to the SAME events and do literally the same (which is kinda funny watching 
).
I modified your SomaCafeTownSend example to support the situation described above by turning stage into an IEventDispatcher and not passing the Application itself to the SomaApplication constructor but an instance of an component which hosts the navigation-ViewStack. I also modified the SomaApplication constructor to call super() and not super(.stage). Now I can edit the user data of the 2 instances independently.
What do you think about it? Did I miss something obvious?
Lg
warappa
January 27th, 2010 at 3:17 pm
The idea was to have only one IEventDispatcher, the stage, without having to create a Singleton or whatever, so it is accessible from anything and especially the view (to keep the view free of framework code).
Doing that, yes a command will drive two Soma instances. The good thing about that is you can use the same event from modules (like a loaded swf that would dispatch those events), or from other Soma instances. I thought you could easily use a “selector” in the the events to know which Soma instance you want to drive. I believe having more than one Soma instance is aspecial need, right?
Now, I’ve done it this way. I had to make choices but I’m not pretty sure what would be the best.
The problem with passing something else than the stage is, if your IEventDispatcher/component is not on the display list, you won’t get events dispatched from another view. But, is that a problem or a capability? I’m not sure either.
Your input is definitely interesting. Could you put you demo and code online somewhere? or send it to me so I can see what you’ve done more precisely?
Feel free to create a post on the forum, maybe it will be easier to push the conversation further if you’re interested, if you don’t mind registering!
http://www.soundstep.com/forum/
I’ll think about that anyway.
Thanks
Romu