It’s common for a developer who has an architectural vision, someone who sees application development from beginning to end, to dislike MVC frameworks. In fact these frameworks are most valuable when keeping less experienced developers from coding themselves into a corner. A framework can be important in team development when the architectural vision needs to be shared, it provides a standard for each member to adhere to.

Flight attempts to offer a logical standard for application development, then gets out of your way and lets you do your job.

Some time ago the name was changed from FlightMVC to Flight Framework because doesn’t prescribe the bloat of a complex presentation framework. Because of high demand (and because I’m told that we’re not complete without it) Flight will likely offer an IoC presentation workflow (completely optional) that will allow a really nice separation of the view from the world. Even then Flight will continue to prescribe taking the minimal path: don’t add the headache when you don’t need it.

Please excuse the lack of documentation & examples, they’re coming soon enough. I hope these 2 cents are a helpful contribution to this discussion.

I’ve tried to implement a few and I found I lose the ability to see what I’m doing clearly. Granted, spaghetti code doesn’t make a good product, but using MVC certainly doesn’t guarantee a good product.

It came down to this. I keep making flex components separate when they are their own piece. Over-separating files and you end up with 12 views you don’t know where to look at. Sure the code is less than 50 lines each but it takes 2 aspirin to find the exact piece.

What I do however is try to use the Presenter Model ( http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_3.html ). That is, keeping the view wired to the model (which you really want to enjoy the power of {bindedStuff}), while the Model doesn’t know about the View.

That has helped a lot the spaghetti and made it into a nice lasagna.

Jokes apart, it’s not easy. Whichever way you pick there are drawbacks. More files doesn’t mean more happy. However, if something such as ’saving to disk’ is not a stand alone class, you’re really doing throw-away code.

Happy to discuss this further, because I’m yet to find the silver bullet.

Cheers.

Secondly, an MVC pattern that’s decently implemented for a technology (i.e. Flex) should provide a paradigm that guides the architecture of a fully scalable application. In other words, there are many ways to accomplish one thing, typically ranging on the continuum of “quick and easy but doesn’t scale” to “more involved but scales better”. I would think a good framework provides a balance and a bridge between those ends, guiding the developer into a reasonably scalable pattern that facilitates rapid development.

I always approach a project as if it would be scaled to the n-th degree, because if you just try to “bang it out” and cut corners, inevitably you’ll regret it. I’ve gotten used to implementing an MVC out of the gate so I don’t even have to think or worry about where the project might go.

There are other design patterns I prefer for UI work–the command pattern works well and is easy to understand, especially if the command-passing structure is easy to see in code. I’m mystified by the Model II design embodied in struts, but I really like the clearer model-whose-name-I-don’t-know behind Java Server Faces.

What’s so great about MVC? If used rigorously, it makes it relatively easy (compared to other technologies I’ve used) to manage a large, complex, live UI gracefully, and to build new components by extending old ones. I can attest to that, having done so in SmallTalk. I can imagine why it hasn’t grabbed you in Java, though–because I’ve seldom seen it used there–just other “sort-of” MVC-like things which give away the main strengths of MVC as originally conceived.

By the way: it occurs to me that with Flex, it might be possible to implement a real MVC-based system… which gives me something to think about. So thanks.

My new job involves AS2 and no MVC framework of any kind.

All I have to say, is wow, it…is… *refreshing*. Each screen of the UI is 1 page of functions. The code is easy to digest. It’s straightforward to hammer out a page and productivity is way up.

There’s something to be said about imposing limitations on your art – within confines, your creativity becomes focused.

http://www.37signals.com/svn/posts/1560-axl-vs-frank-more-time-doesnt-mean-a-better-product

Something I’ve enjoyed about Swiz is that it gets back to basics with straight-up Controller classes.