When all you have is 3 hammers (called Gateways, Beans and DAOs)

Kola, I can't seem to grasp whether this is being critical of my gateway discussion or not (it comes off as critical but I am not sure it was intended too). Anyway, I was trying to understand where the ColdFusion implementation of the gateway pattern cam from, and it isn't Fowler's book (which was part of the point).

Notice that it led to a discussion of other people's patterns. Some use a gateway, others don't. Some, like Peter Bell, use a active-record-ish pattern (his IBO has similarities to active record for sure). Others seem to mention they are doing the same (I know Paul Marcotte and Sammy Larbi are two who don't use the standard DAO/Gateway implementation). The whole point was to look at the origin of the pattern in CF as it relates to its brethren in Java (and the pluses and minuses to the pattern itself)...to me it would seem like the kind of post that negates your complaint, not promotes it.

Still, I think your characterization isn't entirely correct. There are a number of people talking about design patterns. Its just not for the noob...and most CFers (and most of the articles are geared towards) OO noobs. I don't (and I don't think you would) tell someone to learn OO by reading Patterns in Enterprise Architecture. However, it is this very kind of criticism that, to me, breeds fear of learning OO in the CF community and thus why I think sometimes these posts are often counterproductive even if they have a legitimate point...no one wants to get called out by the OO police when they are simply trying to learn.

Brian links to the Longacre blog's coverage of data gateway patterns and I think this quote is particular relevant here:

"The key distinction between table data gateway and a Row Data Gateway is that a table gateway encapsulates the entire data structure behind a single object or class, while a row gateway encapsulates a single entry behind one instance of the gateway object. When the application is dealing with only one object at a time, the two are very similar. However where a row data gateway may use a separate Finder class or method, a table data gateway will provide the lookup method itself."

When we use 'DAO' and 'Gateway' in the ColdFusion world, we are a lot closer to the "Row Data Gateway" and "Finder Class" position. I'm not quite sure where our current usage originated but one of the problems we seem to face as a community is that when an example is held out to illustrate an approach, many CFers take it as _the_ way to solve that problem.

I'm working on an architectural proposal for one client and also just did some mentoring for another client - both cover the same sort of issues with tiered application design. I found myself advocating _against_ having the "standard" five CFCs for each object (bean, DAO, gateway, manager, controller). This seems to be increasingly common practice in the OO CF world and I'm very concerned about it. IMO, controllers should be partitioned according to application concepts (or sections), managers should be partitioned according to the related groups of objects they orchestrate and so should gateways (aka finder classes per the above). I personally use Transfer for my per-object data layer so Transfer itself acts as my DAO and it manages my beans. Only the beans themselves have a unique blueprint per object (and even those are created on the fly by Transfer).

So in an application that has 20-30 beans (which I might need decorator CFCs for with Transfer), I might have around a dozen finder classes, 5-10 manager classes and 3-6 controllers. That's 28-46 CFCs + Transfer compared to 100-150 CFCs which the "5:1" process creates.

I agree with Simon Horwith on some of these basic design pattern issues that objects are supposed to be smart. That's what Object Think is all about. Responsibility-Driven Design. Not Data-Driven Design (which is the 5:1 approach).

...and I should have mentioned that I completely agree with you about the lack of understanding of the forces and trade offs involved in selection of patterns. A given pattern is a solution to certain problems in certain situations - not merely a template to be used to build your application. Folks should read Joshua Kerievsky's "Refactoring to Patterns" book (as well as the original "Gang of Four" book) for real world examples of when - and how - to use various patterns.

I've had a number of blog postings and articles about other (much more interesting) patterns than DAO and Gateway. These include the State pattern and the Strategy pattern, among others. Have a look if you like:

http://www.briankotek.com/blog/index.cfm?mode=cat&catid=E3B11FA8-3048-23C1- DDADAFDD4093690F

I know what you mean, Kola. I've all but dropped out of CFC-Dev because I'm sick of the patterns talk.

It seems that as people learn OO they tend to go through two phases. The first is "model everything on real world objects." When that falls flat, they move on to design patterns, and overcomplicate designs by forcing them to fit whatever set of patterns they know best.

I'm not sure what the third phase is, if there is one, but I've given up on learning OO directly. Instead, I'm striving to better understand the fundamentals, such as separation-of-concerns and DRY. I figure if I truly grok the low level principles, I'll be able to pick up new patterns with ease and know when to use which one. Also, principles are portable -- they tend to apply across all languages and paradigms.

You have right in some point. Instead of understanding concepts, appliying techniques without knowing what really means is a common situation specially in our "lazy" CF community. Hal Helms did a great explanation on this at CFUnited by explaining real object idea and pseudo OO stuff.

The fashion is also another important point. When Sean said "We are using ModelGlue instead of MachII at Adobe", Model-Glue became popular in a short time. Or same thing for Transfer. How many of MG or Transfer users did really understand what is really behind of it. Or are they just using because Sean suggested it? :)

Of course pragmatism is an important point. Use a solution which solves your problems. But meantime be clever also to get a "better" solution which would be important in your future efficiency.

"I agree with Simon Horwith on some of these basic design pattern issues that objects are supposed to be smart. That's what Object Think is all about. Responsibility-Driven Design." - Sean Corfield 7/25/07

After hearing the tension at cfObjective 2006, I'm amused to see that :)

In any case, I agree strongly with Kola here. I've recently applied the Decorator, Strategy, State, and Iterator patterns to some of my applications with a resounding success. I'm using Peter Bell's IBO (I call it an Iterating Entity Bean though), and I occasionally use a Flyweight pattern with the occasional Gateway, but I've found that using the right pattern for the right job makes OO a lot easier than trying to shoehorn everything into a Gateway, DAO and Bean model.

Hey Brian, I wasn't being critical of your blog post at all - in fact the only reason I mentioned your blog post was because it prompted me to write on something which I have been meaning to discuss for a while thats all. Nor am I trying to be counter productive or put anyone off learning OO. I am certainly no guru and can always learn more - but I do think the way many people in CF are being introduced to OO can be a slippery slope. Especially if they are using certain design patterns because thats the 'way everyone else does it' and without spending time reading the actual definition and intent of a design pattern. I agree that POEA isn't the first book I would give to someone but that said its no more advanced than the design patterns book in my opinion

Kola, No problem, like I said I didn't think that was the intent. I am glad my gateway discussion has sparked a worthy discussion. In fact, it kind of follows I guess since I was actually trying to look into the *intent* of the gateway rather than its function (as in what problem is it actually solving). I think Sean had a point when he said we need to get some CF specific discussion and examples on the topic of alternative patterns to the DAO and Gateway; so let's get the material out there to assist CF developers to delve further into design patterns. To me, a big help was a book called "The Object-Oriented Design Process" (I think that is what it was called anyway) which got to the key of thinking about your domain model in abstract terms and got away from the tendency to think about data and code first.

In fact, I continually warn people about using tools like my own generator to learn OO because it can lead to the wrong way to look at the problem since it goes at a 1 table=1 domain object=5 CFCs mentality. I don't even code that way...I copy and paste some parts into combined services and gateways that deal with logical portions of my application (similar sounding to what sean describes on his post).

One last point, for Oğuz, I think Model-Glue and Transfer have gained popularity on their merits. Personally, I use Mach ii, but Model Glue is a very good framework and deserving of the attention. There may be people who use something just because Sean says so, and as silly as that may be, I haven't seen Sean recommend anything lightly so it really isn't all bad anyway.

@Brian, may be I pointed out different than what I targetted. Think that we have ColdBox for a long time and it is a great solution but when I compare the first phases of MG and ColdBox, I can definitely see "the Sean factor" just to try anything new. :)

