Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Advantages of PureMVC over Robotlegs 2  (Read 24348 times)
naghekyan
Newbie
*
Posts: 3


View Profile Email
« on: December 06, 2013, 02:02:53 »

I have just investigated both frameworks to understand the basic concepts, architecture and other details of PureMVC and Robotlegs 2 and now I don't know which one to choose. The problem is that I think both of the frameworks have almost the same architecture (Views, Mediators, events that create Commands which in its turn call some Proxy functions - in case of RL2 Models and Services). In addition to this I see that Robotlegs has introduced an elegant mechanism of automatic dependency injection (which as I know what taken from Java), and this really took that framework a hug step forward. In the case of PureMVC you should use the Facade. Now can I consider that Robotlegs has accomplished the same that PureMVS has done, but in a better way? If no, then what are the key advantages of PureMVC over Robotlegs?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: December 07, 2013, 11:19:53 »

what are the key advantages of PureMVC over Robotlegs?
I would have to say simplicity and portability. And I'm talking about PureMVC vs DI in general here, not just RobotLegs.

Simplicity
Many pieces, loosely coupled is a mantra that guides OOP design, but loosely coupled without pattern can make working on an app that uses dependency injection difficult.

If anything can have any other thing injected into it, then multiple dependencies form on the thing itself. You've freed the object getting the thing from having to know how to get it, but you've still formed a dependency on it. If five objects inject a particular thing, then refactoring that thing becomes increasingly difficult.

PureMVC is more focused on message passing and formalizing the collaborators based on a few simple patterns. It's simple, but it's enough to do pretty much any size application you want to attempt with it. All those programs will look very similar because they use the same patterns.

DI doesn't exactly encourage pattern use. I'm not saying it discourages it, but I will say that developers, particularly good ones, are a lazy lot. We figure out the path of least resistance like Yoda feeling the Force. And since you can just inject something anywhere, you are not encouraged to consider the collaborations you form on the spot while fixing some problem or trying to demo or die. But now there is a coupling. If you're wise and inject Interfaces, you'll save yourself a lot of work, but i digress. DI is championed, IMHO, mostly by cowboy coders who feel penned-in by a framework that is prescriptive. [I can feel the flamethrowers lighting up on that one.] But I get that. I rode those dusty plains for years. But your work is amplified if you're contributing to a team in a concerted effort that doesn't involve a lot of head-scratching about other people's code. If everybody is confused about some part of the thing, then that's mental friction that manifests as technical debt.

Portability
Check the code repositories. There are a lot of versions of PureMVC out there. They're not all as well supported as AS3 (primarily because I lived and breathed AS3 - and still do, mostly) and the time to coordinate on all those fronts. But the point is really that the idea itself is so simple and the actors and their collaborations and responsibilities are QED to build in practically any OOP language. Most of those ports were done in a weekend. It is easily ported because it uses the simplest features of the language for everything.

And because the scope of the framework itself was predetermined, you don't really have to worry if it's going to change and there'll be a whole new way of doing things. A program in PureMVC from 2006 looks pretty much the same as one you'd write today.
Logged
naghekyan
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: December 08, 2013, 02:57:21 »

Thanks for you response. But I wish I could understand your statements about simplicity. (It is not simple to understand the statement of simplicity :)) Could you please outline how PureMVC is simple that helps and how RL is not simple that creates a mess, please.
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #3 on: December 09, 2013, 04:29:22 »

It's worth noting how stable and unchanging PureMVC is. This probably stems from the simplicity and from Cliff's philosophy to keep it to its core mission.  For a developer, it is a huge advantage to use a framework that does not change (after it has been developed to its required level).

See the github stats (commits, releases etc.) for robotlegs and for puremvc.
https://github.com/robotlegs/robotlegs-framework
https://github.com/PureMVC/puremvc-as3-standard-framework
https://github.com/PureMVC/puremvc-as3-multicore-framework

----Philip
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #4 on: December 09, 2013, 07:49:19 »

... an addition to my previous post

