Filed Under (AIR, ActionScript, Flex, RIA) by jonr on October-15-2008

You know you had a good idea when you see someone else implement it, and they do it better than you may have yourself.  Brian Lesser posted an article this week on O’Reilly titled, “MVC As Anti-Pattern.”  I have been meaning to write a similar article for a while.  Internally at Gorilla Logic, Stu Stern and I have had a long running dialog questioning the wisdom of bringing in full blown MVC frameworks into Flex (especially model 2 like implementations with a front controller).

Brian Lesser does a good job of arguing against implementing the traditional MVC pattern within Flex applications.  Lesser outlines the language/framework features in Flex that are far different than the language MVC grew out of many years back (i.e. Smalltalk), including discussing data binding and event listeners in Flex.  In addition to his main points, I am still a little awestruck at the willingness of developers to drag in a framework that quadruples or more the amount of code without adding much clear value.

Obviously, architecture is important and Lesser does spend some time discussing what the layers look like within Rich Client applications.  I am still digesting this section, but my initial reaction is that his ideas fit well with how I view application architecture in context of RIA’s (hard to go wrong when you borrow from Eric Evans).  It really is an exciting time as the move to rich client runtimes not only allows us to build better applications for end users, but forces us to think differently about the architecture.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • DZone
  • Digg
  • del.icio.us
  • Reddit
  • Facebook
  • LinkedIn

Comments:
Curtis Rose on October 15th, 2008 at 8:34 pm #

I totally agree with the idea of simplifying applications. I’ve heard Ken Orr often say that ‘complexity doesn’t scale’ and even though he means it in a broader sense, I think it also applies to the amount of code it takes to write applications. Simpler is better, and more maintainable, and cheaper to own over the long haul.

Ryan on November 4th, 2008 at 10:25 pm #

The fundamental problem with not using MVC and simplifying your code is that it reduces the amount of work we get to do as consultants. Long live MVC and bloated software! The truth is high quality and simplistic software is what sets good software consultants apart.

Mike on November 21st, 2008 at 9:24 pm #

I berated our industry over the same thing. http://blog.bigfatstogie.com/?p=34

Essentially as I’ve come to see it in the last 10 years or so, patterns as a whole are like training wheels; when you first start working on serious enterprise-level products it’s over whelming at first to the newly minted CSE. After a number of years / projects / life-cycles, we begin to see that a particular problem domain or capability set can benefit from a particular implementation of a pattern, but not as much to try to shove it in a preformed box of a framework that makes up a particular pattern (we all use adapter / factory / delegate etc,: but not as much to go about and attempt to make our project structure fit some Adapter-be-all). This is where I think carigorm is utterly ridiculous (besides it’s goofy enough to pronounce).

[...] have been rebelling against dragging additional frameworks into Flex just for MVC for a while now (Flex and MVC /  Cairngorm).  I finally got a chance to spend some time coding with Mate on a flight back from [...]

[...] I just finished a write up for InfoQ on the Flight Framework. Flight compares themselves to Cairngorm, without all the “boiler-plate” code.  The association with Cairngorm is a turn off for me to seriously consider using Flight, as I still don’t understand what value Cairngorm provides (old post 1 & 2).  That doesn’t mean I don’t believe that Flight may have value, but in learning about the framework there seem to be the typical assumption that everyone is out there looking for the perfect MVC solution (old post 3). [...]

Post a comment
Name: 
Email: 
URL: 
Comments: