Objects and Frameworks - Getting Started

So you read my last blog post and perhaps you are saying to yourself, "ok, I'll give the whole objects and frameworks thing a shot." Maybe you know enough to know that you will need to start creating components modeled as beans, DAO's and Gateways. This seems like a lot of extra work compared to my 1 request 1 template coding (or maybe 1 template a 1 cfc with my queries). Suddenly you remember a project called Reactor that took care of most of that drudgery for you...oh, and you read many articles recently about a new version of Model-Glue (Unity) that used Reactor (and ColdSpring) to generate your list and form pages for you using scaffolding. Perhaps, you have even watched Joe Rhinehart's blog in 9 minutes presentation. This won't be so hard after all right? My advice to you would be to slow down.Think of it this way: how do you evaluate a shortcut to someplace you have never been? The answer is that you cannot because you have nothing to judge its value against. Without placing any judgement on the tools themselves, I would say the same goes for projects like Model-Glue, Reactor and others that offer some powerful shortcuts in developing object-oriented applications. It is my personal experience that rushing down this path is a road to deeper frustration. Let me explain why.

For example, let's look at scaffolding. While the idea of having Model-Glue generate some generic view code may have value, I cannot foresee what kind of application you could build that wouldn't require you to modify these scaffolds quite a bit. Yes, Model-Glue allows you to do this, but doing so suddenly requires an understanding of what is going on behind the scenes that you aren't likely to have yet. This is not a criticism of Model-Glue, but personally I am not a fan of scaffolds; an opinion I can only base this upon the experience I have gained. This is another important point: if you are new to objects and frameworks, you probably do not have a good basis for evaluating whether scaffolding is a good idea or not for your purposes.

Next, let's look at Reactor a bit (again, not picking on the tool). Reactor is an object relation mapping (ORM) framework that uses an "active-record"-like pattern in its objects. Perhaps you are wondering what an ORM or an active-record pattern is? Or maybe you read about active record when Rails was the darling of the moment but you are wondering if it is this a good or bad idea? Well, I don't have an answer for you because this is a matter of opinion no matter how strongly people feel on one side or another. You will need to, and be able to, figure this out on your own with a little more experience.

So now you may not be thrilled with me because I am telling you to avoid all the ways that made you feel more comfortable about this transition. Sorry :( However, I say these things out of personal experience. This advice is based upon mistakes that I made that I wish I hadn't. So, what should you do then?

My opinion is to learn a bit about what beans, DAOs and gateways are, and then pick a small project and try to implement those concepts doing the coding by hand. There is more to it than beans, DAO's and Gateways (like the MVC pattern, service layer, transfer objects, facades, etc), but this is a good place to start. Your first attempt will likely be procedural code wearing an OO hat, but that is ok in my opinion because you are working your way towards understanding some of the underlying concepts. Plus, if you remember the biggest point of my last post was that it's ok to get it wrong...it's part of the process (and a part I am very well versed on ;).

In my next post on this topic, I will try to cover some resources you can use to learn about some of the concepts I glossed over here.

I agree!

I never recommend jumping, but slowly transitioning apps. As you go through the process, you learn a lot.

Well said.

I am exactly the kind of person you're writing this article for :) I apprecaite your thoughts and believe it or not, I had felt the same thing. Is there a good reference you can reccommend to get started learning this stuff?

Thanks for these great articles, which are a reference unto themselves.

Dittos. You are talking to me, Brian. Looking forward to your continued posts on this...

Just when I was starting to use cfc's at all, I listened to the CF Weekley Design Safarri podcast and have been head deep in reading articles, blog posts, posting on the CFC Dev list, and contacting Sean Cornfield, Ray Camden and skyping Peter and Matt trying to figure out OO. I have been tearing apart some of Peter's 00 examples (00P for Noobz and PersonAddressService), hoping to find the "Roseta Stone" you talked about in your previous post.

In my current application, I have begun to create gateways, with the idea that I will eventually use DAO's and beans when I build the back-end.

I watched Joe's presentation on Model-Glue:Unity from the Adobe Developer's Week and thought, "Maybe this is the 'Roseta Stone' I have been looking for." However, all of my OO persuits came to a quick end last week.

The director and the cheif operations officer came into my office and asked me why some things weren't being addressed on the website. I tried to explain that I was taking some time to write better code, but they said they don't really care. "If it works, who cares what the code looks like?" I could have tried to defend my cause, explaining the benefits of maintaining a modular code base, but they could care less.