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]
Author Topic: Architectural frameworks worth it?  (Read 10608 times)
Courseware Beta
Posts: 3

View Profile Email
« on: December 31, 2007, 08:27:49 »

I've just begun refactoring our Flex project to use PureMVC, and I've been happy with improved clarity of the code. However, I just read a blog suggesting that architectural frameworks aren't worth the costs of implementing them. I'd be interested in hearing rebuttals of the arguments posted at the following URL:

Joel Hooks
Courseware Beta
Sr. Member
Posts: 146

baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #1 on: December 31, 2007, 09:46:57 »

I think Yakov misses the point of PureMVC, as it is not a framework on top of flex. It is an AS3 framework that can coincide nicely with Flex, Flash, or any other AS3 platform.

I also think that somebody with decades of software architecture experience might look at a framework and say, 'Meh, I like to do it this way...'.

In my case, having a framework from which to base my design off of is a boon. I learn more about the patterns that come into play and can start constructing meaningful software. That said, I am a big proponent of learning a language WITHOUT the crutch of a framework. When I was starting to learn AS3, I specifically avoided flex for this very reason. Sure, Flex provides a lot of nice components, but I felt like it would take away from my overall learning experience and shield me from what was actually going on.

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #2 on: December 31, 2007, 09:56:45 »

Opinions vary wildly on this point. So, since you ask here, I'll give you my two cents.

I came to the framework game honestly. I'd already spent nearly 20 years programming by the seat of my pants. I started professionally in machine language, (that's right later it was a joy to have an assembler!). I was poking endless hex numbers into memory locations and loving it!

Many years later at the end of a long chunk (nearly 10 years worth) of mostly Perl work, found myself in a large company that was sinking because the huge krufty pile of Perl that we called our 'Enterprise' was failing to bill a huge amount of our customers and our massive database was riddled with integrity problems because nothing was planned. Our Enterprise had not so much been designed as it had accreted like a coral reef.

So the powers that be foisted Java on us. 'We're moving to a new paradigm,' they crowed. Meanwhile I (not-so) silently forked the sign of the evil eye at them and this new monster they were building. But it wasn't long before it became apparent that they would hang on to the Perl slingers long enough to prop up the aging garbage pile until the gleaming new machine was built and then they'd axe us. So when they came and asked be to join the Java team, I grudgingly went.

We were fortunate enough to have an insanely sharp contractor come in, lay down the infrastructure, all pattern-based, and he took the time to explain it to us. It was hard going and I complained every step of the way, but eventually it began to sink in and I realized by the time all was said and done, that I'd been missing out for a long time. Suddenly I had a much clearer picture of what I was doing, and could articulate it to others and expect them to understand right away when I mentioned the use of a Facade, or google until they did.

After learning to think about software in patterns, and doing several years of hands on J2EE work, I found Flex. I started dabbling, recreating a small but nontrivial app that I often use to learn a new language. Being on the client side was a little bit of a disadvantage at first as  I was used to server side patterns and didn't know what was really applicable. So I just started hacking away. Of course I used everything I've learned over the years prior to learning about patterns in order to keep it simple and clean, and good stuff was happening right away, to be sure. But before long I realized that the classic issue in an OOP system of how to wire things up and pass data around without making a mess was as prevalent here as anywhere. I never did finish that app. It became unmanagable spaghetti code despite my best efforts, and when Flex 1.5 came out, I never carried it forward. By that time, I'd had the good fortune to find Cairngorm, and never looked back.

Some frameworks are more pain than they're worth. EJB 2.0 for instance made you define 5 separate classes for every entity object. That was a bit much to cope with, and I can certainly agree with those who say using that particular framework is more trouble than it is worth.

But to accept or make a blanket statement such as 'Frameworks are more trouble to implement than they're worth' is to do yourself and others a disservice. Its all about where you are on the curve. If you'd told me that back when I was trying to wrap my head around Java, J2EE, EJB, and JBOSS all at once (against my will!!!!) for instance, I'd probably have socked you in the eye if it was a particularly bad day.

There is a quite good post on this topic by Steven Webster, coauthor of the Cairngorm framework here: http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.cfm

Although I don't agree that if you're the only one who'll ever look at the code, there's no need to use a framework. I think the decision is governed purely by the potential complexity of the app.

Steven seems to advocate rolling up the sleeves without a framework first as well. Clearly, it's better to make a big mess by hand first. This helps you to know just exactly what it is you're avoiding when you use a framework.

As a point of professional responsibility, though, I would suggest making that mess on one's own dime and not that of a customer.

« Last Edit: December 31, 2007, 10:01:22 by puremvc » Logged
Courseware Beta
Sr. Member
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #3 on: December 31, 2007, 01:35:15 »

It seems to me that a lot of the discussion was based on frustrations with Cairngorm, Yakov in particular. I think a more important thing to consider is does a particular framework (if one at all) increase developer efficiency by doing things such as decreasing the amount of refactoring that must be done for minor changes/additions.

The problem I have with framework-less application design is as Cliff mentions it all becomes spaghetti code. Even though in the article they advocate separating code into "model", "view", etc folders, it's really a case of taking one big plate of spaghetti and dividing it up. There will still likely be too much interdependence between components.

As great as Flex is, in essence its an ActionScript wrapper for Flash. It divides things up into either MXML, AS3, or a mix of the two. As far as I can see it gives us some nice UI elements and some nice data interaction objects (RemoteObject, HTTPService, etc.). I consider Flex to be more of an API than an application framework, thus the need for a third party one.

Pages: [1]