I am very happy that we have Sean and he suggests the best for the community. There is nothing wrong with this. I just wanted to try to show that there is a community who just "believe" instead of understanding.

I get tons of questions from our customers about framework selection or OO techniques. What I suggest them is always to try and see the results and decide depending on their needs. But I know also that most of them just decide when I say go with XX without any research. "It depends" is not enough answer for some "clever" developers. :)

@Oguz, I'm not sure whether to be flattered that you think I have so much influence or offended that you seem to be accusing me of trying to suppress ColdBox because I haven't written much about it?

ColdBox seems to be getting a lot of attention without me "helping it along" which is what you seem to think I've done with Model-Glue and Transfer...

By the way, I did *NOT* say that "we" were using Model-Glue instead of Mach II at Adobe. You need to check your facts before making such remarks. adobe.com - formerly macromedia.com - has a lot of Mach II applications and *no* Model-Glue applications. I blogged that I switched *one* internal project from Mach II to Model-Glue (a project that was canned as part of the acquisition). Kuler uses Model-Glue behind the scenes - I did not write that (but I did consult some on it).

@Sean: First of all I very appreciate what you provide to the CF community. I don't say anything about it and there is also no doubt about the importance of your great community support.

I am just trying to show the factors which effects community decisions easily such as your articles like "Mach II Out, Model-Glue In!".