It is interesting to see the size of puremvc in terms of source files and lines of source code.
$ wc -l `find . -name *.as`
     197 ./org/puremvc/as3/multicore/core/Controller.as
     160 ./org/puremvc/as3/multicore/core/Model.as
     293 ./org/puremvc/as3/multicore/core/View.as
      20 ./org/puremvc/as3/multicore/interfaces/ICommand.as
      64 ./org/puremvc/as3/multicore/interfaces/IController.as
     130 ./org/puremvc/as3/multicore/interfaces/IFacade.as
     149 ./org/puremvc/as3/multicore/interfaces/IMediator.as
      56 ./org/puremvc/as3/multicore/interfaces/IModel.as
      75 ./org/puremvc/as3/multicore/interfaces/INotification.as
      56 ./org/puremvc/as3/multicore/interfaces/INotifier.as
      80 ./org/puremvc/as3/multicore/interfaces/IObserver.as
      61 ./org/puremvc/as3/multicore/interfaces/IProxy.as
     105 ./org/puremvc/as3/multicore/interfaces/IView.as
     121 ./org/puremvc/as3/multicore/patterns/command/MacroCommand.as
      41 ./org/puremvc/as3/multicore/patterns/command/SimpleCommand.as
     352 ./org/puremvc/as3/multicore/patterns/facade/Facade.as
     113 ./org/puremvc/as3/multicore/patterns/mediator/Mediator.as
     127 ./org/puremvc/as3/multicore/patterns/observer/Notification.as
      99 ./org/puremvc/as3/multicore/patterns/observer/Notifier.as
     113 ./org/puremvc/as3/multicore/patterns/observer/Observer.as
      86 ./org/puremvc/as3/multicore/patterns/proxy/Proxy.as
    2498 total

I wonder what the corresponding statistic is for robotlegs. Size matters when you want to read and understand the framework code.
----Philip

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: December 09, 2013, 07:50:47 »

Regarding simplicity, PureMVC is a tiny handful of patterns, but every app you write will use those patterns over and over. All your programs will essentially look the same. This makes it easy to bring developers up to speed on 'how things are done', and there are plenty of folks out there who already know.

With DI (again, not talking about RL, only DI in general), you're not encouraged or required to use patterns other than injection. This means on a large team, people often do the same things in many different ways. That leads to programs that are difficult to understand, debug, and evolve. If everyone is using the same handful of patterns to get things done, then it's much easier to follow.
Logged
naghekyan
Newbie
*
Posts: 3


View Profile Email
« Reply #6 on: December 11, 2013, 12:31:24 »

Now I got what you mean :). Thanks a lot! But with DI you are much free and flexible. And the argument what you mentioned regarding to not encouraging patterns is the price we pay for "buying" that freedom. Are you agree?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: December 11, 2013, 07:23:21 »

Absolutely. Freedom can easily become anarchy in a large app with many devs. Having specific ways of doing things keeps everyone on the same page. Sometimes you think you're oppressed and having your freedom taken away, but then without the framework and the patterns, you find you have to solve so many mundane patterns and make so much spaghetti while you do it, that freedom turned out not to be so great after all.
Logged
piotrzarzycki
Jr. Member
**
Posts: 11


View Profile WWW Email
« Reply #8 on: January 06, 2014, 04:49:24 »

Hi naghekyan.

Have you checked also https://code.google.com/p/fabrication/ utility witch is add many intresting features to PureMVC.

Piotr
Logged
turtlebite
Newbie
*
Posts: 7


View Profile Email
« Reply #9 on: January 27, 2014, 12:03:31 »

For me, portability is the strongest reason. When I evaluated frameworks in 2011, I was almost going with Robotlegs. But I finally decided to take PureMVC because if it's portability. Back then I was developing in Actionscript only. But by now I've built websites using PureMVC for PHP, and also JavaScript. I've just finished my first app in Java, and I have to say that in all those languages I immediatly felt at home with PureMVC. It is just a rock solid microframework that never stands in your way and I'm looking forward to try it with Haxe, Typoscript and even Python. :-)
Logged
Pages: [1]
Print