Overthinking Your Framework is a Stalling Tactic

Ok. I am going to go ahead and dive into a topic I often feel gets beaten to death, but which inevitably comes up almost weekly, if not more frequently. This time, it is time for some tough love! If you are sitting back studying frameworks, researching options, reading blogs and looking for the answer about what framework you need to just admit to yourself you are just stalling (go ahead, flame on)!Here is a common story: someone posts to a list I am a member of saying how everyone seems to be telling him and other procedural developers that they need to use a framework, but there are so many options and so many recommendations that it is causing them to think it isn't worth the trouble - that once they choose one, a new and better one with all new features comes along and they will need to keep upgrading their application to keep up with frameworks. In this case they are using frameworks generally to describe things like Mach II, Transfer, Model-Glue, ColdSpring, etc.

Not using a framework and sticking to procedural code has none of this overhead. That until there is some consensus of which framework is the standard, they feel like it is almost not worth choosing one.

However, people keep telling him that the only way to really know which one is best is to build an application in each and compare their relative merits.

Here is my response:

Personally, I dislike the advice of building sample apps with each Framework. It is confusing and difficult if you are new to a frameworks and OO and it is time consuming. Therefore completely unrealistic unless you have lots of spare time.

Usually this is the point in the conversation where I tell people to take a step back, take a deep breath and relax. This is not the Holy Grail we are talking about here. Choosing a framework is not a life altering decision people!

The first thing to understand is that you are confusing differing types of "frameworks" and putting them under the same umbrella. You have MVC (i.e. Model-View-Controller) frameworks like Mach II, Model-Glue and Fusebox to name three. Then you have ORM (i.e. object relational mapping) frameworks like Transfer or Reactor. You also have inversion of control/dependency injection (IOC/DI)frameworks like ColdSpring or Peter Bell's LightWire. These differing types of frameworks achieve very different ends (although they can all work together).

Usually when people use the generic framework term they intend to refer to MVC frameworks. I am not sure what "features" any standard MVC framework would not take advantage of - there are still people who choose to use Fusebox 3 or 4.1 for example (or Model-Glue 1.1 even though 2 is the most talked about). To me, just the idea that someone has convinced you that there are "features" they can't use means the concept has been fundamentally confused in their explanation.

You see, the controller in an MVC application is really just concerned with shuttling data between your View (in this case HTML - sometimes with some Ajax) and your Model (i.e. the components that run your application, handle persistence and contain your business logic). A good framework will offer additional tools for common tasks, but the core of its intent remains the same and don't require any new features.

Note: Standard MVC frameworks like Mach II, Model Glue and Fusebox are typically not considered relevant when discussing an application built entirely with Flex.

So, let's say you choose to use Mach II today. If you design your application properly there is no reason why you can't 1) port that application fairly easily to another MVC framework should you decide to change your mind or 2) use a different framework for future applications. So, in general this is a matter of making a mountain out of a molehill. The big decision you need to make is that you *will use* a framework, which one is secondary.

Finally, it is my personal recommendation that you leave things like ORM, IOC/DI and AOP (aspect oriented programming) alone until you feel comfortable using MVC and object oriented programming (OO). Only then should you build your OO MVC ORM IOC DI AOP app ;)

None of this is intended as criticism. I know where you are because I have been there. Nonetheless, this stressing over which framework to use is a stalling technique plain and simple. It is brought about by the fact that moving from procedural to OO is painful and difficult. Once you accept that, just bite the bullet, pick a framework (any framework) and get coding!

Actually sounds like extremely reasonable advice - nice posting!

A great post. This should hopefully wake up a lot of people who are still finding themselves in this loophole. I loved the last bit though the most. Talk about driving a noob nuts! They'll be pulling their hair out for weeks!

"Only then should you build your OO MVC ORM IOC DI AOP app"

I agree completely!

I'm currently working on my first Mach-II application. The code is a mess, I JUST figured out WTF a bean is and when I'm done I'll be embarrassed to claim ownership but I'm learning and my next application - whatever it may be - Mach-II or Model Glue - will be better...

Sounds like an extended version of the talk we had Brian. You don't like me enough to give me the long version? :D

I have been going over the exact same thing...sitting here researching, reading blog after blog, trying to figure out which framework I want to use. I finally just said, "Why am I wasting my time on all this research". It seems everyone has the same advice, try one and see if you like it.

I tried fusebox, and by building my authentication piece of my application, i realized i wanted to be forced into MVC and gave model-glue and now thats what I am using as a noob to the framework world.

I wish I had just been told (and realized) I need to pick one based on my goals and just move forward, sink or swim!

AFAIK, M2, FB & MG R 4 HTML & CFM. AJAX OK 2.
TO'S, BO'S & DAO'S HELP W/ CRUD.
IMO, ORM(E.G., REACTOR) & DI (E.G., CS) R GR8.
FWIW, OOP W/ CFC'S <> JAVA.
ECLIPSE + CFE IS 4 CFC, CFM, JS, CSS XML, ETC., BUT != WYSIWYG.
HTH.

I don't know whats worse Matt - the fact that you took the time to write that or the fact that I read and understand it.

LOL @ Matt.

BTW, the advice in the post is spot on too. Just jump in. I started with Model Glue after reading Ray's expose/photo gallery example.

Not sure what the other framework author's do, but I'm sure they've got samples too.

Directly comparing how frameworks work is tricky. The CFPetMarket site may assist with the comparissons of framework implementations, but it's hard for someone new to frameworks to know if the projects on the cfpetmarket site are 'good' or 'poor' implementations.

So, jump in and have a go with your own data and business processes.

Good advice. I decided that I needed to learn what frameworks were all about, picked one that had quite a lot of buzz about it at the time and just plunged in. I will eventually learn other frameworks. The point is to just get started and let the chips fall where it may. Just don't start with a time-critical project if this is for billable work.

thanks Brian
excellent advice...

Hey Brian. I was going to reply to this inline, but the reply got really long and I ended up writing my own blog entry on the subject.

http://ontap.riaforge.org/blog/index.cfm/2008/5/2/Indecisive

The thumbnail synopsis is that you're right, it is stalling. But the indecisiveness over frameworks runs a lot deeper than the learning curve.