http://corfield.org/blog/index.cfm/do/blog.entry/entry/Mach_II_Out_ModelGlu e_In

After having these kind of entries in your blog, think what happened? :)

When we remember of the reason of this thread, I just want to say that as you have already mentioned, let us try to decide with knowledge, not with beliefs. Let us try to understand more by reading more OOP books, articles, blogs etc. etc. before deciding a way which would be helpful for our future efficiency.

By the way, I also really wonder what you think about ColdBox. :)

@Oguz, I really don't think you've read that article properly. Please read it again, especially the various comments. There are plenty of specifics in there that explain why one framework might be better than another in certain situations.

Right now I'm designing a system that will be built with Mach II 1.5, I'm building my startup's website with Fusebox and I'm building another website with Model-Glue.

Are you saying I don't provide knowledge? That I try to sway people with "beliefs"? That's rather insulting.

As for ColdBox - given that you don't seem to want me to "effect community decisions", why would you even care what I think about ColdBox? Comments like yours make me want to keep my thoughts on ColdBox to myself - if I praise it you'll accuse me of trying to influence people and if I criticize it you'll want me to justify every single complaint. I can't win for losing with people like you.

Your attitude makes me want to give up blogging altogether and leave the ColdFusion community completely.

@Sean,

I don't think Oğuz was implying that you try to sway at all.

I believe what he is saying is that you've garnered a great deal of respect from the ColdFusion community both as a result of the positions you've held related to ColdFusion and as a result of your well reasoned commentary and obvious experience.

This has apparently, in some eyes, resulted in an unintended elevation of you as a contributor, and given your perspective a significant weight in the ColdFusion community.

I don't think Oğuz is saying you're 'trying' to do anything. I believe he's saying you do influence, albeit unintentionally.

Guys, I see all of your points. Fact is, many developers without formal training read our blogs to gain the experience and knowledge of those who know more than they do. Discussions, such as this one, are great for pointing out that there is "more out there" to learn and grow from.

@Sean, don't quit. Many look to you as an extremely intelligent, well spoken, and passionate CF developer, with huge levels of software development experience. As @Brian, and others here, have said, it's a matter of examples available. And it comes down to what readers see the most, not just on your blog but every blog. The CF community would be at a serious loss if you chose to stop.

Over the past two plus years I have seen hundreds of posts dealing with these Table Data/Row Data Gateway Patterns, and couldn't speak with any knowledge about Observer or Strategy Patterns. Why? I haven't read the same books. I'm just a self-taught kinda guy. Sure, I've been doing CF for the past seven years, but I've run an IT dept for two companies at the same time (at 60+ hours a week), gotten married, had a daughter, switched jobs again... So, when I decided that frameworks weren't an evil thing after all, I went to those who knew more than I did. When I wanted to learn more about OO/MVC style development, I went to those who knew more than I did.

Back when CF 6.1 came out I was taking a few classes on programming. I read about CFCs and thought "Dude! You can do OO with CF!" and stopped hounding my boss about .NET. But it took years (like 5 maybe) before I saw anyone online really talking about OO dev with CF. Not to say you guys, and others, weren't doing it, but us untrained spaghetti coding neophytes were just scratching the surface.

Don't give up on the ignorant, just help to educate them. Matt, Peter, and Chris have the LitePost project sitting undocumented in GoogleCode, and it is a fantastic small example application, from which people can learn just reading the code. That's what our community needs, solid CF OO examples to learn from. I want to help, but I still have some catching up to do.

So, I think I'll go get "Head First Design Patterns" and try to figure out some of what you guys have been talking about. You have all sparked my curiosity, and I'm anxious to find out how I can approach some issues differently.

@Sean: How can we come this point I really do not know. What I said is that what you do is the great and beneficial for the CF community. What I am complaining about is the community behavior and regardless of what you provide they "believe in it" and give decisions without thinking about it or trying it to decide about it.

This entry also mentioned same thing about design pattern. What I understand is Kola tries to give another perspective as there are some other patterns beside design pattern and CF community must also care about them. Just instead of "agreeing/believing" design patters because they are "served" the community as a solution. I gave frameworks as an example for this kind of unhealthy decisions. Just that.

Of course you know you have a great respect from community and I am totally sure that you are always careful about what you provide and I am one of the biggest fan of your entries and I check your blog everyday more than once since early blog times. :)