This cropped up on the TDD mailing list and it made me smile so I wanted to share it along with some commentary. A fairly common request from folks in the CF community is for "static" methods (and data members) to be added to CFML. Folks look at Java, think it's a cool concept, and want it in CFML as well. I generally pop up and say it's a bad idea and that Java only has static because it doesn't have any concept of a global application scope (which CFML does, of course).

[More]

Over the last few days I've been working on a new MVC application framework for ColdFusion. It's very lightweight and completely convention-based. Beyond this introduction, I won't be blogging about it here but you can read all about about on the project blog over at Framework One's RIAForge website.

That's where you'll also find the forums, wiki, source code repository and bug tracker. The blog also has a link to the new mailing list if you'd rather use that instead of the forums.

What is FW/1? Read the RIAForge project description and introductory blog post there.

Why create FW/1? Again, read the project blog on RIAForge!

Marc Funaro kicked off quite a heated debate on his blog lately by raging against people pushing object-oriented programing/design and how his attempt to follow their advice nearly led to the collapse of his business. Marc was expressing a common frustration that many of us have heard from people who try to learn OO, especially from people with a long history of procedural programming and/or no computer science background.

I've left comments on a few of the blog posts but several people have asked me to go into a bit more depth about my thoughts on this issue (since I'm one of the people sometimes accused of "pushing" OO and insisting it's the "right" way to do things).

[More]

In the absence of a printable schedule - sorry, Joe Rinehart says it's a problem with the Media3 hosting and he's been trying to get them to fix it for months! - here is my schedule for cf.Objective() 2009:

[More]

Ben Nadel had a bit of a "crisis of faith" last week over his ability to learn OOP the "right" way. He's highlighted a problem most people have coming to OO these days: in their search for the One True Way(tm), they are overwhelmed and can feel like failures. It can be a long, hard road. In a comment on his blog, I recommended everyone read the first two paragraphs of the "Gang of Four" Design Patterns book because it really sets this in context. I'm going to reproduce those first two paragraphs here to get you thinking. I highly recommend buying and reading the book.

[More]

There, I said it!

I said it in a post to the cfcdev mailing list and Henry Ho felt it deserved a mention on his blog.

The topic came up because John Whish, manager of the Devon CFUG over in England (where I spoke last September on design patterns), is running a series of presentations on OO and patterns for the group. He wondered how to approach the fact that CFers tend to have separate DAOs and Gateways whereas that distinction does not exist in non-CF languages or pattern literature.

I feel responsible for that distinction so I replied with my thoughts and an explanation of why I had suggested it nearly six years ago but why I don't think it's good advice these days (and, frankly, hasn't been good advice for years - I no longer had access to the guidelines document that enshrined the advice!).

I recommend you read the thread on the Google Group (cfcdev). Henry quotes part of my reply and links to the thread for more detail.

Thinking in objects can be really hard and one of the biggest stumbling blocks for many who are new to OO design is identifying what are the right things in the problem domain to model as classes. This topic came up in a recent thread on the excellent cfcdev mailing list and Alan Livie shared his recommendation for Robert C. Martin's book "Agile Principles, Patterns, and Practices in C#". In particular, he pointed list members to chapter 20 which discusses the design of objects to represent a coffee maker.

That particular chapter is available as a PDF and it's a really good read. It starts off explaining the problem to be solved and then presents the "obvious" object model that most new OO students come up with. Then he takes it apart, explaining why it's a poor design, and goes on to construct a much better model (with fewer objects) that is very elegant and easy to understand.

If you're struggling with the OO design process, you need to read this PDF and absorb the lessons laid out within it. Even if you think you're an OO 'guru' you'll probably learn something from it!

Several people have been blogging about the OO Quiz created by Hal Helms. I'd question the wording of a couple of the questions but it's a fun way to while away 15-20 minutes and it will definitely test your understanding of object-oriented terminology and principles.

The preso I gave on Monday at the Devon CFUG and which I'll be giving in about an hour at the TVCFUG has been posted to the PRESOS section on my blog. It's a PDF with slides and notes since there are quite a few notes on this preso and it'll make it easier to follow.

John Whish (Devon CFUG) has a version of all the slides (with builds but no notes) which was how I presented it on Monday because my laptop wouldn't drive the projector (first time ever!) and I had to present from John's laptop.

Update: Bob just added Part VII so I'm updating this post to include that.

---

For ease of reference I just wanted to post a quick note highlighting Bob Silverberg's excellent series on using Transfer ORM and OO architecture:

• How I Use Transfer - Part I - Introduction
• How I Use Transfer - Part II - Model Architecture
• How I Use Transfer - Part III - Abstract Objects
• How I Use Transfer - Part IV - My Abstract Service Object
• How I Use Transfer - Part V - A Concrete Service Object
• How I Use Transfer - Part V.1 - A Comment and Response
• How I Use Transfer - Part VI - My Abstract Gateway Object
• How I Use Transfer - Part VII - A Concrete Gateway Object

If Bob adds additional pieces, I'll update this post with his new articles.

There's a lot of good information here although it may be a bit overwhelming on first read so be prepared to keep coming back to these posts!

If you use Mark Mandel's awesome Transfer ORM in a cluster, you've probably wondered what to do about keeping the cache in sync across servers in the cluster. I've had to solve this problem a couple of times now and I figured I should publish an example of how to do this.

[More]

Andrew Powell - Enterprise Class MVC with ColdFusion and Java - Saturday 11:25am

We hear a lot of talk about using individual Java objects within ColdFusion but the reality of enterprise development is that entire subsystems tend to built entirely in Java. Software teams that serve the enterprise often build large, complex systems using Spring and Hibernate. How do you go about using ColdFusion with such systems? I haven't seen any presentations on this subject so I was pleasantly surprised when I started reviewing Andrew Powell's slide deck to find that he was focusing on how ColdFusion can provide the web front end to enterprise class Java systems.

He introduces Spring (the Java version) with a demo and then introduces Hibernate (the industry standard ORM for Java), again with a demo. After that, he will walk you through solutions to the problem of connecting ColdFusion on the front end to Spring on the backend and, using Mach-II as an example, he then shows how to create an MVC web application that allows you to leverage the entire Spring-powered, Hibernate-persisted Java backend.

If you work along a Java team - or you are considering using more Java for your backend systems - this talk will provide you with a lot of good information about how well ColdFusion plays in this space.

My blog posts have been few and far between lately. I can only blame one of my clients. Right now I have three clients and one of them is keeping me busier than I could've imagine when I first took them on in November. For all three, I'm designing / building a (Mach-II or Model-Glue) + ColdSpring + Transfer system. One client, here in the Bay Area, is pushing very hard to a full relaunch of their platform in just a few weeks so the pressure is really on to get a solid, high-performance system in place. I'm actually very excited about what they're doing - they've already proved their product with a number of clients with multiple codebases but we're creating a unified platform so that they can scale out to an arbitrary number of clients, all on the same codebase. I'll be blogging about them when they launch because I think their product will have broad appeal.

Of my other two clients, both are ongoing rearchitecture projects along similar lines but with slightly less impending deadlines. It doesn't look like I'll be anything less than insanely busy for several months tho'. January was a record month for me in terms of hours worked and I expect that will continue for the next few months.

The downside of that is I'm less available on IM than usual (sorry) and never on IRC (so folks have to ping me if the cfmx7bot goes offline). I'm also behind on getting articles and columns and presentations written - but I am almost completely caught up on reviewing cf.Objective() presentation outlines!

I'm working with just three clients right now and with each of them I am essentially doing the same thing: taking an existing system that has been built up over a number of years and helping them rearchitect it for better maintainability and better scalability. The technology stack is pretty similar in all three cases:

• Model-Glue (two clients), Mach-II (other client)
• ColdSpring
• Transfer

In addition, we're using cfcUnit and ColdMock for unit testing (Brian Kotek's ColdMock project is awesome for unit testing beans that are actually Transfer decorators!).

All three clients are on - or imminently moving to - ColdFusion 8 (as most of my clients have been) so we can take advantage of AJAX, performance, array/struct syntax, enhanced operator syntax, onMissingMethod() - which powers ColdMock - and many other recent enhancements.

These three clients have been keeping me pretty busy - I was even on-site with one of them for three days this week which, as folks who know me will realize, is pretty unusual since I've mostly kept to remote work since I left Adobe. I think they're going to be keeping me busy for at least the first quarter of 2008.

I haven't been blogging much this past two weeks but I've been posting to a few mailing lists, covering decorators (Transfer), dependencies (ColdSpring) and various OO design issues. I've also been writing an article for FAQU which will be in issue 6 (issue 5 is at the printers and should be in readers' hands soon). The article covers the whole "beans + DAO + gateway + service" object stuff, looking at four possible ways to structure your code and examining the pros and cons of each.

I'm also reviewing a new ColdFusion book that is in the works. It's a great introductory book that covers a lot of best practices and focuses on CFCs up front. It's target market means that it probably won't get on most American developers' radars but I think it will be worth tracking down and reading if you're a novice (to ColdFusion).

I'll also be writing a regular column for [name withheld] on my favorite subject: architecture.

As you can tell, 2008 has started off busy and looks likely to stay that way. I think the year will offer me some interesting challenges and some interesting opportunities - and maybe some big changes too.

Luis Majano has just announced that I will be encoring an extended version of my Design Patterns and ColdFusion talk at their December meeting.

Now that MAX is over and I've given my presentation at CFUNITED Express Bay Area, I've posted the presentation (612Kb PDF) to the "software" pod on my blog. Since there's a lot of "chatter" that goes with the talk, I've opted to publish the deck as slides + notes so you'll get a better sense of what the audience really hears.

Let me know if you have questions or comments!

Since there seems to be some interest in this, I created a mailing list for the project. Quoting from the group's about page:

Event-Driven Model Framework for ColdFusion. The name? EDM = Event-Driven Model, Mund = mouth (German), Mund = ancestral rule over the family / disciplinary power over members of the family / responsibility to protect the family (Old English). Edmund is also one of my cats :)

As folks start adopting more AJAX and Flex for their applications, I see a lot of questions about "how to use <insert favorite HTML framework> to handle AJAX/Flex calls?"

This is based on two things (in my opinion - putting on my flame-retardant suit)...

[More]

So I was gave a design patterns presentation at both MAXs... I figured I'd Google to see if I could find any coverage of it (no, I couldn't) and what turned up was my own blog post from four years ago! Along with the observation that CF lets you implement certain patterns more easily I said "The bottom line is that it's useful to be aware of the J2EE patterns but beware of slavishly applying them to ColdFusion - some of them were designed to solve problems that are specific to the Java technology and you can often find a more elegant form of the solution in ColdFusion."

As folks who attended my session in Chicago and/or Barcelona heard, I'm still offering that caveat today and people still think it's news...

With all the buzz around AJAX - especially with CF8 making it so easy - we're starting to see a lot of questions about how best to integrate AJAX with MVC frameworks like Fusebox, Mach II and Model-Glue.

Brian Kotek has a great post about data vs content in the context of AJAX and frameworks. He emphasizes the benefit of having your model in CFCs as the easier way to expose data-centric functionality to AJAX and notes that for data calls, you should not be trying to go through the MVC framework. It's a good read.

Kola Oyedeji articulates a growing frustration with CFers' use of design patterns that has also begun to bother me as more and more CFers try to move to OO. He highlights Brian Rinaldi's analysis of gateways in CF and then goes on to ask why we don't use several other common design patterns. Brian's post digs into the various types of gateway patterns and points out that none of them match what we tend to call a gateway in CF. Brian's post is a good read (I meant to blog it at the time but I've been a bit swamped this last week) and Kola's only scratches the surface of a growing problem in our community. I posted a couple of comments on Kola's blog which I may elaborate on as future blog posts here since I think design patterns are very important but there needs to be much more CF-specific "education" on them.

---

Please also take the time to read Matt Woodward's (very long) post about our use of design patterns in ColdFusion. It's an excellent read and makes some very important points about there being no "One True Way" and the fact that patterns are high-level and therefore can have multiple implementations in different languages.

Many of us have seen the (infamous) Ruby on Rails "Blog in 15 minutes" video and probably also Joe Rinehart's "Blog in 9 minutes" Model-Glue: Unity video. It makes it all look so easy. Wow! We should all use Ruby on Rails (or Model-Glue: Unity) because it will clearly make us so much more productive!

Of course, as those folks who've struggled with Model-Glue: Unity (or Rails or any other framework) know only too well, it's not quite that simple!

So why do some people struggle when others find these frameworks so easy and so productive? The answer is blindlingly obvious, unfortunately, but it isn't an answer most people want to hear.

Sammy Larbi asks "is Rails easy?" and points to Venkat's blog entry "Can your cat code my Rails App?". The answer to both of these might seem obvious. The answer to the second question is clearly "no". The answer to the first question is, unfortunately, "it depends".

As Venkat says:

I asked why she thought developing with Ruby/Rails is so darn simple. She said she had seen a demo of a fully working app being created within minutes without much effort or code.

The videos are, of course, somewhat misleading because they show what someone can do once they already know the framework really well. It's the same reason that experienced OO developers find OO so liberating and productive: they already know OO really well!

Venkat compares C++ and Java, saying the latter is more productive with the following caveat: "I doubt anyone would say that Java makes an ignorant programmer more productive. You did have to take the time to learn the details of the language, the platform, and the API."

The point behind all this is that there really is no silver bullet. Using a framework doesn't automatically make you more productive from day one. You have to learn how to really use your tools and sometimes that learning process is non-trivial to the point of seeming endless (and being a lot of hard work!).

I post this because I got into a somewhat heated discussion at CFUNITED a few years back with someone who thought OO was dumb because they'd tried to use it and it made a mess of their application. I said that it takes time and effort to learn OO in order to be able to apply it properly. They got offended, thinking I was telling them they were too stupid to learn OO. I've repeatedly said: this stuff is hard. I started doing OO in January 1992 and I'm still learning. OO has mostly become second nature to me now but that doesn't preclude me from learning new techniques - often from people with less OO experience - that help make me more productive.

So don't think that Rails is going to turn everyone into super-productive programmers overnight - most people coming to Rails already have a fair bit of Java and OO experience so pick up the concepts easily and, once they've learned the Ruby and Rails specifics, they can be more productive than they were in Java.

It's the same principle that applies when you learn a new framework in ColdFusion. It may seem strange at first and may look like extra work but once you understand most of the specifics, you can be much more productive. Just be prepared for a learning curve.

Brian went to Hal Helm's talk at cf.Objective() about Object-Oriented Modeling and it sounds like it generated sound good discussion. In particular, Brian has written up a walkthrough of Hal's "employee" example which shows that the 'obvious' use of inheritance is both simple and wrong. He then takes us through how to solve the problem (with a design pattern - Strategy) and how to use composition and inheritance correctly. It's a good article. If you're struggling with certain aspects of OO design, it should help you.

Lots of people like Ruby on Rails for the speed with which you can build web applications. One of the tradeoffs I often bring up in discussions of abstraction - which Rails offers in spades! - is that each layer of abstraction adds a certain amount of overhead. Sometimes it's easy to refactor the abstractions out in order to reduce overhead (and improve performance). Sometimes it's hard.

Andrew Shebanow has a good post about this tradeoff in relation to Twitter, which is powered by Ruby on Rails. Alex Payne, of Twitter, has talked about their experience with the massive scalability explosion that the site has seen and some of the "friction" that they've encountered trying to refactor the abstractions out.

I worry about this in the context of most every framework I use - and there's certainly been plenty of noise on mailing lists and blogs over the years about the performance of frameworks. One of the reasons I've settled on Fusebox for the Scazu website is that it compiles all the circuit files down to inline CFML on the first request so the abstraction is compiled out (this is one of the core messages in my "Extending the language of Fusebox" presentation - see slides and sample code under 'SOFTWARE' on my blog).

I've also been a fan of Transfer for ORM, lately because of the TQL - Transfer Query Language - component that lets me write complex database queries using an object / property abstraction. It looks much like SQL but lets you use the terminology of your application instead of the terminology of the database. It does add overhead but refactoring methods that use TQL into methods that use the underlying raw SQL is pretty straightforward and can be done on a method by method basis (and, in fact, I recently refactored one performance-critical method in exactly this way).

Going back to Andrew's post (and the underlying comments from Alex), I'd say that Transfer has a low friction coefficient that contributes to why I like it so much.

Brian Rinaldi picked up on an opinion piece by Allen Riddle that asks if SOA (Service-Oriented Architecture) is killing OO in the enterprise. Brian draws a parallel between Allen's arguments about generic programming diluting OO programming and his own diversions into anemic domain models, often caused by having dumb beans and fat service objects.

[More]

Nice piece on InfoWorld about the design of services: services are not applications. It's very important to keep this distinction in mind if you are building a system based, primarily, on web services (or Flash Remoting, to be honest). Architecture, performance, coupling and cohesion - those concerns all pull in a different direction for services than they do for applications.

Peter Bell has taken a comment by Brian Rinaldi on cf-talk and turned it into a somewhat controversial treatise on using frameworks and learning OO! Make sure you read the (ongoing) thread on cf-talk as well for background and then feel free to pitch in on cf-talk or on Peter's blog or even here on this blog. I think this one is going to run hot for a while...

In response to a question on the Model-Glue mailing list about how to structure applications, I posted a fairly extensive response about separating controllers from the model. I suggested you always imagine you might have to change the MVC framework you use.

Brian Kotek picked up on my response and posted that you don't need to go that far - just considering that you might have to put a Flex front end on your application is enough. He's right, of course, and that harks back to my Mach II advice post back in May.

I was reading the Flash Coder blog about the lack of value of frameworks and it made me think of Simon Horwith's comments about frameworks in ColdFusion.

In particular, I was taken by this comment from the Flash Coder:

A development framework is useful when your workforce is disperately or poorly skilled. Perhaps 'poorly' is the wrong word - maybe 'intermediate and below' is a better description.

To be fair (to both Simon and to the Flash Coder), the blog entry is mostly focused on code size and performance in regards to frameworks and is specific to Flash (therefore the context is more about cell phones and set top boxes).

However, the underlying sentiments expressed by the Flash Coder threw up much the same "red flag" that some of Simon's comments have: namely that frameworks are not appropriate for "good" developers and that if you're really good and really know OO and patterns, you just don't need frameworks.

Here's another quote from that entry that is almost exactly what Simon has said when justifying his Sensible Assembly Methodology over using a standardized framework:

The best solution of course, is to have skilled developers creating good pattern based OO code in a more project bespoke manner and adhering to accepted best practices.

I don't really want to start up the whole framework vs no-framework debate again but I thought it was interesting to see this message - and the subsequent pushback in the comments - coming up in Flash. I would bet we could go look in the PHP or Java community and see the same thing.

Tom Ball (Sun Microsystems) asks the question "Is writing code a Career Limiting Move?" - there seems to be a strong sense in many teams that architects don't (shouldn't) code but it seems to go against agile thinking.

This post hits a nerve for me because as a senior software architect for most of the last decade, I've often found myself in situations where I've ended up quite distant from the code. And I don't like that much. I don't want to just write code but I do find writing code to be both very therapeutic as well as a good way to experiment with some of my ideas and evolve better practices.

I realized recently that, although I created the engineering team that rebuilt macromedia.com (now adobe.com) using ColdFusion and Flash, I hardly wrote any of the code on that site! The RSS feeds on LiveDocs are powered by code that is based on an initial prototype I built but that's about it, in terms of live code. I wrote quite a bit of back end infrastructure code for our ERP integration project (lots of XML processing and JMS messaging). That was a while ago.

My new team is smaller and is trying to be more agile in style so architects write code too. It's really good to roll up my sleeves and write code again - it's really helped me confirm some of my architectural ideas about what we're building (both good ideas and bad ideas!).

BTW, this lack of coding at work is what fuels my contributions to open source projects outside work, such as Fusebox 5!

Brian Rinaldi has a great blog post about taking the plunge with OO, with design patterns and, in particular, with frameworks.

Apparently I can be "quite blunt" but that was enough to kick Brian's butt into actually trying OO etc.

What I really like about Brian's post is that he realizes that there is no "perfect" OO solution and that it's OK to move toward the light, step-by-step, and it's OK to make mistakes and take shortcuts and make things better later.

Excellent post Brian - lots of good lessons to be learned here. No one should be afraid to take those steps!

Simon Horwith is an easy target to rag on and he likes to be controversial. I wrote at length about his Object Think session at CFUNITED and I (mostly) agreed with the principles he was espousing. Those who were at CFUNITED and saw the "celebrity death match" will have heard Simon promoting his methodology - while admitting that only one other person in his company understands it well enough to explain it to others. It's kind of the big joke in the community that one day, some time, Simon will actually document his methodology.

His employer, AboutWeb, has just released the second in a series of podcasts. This second one talks about SAM, Simon's "Sensible Assembly Methodology". I'm looking forward to listening to it (as soon as I get caught up on my podcast backlog!).

He also said on blog today (July 7, 2006) that "I plan to have the first round of SAM documentation done and available within the next several weeks - probably before the end of the month".

For a bit of fun, I thought I'd search his blog for mentions of his methodology and see just how long he's been promising us the SAM documentation. So here, for some Friday fluff entertainment, are quotes from Simon's blog over the last year:

January 13, 2006: "The methodology I use, which I promise you'll all be able to read very soon".

December 24, 2005: "I have begun documenting the methodology that I use for developing applications and do promise to make that available very soon".

November 1, 2005: "I will begin the documentation of my methodology sometime in the next couple of days".

October 20, 2005: "I will begin documenting the methodology I use for planning and developing software with CF".

October 1, 2005: "I will officially be releasing my methodology, most likely I'll make the files and documentation available off of horwith.com, possibly on aboutweb.com as well".

September 26, 2005: "the book I've mentioned from time to time over the past year, which is still in the works, will be a definitive guide to my methodology".

September 21, 2005: "So far I still feel this way and I plan to do just that (document and release my methodology) sometime after MAX".

August 12, 2005: "I will document and develop a better alternative! I already have a methodology I use and it does include certain files I've written".

The suspense is killing me... :)

The last session I attended at CFUNITED was Simon Horwith's talk on "object think". There was a lot of discussion about Simon's views on object-oriented design at the conference because of the "celebrity death match" with Hal. As some of the attendees know, Simon and I disagree vehemently on several issues - mostly around frameworks and the actual implementation of object-oriented designs - but what most people don't realize is just how many issues Simon and I agree on.

Simon started out with an overview of what object think is about. The key concept is "object personification" which is the basic way that I teach people about object-oriented design: I make people play at being the various objects in the system. I make them write notes to each other to reflect the message passing that objects do. Object think is all about creating an expressive but accurate domain model where every object handles all of its own responsibilities - it sounds obvious but it has some deep implications.

[More]

Peter Bell - a strong advocate of application generation techniques - is blogging so that should be a good one to watch! Thanx to Brian Rinaldi for pointing that out.

Peter has some very interesting ideas on code generation and is very passionate about it. You can always guarantee a good (and often heated!) discussion on a range of topics that includes frameworks, design patterns and metaprogramming.

Welcome to the blogosphere Peter!

So you're building a Mach II application and you're figuring out what code should go in your filters and what code should go in your listeners and you build it all out in a nice, modular fashion and it works and you're very pleased with yourself.

And then you need to put a Flex front-end on your application. That means you need to expose your model as a set of remote methods. If you got your application design right, that'll be easy: just open up your model CFCs and change the access attributes and you'll be done, right?

[More]

Thanx to Dave Carabetta for this great discovery - he writes that Gentleware, makers of the excellent Poseidon for UML product, have teamed up with Synergy Learning to create an incredibly comprehensive online course entitled Introduction to Object-Oriented Modeling and UML. Dave has a lot of details on his blog as well as his thoughts on the course.

Updated to add some clarification on my views about performance!

First off, while I think the tests are interesting, I've always been one to say don't worry about performance too much because "fast enough" is almost always sufficient. Very few websites get the sort of traffic to need heavy load testing and tuning, frankly, and as we know there are some very high traffic sites out there running on various frameworks. macromedia.com runs (about a quarter of its applications) on Mach II and the performance under load testing met all of our criteria.

My comments about the tests Webapper ran were meant to say:

• It's no surprise Fusebox is "faster" because it is more of a compiler than anything else (the framework doesn't really "do" anything at runtime, once your XML is compiled to CFML)
• I was pleasantly surprised that Mach II was not slower than a hand-coded CFC-based application - a lot of people complain about the "overhead" of Mach II but this shows that is not necessarily true

And I should have pointed out that none of the versions were optimized for speed. However, I'll bet that if they are all optimized, the results overall won't be too different - at least, not different enough to make any overall judgments and, in particular, framework choices based on.

The point of the original (Webapper) article was that JVM tuning can have a dramatic effect on performance, as can Trusted Cache.

---

Those wonderful folks over at Webapper have been doing some load testing on various frameworks using the ColdFusion PetMarket application (featured in the February CFDJ). They tested Fusebox 4.1, Mach II and Simon Horwith's "no framework" versions of PetMarket. Fusebox 4.1 was the fastest which really isn't much of a surprise since it compiles everything down to straight line CFML on the first request so subsequent requests just process a single file. What surprised me was that the Mach II version outperformed Simon's version (albeit, not by very much). Overall, Simon's version was 100% slower than the Fusebox 4.1 version. Unfortunately, Webapper couldn't test the Model-Glue version because "the PetMarket Model Glue application was not fully functional". Based on my experiences, I'd expect Model-Glue to fall somewhere between Fusebox 4.1 and Mach II performance so I hope they get a chance at some point to show that.

In the last few weeks I've been receiving an increasing number of questions asking "Which framework should I use?". Sometimes there's quite a bit of background about the application to be built and / or the skillset of the developer(s) involved. Most often there is little or no background info. For example:

I just want to know your thoughts on this question... Which is the best Framework you think to adapt? (Fusebox or Mach II)

Even assuming they mean "adopt", it's certainly not a straightforward question. I'd recommend folks download my frameworks comparison presentation and take a look at the accompanying sample application code. This covers Fusebox, Mach II and Model-Glue and gives pros and cons for each framework as well as some broad recommendations based on your skillset and the type of application you want to build. The sample code has nine variants of a single application, showing various flavors of Fusebox, Mach II, Model-Glue, Tartan and ColdSpring in various combinations.

I'm currently running around CFUGs with a talk about "Objects & Persistence" that briefly covers four of the ORM frameworks that have appeared lately: Arf!, objectBreeze, Transfer and Reactor. I'll soon also be giving a talk about factories and covering ColdSpring. Both of those talks will be accompanied by more variants of more applications.

However, I get the impression that some of the people asking me this question want me to specifically recommend a framework or a combination of frameworks for them so they don't have to digest the presentation and code. The short answer is that there is no "One True Answer™".

Here's part of another email - which has a lot more background the question - but here's how the question was phrased:

Anyway, I'm looking for some guidance with frameworks. I am involved in a project that I know could benefit from using a framework. I just don't know which one would be best. The more I read, the more confused I get. I think I've narrowed it down to Fusebox or a Model-Glue / ColdSpring / Reactor set up. I really like the MVC concept, but am new to that as well, so I'm not sure if it would be easier to go with something that forces the implementation or trying to implement Fusebox in an MVC pattern.

This person has done their research and understands some of the tradeoffs involved which is great as far as I'm concerned. I sympathize with this part "The more I read, the more confused I get." - it's not a simple choice. They will get a long, detailed response - as soon as I find time. The other email shown above will get a short recommendation to read my presentation and look at the sample code.

The point of this (somewhat long) blog entry is that if you want me to offer advice on the choice of frameworks, I'm more than happy to do so - but the quality of the answer you get will be directly proportional to the amount of information you provide me with (and the amount of "homework" you show you've done).

And yes, I do have a personal preference - if there is no overwhelming reason to use a different specific framework combination. Just remember that what works for me might not necessarily work for you. What is my personal preference? Don't read too much into someone's personal preferences...

Frameworks certainly stir up some passionate debates! Bob Lee says "I Don't Get Spring" and it gets picked up by The Server Side and both posts generate a lot of commentary. ColdSpring implements, in ColdFusion, several features of Java's Spring framework features so some of the discussions linked should prove interesting to you, as a ColdFusion programmer.

Joe Rinehart talks about the benefits of frameworks in the context of security audits. He highlights how MVC and separation of concerns, inherent in many frameworks, helps isolate areas so that auditing an application's security becomes easier. It's another case of frameworks helping to provide standardized application structure that then makes all sorts of other software tasks much easier.

I was a little surprised he didn't go into more depth and talk about how frameworks can often provide standardized way to manage user login security and logging and auditing. Plugins and extension points (such as Model-Glue's standard broadcast messages) allow login / security to be built into applications in a nice, clean standard way. Auditing and logging can also be added more easily: Model-Glue allows a logging listener to be easily added that tracks all the messages without interfering with the existing application flow; ColdSpring AOP allows pretty much any application behavior to be logged without touching the application code.

Using a framework can save you a lot of work - tedious, boilerplate work.

A couple of days ago I talked about the differences between the abstract factory and factory method. Joe Rinehart has followed up with more about why factories help you write less code. He also outlines a situation where the abstract factory is useful and Doug Hughes mentions another situation in his comment. Both involve multiple similar implementations of subcomponents - support for multiple databases in Joe's example and support for multiple authentication systems in Doug's example. Joe also offers sample factory code (for the factory method design pattern).

Someone asked today whether the abstract factory design pattern might be overkill for general ColdFusion web applications. I said, yes, we would find more applications for the factory method design pattern in our world - abstract factories are pretty complex beasts.

So, what's the difference between the two? With factory method, you generally provide a key of some sort and the method yields an object of that type. We see this with hand-coded factories that we give a text string to and get back an object - the text string is either a simple key, the name of a component type or the ID of some object described elsewhere (e.g., an XML file). ChiliBeans and ColdSpring are two good examples of factory methods.

With abstract factory, you usually have multiple factory implementations and each factory implementation is responsible for creating objects that are usually in a related hierarchy.

We typically just say "factory" and we mean "factory method". Want to see an abstract factory in all its glory (gory?)... check out this 1996 article I wrote about building a compiler. I didn't call it an abstract factory design pattern because back then I didn't know the names of those patterns very well (the "Gang of Four" Design Patterns book appeared only two years earlier).

If you're feeling masochistic and want to understand a bit more about what makes me tick, feel free to read the entire compiler writing series (six parts, written between 1994 and 1996 and published in Overload).

I was having a private rant about the way people keep getting tripped up on design patterns in ColdFusion - the recent obession with building code using as many design patterns as possible - and the person I was chatting to asked if I structured my code cleanly from the get-go (i.e., using patterns).

My response was "Of course not!"... Now, it may surprise you to hear that someone who is so evangelical about coding standards and, in particular, design patterns, will actually build code that does spring fully-formed and cleanly architected out of its crib and into the world at large. Before you paint me as a hypocrite, let me explain...

I tend to build my code to be as simple as possible to start with. I may well write just one or two CFML pages (sometimes fairly long ones), just to get some machinery down and working. Then I'll refactor for a while, pulling code out into CFCs, for example. Then I'll add some more functionality - again using the straightforward approach - and then I'll stop and refactor. And so on.

I refactor to make the result maintainable or to prepare for a new round of functionality to be added. I try very hard to not attempt both at the same time: fix the functionality, change the code, test, add new functionality, test, repeat. Of course, I should be writing test cases before adding each new piece of functionality (I'm still supping away at my TDD kool-aid).

Anyone who has been watching the development of the IRCBot will have seen similar changes across releases (and the next release, when I get around to it, will continue that trend). I started with a monolithic CFC and refactored before adding each new round of functionality.

Sometimes attempting to both solve the basic problem before us at the same time as attempting to shoehorn design patterns into our code gives us writer's block. I can't count the number of posts on framework lists that say "How do I do X in framework Y?" when it's not totally clear that the poster could solve X outside the framework. My advice is always: implement X (away from the framework) and then refactor that code into framework Y. That way you're only solving one problem at a time.

Furthermore, don't feel forced to use design patterns "just because". They're intended as templates for solving problems you would have in your code - they are not solutions to business problems. Solve your business problem, then solve your code problem. Sometimes, you'll realize the cleanest solution to a given business problem will involve using one or more design patterns to create the code. Good for you - you just saved yourself a bit of refactoring.

Don't over-engineer your code either. Keep It Simple Stupid and You Ain't Gonna Need It are both reasonable bits of advice. Sure, sometimes a potential future enhancement is so blindingly obvious that refactoring in advance to support it is worthwhile.

And where does that leave frameworks? A lot of people argue that frameworks break the KISS / YAGNI principles - you don't need a complex XML config file, an MVC framework is overly complex for my simple app. Well, maybe, but think of the process of adopting the framework as just refactoring for maintenance. You might not need it for a one or two page app. You will need it for a hundred or two hundred page app. Refactoring a small amount of code to use a framework is a lot easier than refactoring a lot of code to use a framework. And a good framework won't get in the way - it won't really add any complexity. The tipping point is actually very low and the inherent complexity of a given framework is small in comparison to the likely complexity of your application.

At the end of the day, it comes down to what you feel comfortable with and how far you want to push yourself. Don't try to "boil the ocean" and cause your project to fail - don't try to learn a new framework for a tight deadline, mission-critical project. Use what you're comfortable with. After the deadline, look at refactoring the code to make future enhancements easier.

A few days ago I highlighted posts by Scott Barnes and Joe Rinehart and talked about why we have a lot of 'dumb' objects in many of our applications. Well, Scott is still bashing DAOs in ColdFusion and asking questions about where validation and transformation live in the model.

When you have an object model, you tend to use whatever types are most appropriate for the in-memory execution model, e.g., boolean. When you have a database, you use data types that are native to that particular database. In some (most?) cases, those will differ. Whose job is it to map between those representations? I hoped it would be obvious that the data layer (DAOs and gateways) 'own' that transformation but it appears to need re-stating:

It is the job of the data layer to perform the necessary mappings between the persisted database schema types and the in-memory object data types.

So a boolean in an object might be mapped to / from a varchar(1) 'Y' or 'N' value - in the DAO.

What about validation? Well, the DAO doesn't (shouldn't!) know anything about your business logic beyond knowing what in-memory data types you use. It might know a date of birth field is mapped to / from a datetime or date column but it doesn't care about valid date ranges or any such business stuff. Validation belongs somewhere in the business layer.

Now, whether you have smart beans with their own validation or dumb beans with external validation is up to you. The point here is that the business logic 'owns' the task of applying that validation to the bean before using the bean in additional business logic (and, therefore, before passing the bean to the data layer for persistence).

Here's an interesting use case tho': your application wants to store unvalidated data (because an object can be in many states, perhaps, and you're following a principle of enterprise robustness of persisting all the data you receive for audit purposes). By definition, this means your persistence model must support untyped (i.e., string) data. That also means your DAO must do no transformation. And that in turn means that it is the job of the business layer to decide whether the data is 'valid enough' to operate on. All the same, the business layer still owns validation (although it's now optional), the data layer still owns transformation (although it's now an identity operation).

The layers and responsibility are always the same. The details may change.

Following on from the CFCDev thread I mentioned about factories and ColdSpring yesterday, I noticed Scott Barnes railing against using DAO / Data Gateways in ColdFusion and left him a comment saying I felt he'd missed the point. In fact I was a bit mystified by his entire post. However, reading Joe Rinehart's blog post today about anemic domain models made me realize what bothered me about Scott's post. Joe's point is that we're seeing a tendency to separate simple applications into tiers in such a way that our domain model - the real business part of our application - no longer does anything useful. I think Joe's example is slightly misleading tho' because it is too simple to underpin the point I think he is trying to make.

Here's the rub: most of our day-to-day ColdFusion applications are simple data entry stuff... display a form, user enters data, create a new entity from the form data... display a list of entities, user selects an entity, display pre-populated form, user changes some data, update the entity from the form data... we have an anemic domain model because, well, the domain model doesn't actually have any behavior!

Our controller loads beans to pre-populate the form and updates beans from the form data and persists the data. There's no behavior there. Our bean isn't smart - at best it might do a bit of validation for us. The controller isn't doing much either beyond orchestrating the CRUD operations on the bean.

We're caught between a rock (an example simple enough to explain in a few sentences) and a hard place (an example complex enough to show why we might use these patterns at all). No wonder some folks try to use these patterns (in simple apps) and can't see the point of it - and it can be hard to take the advice on trust that it's worth it for when your app grows.

Perhaps we need more KISS (Keep It Simple Stupid), YAGNI (You Ain't Gonna Need It) and XP-style refactoring?

Download my frameworks presentation and the accompanying code examples (see "Software" pod on my blog) and look at the first five variants as a progression from procedural to simple OO to refactored OO and see how it sits with your comfort level for such a simple application. The fifth variant has an anemic domain model because the domain is very simple - but consider how much easier that version would be to use as a basis for a much more complex task management app than the fourth variant....

Thoughts?

Here's a problem many of us stumble on: what should a (utility) class API look like? Should it be short and concise, allowing users to build on it, or should it be all-encompassing, addressing every use case out-of-the-box.

Martin Fowler voiced the opinion that he prefers the latter, using the term humane interface and he sparked something of a religious war between two factions. Check out the links he gives at the bottom of his post, especially to Elliotte Rusty Harold's piece on Cafe au Lait and James Robertson's response to Rusty which also has some very revealing comments.

Back when I was on the C++ Standards Committee, we had this argument about the string class. One group wanted a small, narrow API; one group wanted a broad, rich API. Neither side ultimately won so the class is a bit of a mess. It isn't quite a compliant container class (conceptually a string is a sequence of char) but it isn't quite an atomic string class either - it has bits of both. At my insistence, it does have both size() and length() however, for exactly the reasons that Martin Fowler mentions. In C++, size() applies to containers but most people are comfortable with length() for an atomic string. I fought hard for that change but I'm not - in general - a fan of large complex interfaces such as those Fowler would characterize as "humane". In fact I fought the addition of numerous "helper" methods for string (and failed to defeat their addition in many cases!).

Anyway, definitely some good reading for background on what people view as both good and bad class design.

Alistair and Stephen of Macromedia Consulting (formerly of iteration::two) explained the Cairngorm Rich Internet Microarchitecture. This was my first exposure to Cairngorm and was marked as an advanced session but I figured that I'd find it interesting anyway. It turns out that Cairngorm is effectively a set of design patterns and a recipe for how to use them together so I was pretty comfortable with the material.

They went through each of the major pattern collaborations in a Cairngorm-structured Flex app and emphasized the benefits of an event-driven architecture, using named, high-level business events rather than just the low-level click / drag type events in Flex.

The design patterns include Front Controller, Command, Service Locator, Business Delegate, Value Object and a Model Locator. Together they provide a powerful and compelling structure that makes it easy to scale applications as features grow. To demonstrate that, Alistair did a live enhancement to the demo application (the Cairngorm-structured Flex store) in just five minutes that would have taken substantially longer without a framework in place.

Definitely sparked my interest in doing more Flex development - and using Cairngorm!

Chris Scott has posted the first in a series of tutorials on ColdSpring AOP. It's a very good tutorial but it'll probably leave your head spinning the first time you read it: AOP allows you to change the behavior of your code, applying external code before and after certain method calls, without touching a line of code in your original application!

Well, assuming your application is built with ColdSpring in the first place - which is reason enough to start looking seriously at using ColdSpring to assist in managing objects in your Model.

ColdSpring AOP lets you "re-wire" the objects in your Model so that your code ends up calling proxy objects (which in turn call your original objects), and the proxy objects can execute "advice" code before, after or around calling the original methods. This lets you add logging to all or any part of your application, simply by configuring the XML file that defines the objects that ColdSpring manages. Or security. Or...

...but nor should it drive your entire application design.

Back in November last year, I posted an entry about data-driven design and pointed to responsibility-driven design which has essentially replaced it. Mark Kamoski just posted a (long) comment on that entry which points out, quite rightly, that a database is important and that some (many?) RDD evangelists speak as if the database can almost be ignored.

I just wanted to clarify that, yes, the database is an important part of most applications because, well, you need your data to persist and preserve its integrity. However, starting to design an application from the database tables forward to the UI is not going to create a maintainable, easy-to-use application. The UI is the most important part because that's what your users see and interact with. The interaction use cases drive the functionality your application must have. Those use cases should drive the design of the model, since it must support all the interaction use cases - and often more if you plan for growth and change. The model determines the data the application requires and that in turn drives the database design.

Database design is important. Your tables should not just be mere shadows of your objects. Objects (classes, really) are designed to satisfy dynamic interactions and represent a variety of entities and relationships in your domain. Databases represent those entities and relationships too but usually in a different form - due to normalization and efficiency concerns (or sometimes just the simple practicality of representing something complex using just columns and rows!). Therefore there is nearly always a mapping between object data and tables.

If you start with the database, that mapping will not be obvious until you get closer to the UI and that's the wrong place to do the mapping - you need the model first and that means focusing on responsibilities, not data.

Joe Rinehart has an interesting follow-up on Simon Horwith's talk about framework-free software development from the recent Fusebox & Frameworks Conference. I didn't see Simon's talk but based on the quotes in Joe's post, I would have disagreed with several of the same points that Joe takes issue with. In particular, implying that the Model is all about data and that databases should be designed first while pushing all of the logic into the Controller portion of an application is, in my opinion, short-sighted and not even close to best practices. Hopefully Simon will clarify some of these issues when he publishes his methodology / framework!

Chris Scott has posted a good overview of what AOP is and why it can be useful. He also talks about what ColdSpring AOP will provide - and code examples will be forthcoming after the Fusebox / Frameworks Conference this week.

It seems that the frameworks discussion is taking its toll on Simon... In a recent comment on his blog he says "I'm getting tired of hearing about Fusebox" (he's giving the intro to Fusebox session at the Fusebox / Frameworks conference this week!) and that he has "got more important things to do" than "exchanging comments with an entire community" (which he says is "tiring").

So Simon doesn't like Fusebox and is already tired of it - after spending four days learning "all about it" so that he could give the talk at the conference... He thinks frameworks in general get in the way and wants to tell you about his methodology instead which "requires stronger application development skills" and if you think you can discuss frameworks with him, he says "I'm begining to care less and less as people continue to try and convince me".

I'm sorry I'm not going to the conference because I'd really like to talk to Simon more about frameworks and why he is so down on them. Like everyone else who has been involved in the discussion, I'm looking forward to seeing what Simon releases in terms of methodology and code since he believes it's so much better than what most of us are doing today.

I'm not tired of talking about frameworks tho' and I'll be doing just that on Friday at the Salt Lake City CFUG.

And still the debate about frameworks continues... Joe Rinehart has posted a couple of entries on this subject that are worth reading: silly argument, hiring criteria.

Barney Boisvert waxes lyrical about good object-oriented design and how to build more robust, maintainable systems. The best part is that he shows that OO isn't really all that scary, some of it is just common sense!

He also slips in a couple of common design patterns and explains them in very natural terms, showing how they benefit maintainability.

Barney Boisvert has a posted a great entry about how he designs applications. He talks about services, managers, business objects, data access objects, gateways and how to make appropriate compromises. If you've been struggling with OO design - or are just contemplating it and not ready to make the jump yet - then this article should be of benefit to you!

Macromedia's Sho Kuwamoto has kicked off a very interesting discussion about the applicability of MVC to RIAs. Sho comments that MVC is more relevant for HTML applications than for Rich Internet Applications because the views are "smarter" in RIAs. Not everyone agrees with him so the comments are fascinating.

Make sure you also read his follow-up post about state management.

I may have additional comments once I've read all of that (and I may post them in his threads if I feel they're more appropriate to RIA discussions or I'll post them here if I think they're more appropriate to HTML application discussions!).

Artima has a great interview of Erich Gamma by Bill Venners. Erich is one of the "Gang of Four" that brought us the Design Patterns book (a decade ago!). The interview covers Erich's thoughts on how design patterns should be applied. My favorite quote from the interview:

"One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3."

Hal Helms talks about why OO is hard and offers some recommended reading as well as cautioning patience on the journey to OO-ness. As he says:

"... the truth is that almost none of us "pick up" OO in a few weeks or even months."

An accurate observation from Mr Ed at Hacknot about the success (or more often failure) of a designated architecture group within an organization.

When I joined Macromedia, I joined as Senior Architect, part of a dedicated team of architects that were tasked with overseeing web infrastructure, data modeling activities, globalization issues, business processes and so on. I think there were seven of us, including our manager. She went on to set up a situation where all projects had to be approved by the architecture team and each project needed an architect associated with it to "tell them how to do things" (effectively). This was very adversarial, as you can imagine, and over time the team became rather unpopular.

She left, the team transitioned to a new manager who was more concerned with her program management team than her architecture team. The program management team folded and she left, leaving me in charge of the architecture team, which by this point had lost a couple of members - these were dot-bomb times.

I tried to integrate the architects more deeply into projects, making sure they were involved in implementation issues rather than just academic decision making. In the Summer of 2001, I formed the Web Technology Group and the architecture team disbanded, with architects being embedded in various IT teams.

Since then, various people have tried to resurrect the architecture team in various guises with varying degrees of success. As things stand today, we have a 'virtual team' - an architecture council that is made up of senior engineers from each division within IT. I chair the group and, after several experiments, we're now meeting only rarely but we keep each other informed of projects within our divisions and we discuss technical and architectural aspects of these projects whenever we need to.

This arrangement ensures that we're not an isolated 'decision-making' think tank - we're fully integrated into our primary teams - but it also recognizes the 'go to' people who need to be involved with complex projects and, in particular, cross-team projects.

We're still working out the kinks and learning from our mistakes. Read Hacknot and learn from the mistakes that Mr Ed has witnessed.

Doug Hughes continues his series on UML with a great post about activity diagrams and how they can help you document the high-level behavior of a particular Use Case. If you've been wanting to delve into UML but are put off by the apparent complexity (or the non-CF literature), then Doug's blog is a great place to start.

How do you design systems to collaborate safely and robustly? Rebecca says you should start by dividing your applications into "trust regions". Within a "trust region", objects communicate collegially, i.e., without double-checking data for validity. Objects at the edge of a region validate incoming data (passed in or returned from non-trusted collaborators). Formal contracts are useful for boundaries (only).

She gave some specific recommendations for dealing with untrusted collaborators: pass a copy of your data - don't share it by reference; after a request (to an untrusted collaborator), check that the request was actually executed (by calling some status test on the collaborator); employ alternate strategies when a request fails.

However, she also noted that redundant checks are a source of errors, inconsistency and brittle code as well as a performance problem. Don't fall into the trap of validating data that has already been validated for you.

Then she moved on to exception strategies and had some very good advice, including: name exceptions for what went wrong, not who raised it; recast the exception when you cross a boundary / abstraction level so that it makes sense outside the boundary (i.e., catch an internal exception and throw a translated, external exception). Some of the suggestions she had make me realize I need to revise the exception handling section of the CFMX Coding Guidelines!

Next up was Java's checked exception. Basically, they suck because they cause you to write reams of unnecessary code (see my other recent posts on this subject, referencing Bruce Eckel's articles).

Finally she covered a variety of strategies for robust handling of exceptions and called out the common practice of simply retrying operations: there's no point unless you really think the service state will change and a future operation will succeed!

A good, broad introduction to what SOA is (and is not). One of the key takeaways is that to realize the full benefits of SOA, you need more than just web services: you need business process management and a common semantic dictionary as well. Without those elements, your services will have a hard time collaborating and probably won't reflect the correct business abstraction level.

Another key takeaway is that none of this is new but today's open standards (e.g., XML, SOAP) make SOA easier to achieve.

Matt talks about the tradeoffs involved with persisting composite objects. He offers up three options and settles on one of them but he explains the tradeoffs involved. There are quite a few comments as well that cover even more factors that might influence your decision.

...you're doomed to repeat them. Joe Rinehart continues his excellent series of posts about OO by talking about the joys of learning lessons from your mistakes. It's a great post - and it reinforces why I tend to tell people that "close" is good enough for the first cut but be prepared to refactor, refactor, refactor!

This is summarized from Martin Fowler's bliki - attendees at a workshop on enterprise software voted on principles that they felt were important in a layered architecture. Here are the top principles:

• Business layer only uses abstractions of technological services. 14/0
• Layers should be testable individual. 12/0
• Layers are a logical artifact that does not imply distribution between layers. 11/0
• Separation of concerns. 11/0
• Low coupling between layers, high cohesion within them. 10/0
• User interface modules should contain no business logic. 10/0
• Inbound external interface modules (eg web service handlers) should not contain business logic. 10/0
• Business logic layers contain no user interface and don't refer to user interface modules. 8/0
• Layers should be shy about their internals. 8/0
• No circular references between layers. 8/0
• Layers may share infrastructural aspects (eg security) 7/0
• Lower layers should not depend on upper layers. 6/0

These seem like pretty good principles to me (and the ones that got big negative votes seem like bad principles).

If you're following Hal Helms' Occasional Newsletter series, this will be old news but I wanted to highlight Ray Camden's commentary on "Context is King", the most recent article from Hal. I'm well known for responding to questions about the "right" way to do something by saying "It depends" and more recently I've started pushing even further by saying "Get it working, then factor to improve it" as a way of encouraging people not to become paralyzed trying to do everything right first time.

Brian Kotek pointed me at the Net Objectives site which hosts a series of recorded presentations comparing design patterns. As of this writing, Scott Bain is covering Adapter, Proxy and Facade.

Donald Bell's Introduction to UML (IBM Developer Works) is a good resource if you want a quick overview of most UML diagram types.

Another good introduction is on Kennesaw University's website

Thanx to Jared Rypka-Hauer for the for the pointers to these articles.

Doug Hughes has started a series of articles explaining what UML is all about. If you're interested learning OO, then the UML - Unified Modeling Language - is something you're going to keep coming up against in books. You'll need to learn enough of it to make sense of the books and, if you're really serious, you should learn enough to be able to model your applications with it - which you should find really helps you think about your model abstracted from code. I use UML all the time - I've been using it since '97 (before that I used Booch and OMT which were the forerunners of UML) and it's really helps me get a handle on problems!

Since I'm continually telling people there is no one true way to solve most complex problems, this blog entry about two similar patterns is particularly timely. I've been trying to emphasize that for a given pattern, there can be multiple implementations and picking the right one depends on all sorts of variables within your problem space. Here we can see that even for a fairly simple, common problem, there are multiple patterns too (and each has multiple implementations).

Like I say, this stuff is hard!

In response to Matt Woodward's excellent introductory article mentioned earlier, Joe Rinehart bares his sole and talks about how his early attempts at OO went wrong because he was writing procedural objects - big, fat, objects that do everything - which are usually the result of taking a procedural approach to a problem and just creating a CFC with lots of methods that contain the original / traditional procedural code.

Hal Helms touched on this in his "Bad OO" newsletter (which I also mentioned a little earlier).

Hal Helms has started a series of articles on good and bad object oriented design with the goal of teaching folks (a) why OO is hard and (b) how to do basic OO design well enough to get some benefits out of it.

If you're new to OO or struggling to come to terms with it, you should subscribe to his occasional newsletters. He started this current series with an article about bad OO design and in the second article goes on to examine what "customer" really means which is the heart of OO design (in this example).

The December CFDJ has a great article by Hal Helms about the Decorator design pattern. As usual, Hal combines a bit of story telling with education as he shows how to implement the Decorator design pattern in ColdFusion to solve a real-world problem.

Scott's posted a good summary of what it takes to become OO-savvy. Basically he says: read a lot, think a lot, ask a lot of questions.

I've been having an interesting conversion with Will Spurgeon as he's coming to terms with MVC. Will's done his research - which always impresses me - and in one email, he sent me a bunch of links, mostly on the c2 wiki, which discuss the history of MVC (it originated in Smalltalk) and its bastardization over the years into what we typically call MVC today (since most of us aren't Smalltalk programmers). I'm not going to re-hash the discussion, other than to note that the Smalltalk vision of MVC was notable for two things: the controller was simpler than we're used to today; there was typically a controller for each (complex) view.

Anyway, here's the list of links he sent me - read them through in order and see what you think. I hope it will increase your understanding of MVC:

• What was MVC?
• MVC as a J2EE pattern
• Implementing Smalltalk's MVC pattern
• More on MVC
• MVC really has two models
• MVC is not OO

I the observation that there are really two models at play here is very telling: the underlying model and an inspector-like application model that overlays the basic model.

Interesting article on O'Reilly's onJava.com about Integrating Macromedia Flex with Java. The main points I'd like to highlight are the architectural choices it lays out, showing first of all that you don't want to try to glue Flex on top of an existing MVC presentation layer but rather you need to create a delegate layer to interact with your business model. This echoes what I'm constantly telling people about structuring their applications: make sure your business model is completely independent of your presentation tier so that you can reuse it with different presentation technologies.

Right now it's my one big criticism of both Mach II and Fusebox: they are geared very much toward an HTML presentation tier and it's really not easy to use either framework to build either a Web Services API or integrate it easily with Flash or Flex. Once Blackstone arrives, the pressure will increase because event gateways fit into the same pattern of needing a CFC-based way to interact with the framework - and get a well-defined result back.

Scott Barnes notes that an article in the newspaper giving advice to students who want to become web developers says they should learn several language and be familiar with OO techniques. I agree and I've been saying so for a while. The web has moved on and, as Scott notes, in the early days knowing HTML was enough but these days the web is about more than just simple pages and simple forms - even CSS is easier to understand if you know OO (since CSS has inheritance and overriding etc). Increasingly, web developers are being asked to build more and more complex systems - often exposing ERP or CRM levels of functionality - and these complex systems require better understanding of industry standard best practices... which, realistically, means OO today.

Like it or not, knowing OO principles may help you get a job over someone who doesn't. Web development has grown up.

Scott Barnes highlights a common misconception many developers have about Mach II and their business model - namely that Mach II listeners are a good place to put your "manager" logic. You can do it that way but as Scott point out, that will tie your business model to the framework - and your business model shouldn't know anything about any framework code! It's a good read!

As promised, I have edited the Breeze session from 11/12 into an article along with the gmodeler XML.

What is Data-Driven Design?

This question just popped up on the Fusebox forums but I figured my response there ought to get a wider audience.

Sally Shlaer and Steve Mellor are usually attributed with this approach which focuses on the data an object contains to drive the overall design. It was a relatively early approach to OO analysis and design and things have moved on quite a bit since.

Google turned up this nice little piece about it - see the original webpage (thanks to Scott Taylor for the updated link):

2.1 Responsibility-driven versus data-driven approaches

It is often said that data are more stable than functions and so data-centred approaches are to be preferred in most cases. However, one of the greatest dangers in adopting a method based too much on structured techniques is that of data-driven design. Two software engineers at Boeing (Sharble and Cohen, 1994) conducted an experiment with internal trainees with similar backgrounds. One group was taught the data-driven Shlaer/Mellor method of object-oriented analysis - a method consciously and deeply rooted in traditional entity-relationship modelling - while the other group was instructed in the Responsibility Driven Design techniques of Wirfs-Brock et al. (1990). The two groups were then asked to design a simplified control application for a brewery. The Shlaer-Mellor group produced a design wherein most of the classes represented static data stores while one class accessed these and encapsulated the control rules for most of the application: in much the same style as a main{} routine in C would do. The other group distributed the behaviour much more evenly across their classes. It was seen that this latter approach produced far more reusable classes: classes that could be unplugged from the application and used whole. It also demonstrated vividly that the method you use can influence the outcome profoundly. It is our firm conviction that data-driven methods are dangerous in the hands of the average developer and especially in the hands of someone educated or experienced in the relational tradition. Furthermore, We hold that the approach taken to requirements engineering can have a huge influence.

The study by Sharble and Cohen shows convincingly that data-driven methods do influence the thinking of designers and that they tend to produce un-reusable classes as a consequence. The usual effects are that:

• behaviour is concentrated in controller objects that resemble main routines; this makes systems much harder to maintain due to the amount of knowledge that these controllers store about other objects;
• other objects have few operations and are often equivalent to normalized database tables: not reflective therefore of sound object-oriented design.

In our commercial practice we insist upon or encourage responsibility-driven design and analysis. We will be concerned throughout this text to emphasize this in all we do, just as we shall stress adherence to the basic principles of object technology: encapsulation and inheritance. This is not the pedantic reaction of a purist but a stance of immense practical significance.

Sometimes it's hard to navigate all the acronyms and the design patterns that crop up when people start talking about object-oriented software. Joe Rinehart has written a very highly introduction to Data Access Objects along with an example that shows how a DAO is used with a bean (Transfer Object) to support a single form used for edit / create operations. Nice job Joe!

Last night, a small group of us spent about three hours working on a class diagram to help model a merchant transaction system. Joshua Shaffner came into my Breeze meeting and asked for some advice on a system he was designing. He had used gModeler to create his initial class model but wasn't happy with the relationships between his classes.

I made Joshua a Breeze presenter - his first time! - and he worked on the diagram while we all watched and discussed different design choices with him. Joe Rinehart (East Coast?) and Daniel Brown (New York) were active participants in this design session and also present was David Manriquez from Chile and a couple of others who were not posting so I assume they were away.

I've saved the entire chat log and the final XML from gModeler and will be writing up a more detailed entry of the discussion shortly (probably as its own page, rather than a blog entry).

At the end of the session, folks felt a lightbulb had gone on for them as far as OO modeling is concerned.

Overall, I think it showed the power of Breeze as a collaborative tool as well as just how gosh darned hard this OO design stuff really can be!

Many thanx to Joshua for being a Breeze guinea pig and to Daniel for extreme patience while we were playing devil's advocate and arguing with every suggestion!

Very interesting post on Rob's blog about how to get a handle on design patterns from a ColdFusion point of view. Good collection of links and references too.

Now you might not know much about Inversion of Control and you might not care about the pros and cons of HiveMind, PicoContainer and Spring, but Mike Spille's Pyrasun blog can be very thought-provoking because he speaks - often bluntly - from personal experience with all this stuff.

What I want to draw attention to here is a key point in the conclusion of his Inversion of Control Containers review:

"In particular, I salute Howard for resisting attempts to twist HiveMind into something it's not - a rare quality, particularly in open source. HiveMind does (mostly :-) ) one thing and does it well."

Mike comments that PicoContainer looks like it followed the XP YAGNI (You Ain't Gonna Need It) principle and each new release seems to have haphazardly added those features which - guess what? - you did need them after all. He also comments that "Spring's just a bit took kitchen-sinky for me."

My point? Frameworks work best when they are cohesive, focused. That usually means tightly-controlled rather than being open source free-for-alls and it also usually means that the creator(s) started with a coherent vision of the whole.

So, when you're asking for Fusebox or Mach II to be opened up so y'all can contribute code, think about Mike's comments on why some frameworks work better than others.

My post on Transactional Object Design mentioned a thread on Artima that references a buddy of mine, Kevlin Henney. We got to know each other when I was the editor of Overload, the C++ journal produced by the Association of C & C++ Users and Kevlin wrote for the journal. We also both worked on the UK C++ Standards Committee. Kevlin has written a lot of papers on C++, OO and patterns that I wanted to blog here for reference. He has a great writing style and covers a lot of very interesting topics. Hopefully, what he writes will stretch you in some areas and you'll learn new things - I've certainly learned a lot from Kevlin over the years!

Christopher Diggins provides some food for thought about designing a Bank Account object. The opening premise is that get/set is not appropriate for the balance of the account (shades of "getters/setters considered evil") but the initial proposed solution is also very flawed - as the comments show. Make sure you read the comments on this entry because they highlight some really interesting variants on class API that rely on functions being passed in.

Now, passing functions around as arguments isn't something that might spring to mind for many developers (unless you have a background in functional programming) but it is very powerful. And, guess what, you can do it in ColdFusion!

Yes, if you have a function argument with type="any" you can pass a UDF or a CFC method as an argument and then call the argument (function) that is passed in... I'll leave this as an exercise for you readers but if you get stuck I'll post a follow-up showing some examples!

Scott Hanselman has a great little comparison of REST and SOAP on his blog. This is in response to those folks who think SOAP is overkill and REST is sufficient for inter-application communication. It's the first time I've seen it laid out this clearly and it points up some of the specific benefits of SOAP.

Martin Fowler cautions against overuse of the Data Transfer Object pattern and explains where DTOs can be useful in a non-distributed application.

When I put up some code examples in the Mach II Development Guide that used the Memento pattern as a simple way to pass data between the business layer and the persistence layer, some people assumed that was "the way" and just copied it wholesale. I removed the examples because - whilst they were representative of how certain persistence was done at Macromedia - they were not general best practice.

The same thing is true of DTOs - you'll see them used in relatively simple examples where they really add no benefit and then you'll see them used in code written by people who just copy the examples without learning about the pattern.

As Fowler says, patterns have two equally important parts: how to implement them and when to implement them. Most examples show the how but are not good representations of the when. So make sure you read up on the background of a pattern before you slavish implement it all over your code.

Robin Hilliard has posted a very intriguing example of using mixins with ColdFusion - where he blends multiple components at runtime. It's not quite the classic "mixin" inheritance some OO people know and love (or hate) from C++ but it's clever nonetheless.

The classic "mixin" approach typically starts with an interface and a "common" implementation. Extensions to the model work by extending the interface and then implementing with a single class that also extends the common implementation class. Phew! You get a diamond-shaped inheritance diagram. You can see an extended example of this in part 4 of my compiler writing article (published in "Overload" many years ago).

Anyway, Laurence Middleton posted a comment on Robin's blog which points readers to an newsletter by Hal Helms on implementing Person-Role in ColdFusion. This refers to problems such as Employee-Manager where a lot of people mistakenly try to have Manager extend Employee instead of recognizing that Manager is-a Role and Employee (a Person) has-a Role.

Both Robin's article and Hal's newsletter deserve close reading for the techniques they discuss.

I've done quite a bit of refactoring on the model to simplify the controller and model circuits and encapsulate the article and comment handling in their own circuits. I've also updated the code snapshot.

Ted Neward has a very healthy discussion going on his blog: "What is SOA?"

Is it really something new or is it just a buzzword for stuff we've known about for years?

In the latest (John and Ted, Round 3), John Cavnar Johnson makes a good attempt at defining a "service" (in the comments) which shines more light on the issue than most of what has gone before in the discussion and he shows just how much hype surrounds SOA when he says (in an earlier entry's comment) "I will grant you that much of what passes for SOA today doesn't live up to these principles, but I don't think that invalidates them".

No, I'm not going to rant about it - I'm going to point at someone else's rant...
Ted Neward quotes (with a little additional commentary) a post by Rockford Lhotka about Service-Oriented Architecture. Rockford offers some sanity checkpoints and warns of the potential for a train wreck. He's right that there's certainly too much hype around this topic (as there is around several other 'hot' topics these days). After all, cross-application integration isn't exactly a new concept and, so far, almost every attempt to standardize such integration has failed to deliver fully on the promises made...
Is SOA another case of the emperor's new clothes? In the context of being touted as a 'solution', yes I believe it is. If you treat it as a guiding principle (which, after all, is what an architecture should be), then it makes more sense. In other words, don't expect to buy "an SOA" off-the-shelf - but do expect it to cost you $$$ and be prepared to work hard on your business case. There's ROI to be had if you know what you're doing.

There's a nice article by Alex Bell on ACM Queue called Death by UML Fever which talks about the many inappropriate uses of and attitudes to UML in the real world. It's a nicely humorous article but it makes a serious point: there are no silver bullets so don't get carried away... I've seen several of Alex's 'fevers' over the decade or so that I've been using modeling languages and that's why I tend to stick to using "UML as sketch" (Fowler) rather than doing full formal modeling. UML, in my opinion, should be an enabler not a burden or a regime - it's meant to help you organize, clarify and communicate your thoughts on software system design. It can also be useful documentation for a system (if it is kept up to date).
A recent question on the Mach II forum asked how to model applications with UML and there is, of course, no simple answer to that. The question has cropped up in a different form on the Mach II mailing list: "Can someone share some good examples of UML diagrams for planning my application?". The answer is not simple - what works for one person might not work for another because there is no "one way" to use UML...

After quite a long break, I'm now back in the land of UML pretty much full-time. My initial role at Macromedia was that of Senior Architect for the IT group and, after two and a half years on the Web Technology Group, I'm back in that role so I'm mostly working with the back office enterprise application teams. A key tool in my role as an architect is UML because it provides a consistent notation for describing all aspects of the IT systems, from the smallest interaction within the applications to the overall data flows and system interactions of the enterprise as a whole. UML can even describe the people processes and interactions.
For a long time, my UML tool of choice has been TogetherSoft's Control Center CASE tool. I started using it back in '97 (or early '98) when it was called Together/J. I've introduced it into every company I've worked at since then and for Java developers, it really is an impressive productivity tool - combining full visual (UML) software design with full EJB development and deployment, as well as software metrics and code auditing functionality. I introduced it to Macromedia back when I was part of the original Architecture Team and then the Web Technology Group picked it up to design and develop their applications. In fact, both Flash and ColdFusion developers use it, every day, to help them visualize their OO design.
And now I'm using it again. On a Mac. Even tho' we're still using version 5.5 (we weren't doing enough Java development to make it worthwhile upgrading) which was Windows-only. But it's a Java application and so, likely many pure Java apps, it can be persuaded to run on pretty much anything. I installed it on Windows 2000 using Virtual PC and simply copied the installation back to my Mac file system and tweaked the startup script to match the OS X Java install (the Windows install comes with both .bat and .sh startup scripts).
I'd forgotten how much I enjoyed using UML! I love how consistent the notation is and how you can describe systems at so many different levels, no matter how complex they are. And I love Together Control Center - I've tried a lot of different UML design tools but I keep coming back to this one as the most intuitive and most useful. I particularly like the integration of design patterns and refactoring tools and, when I'm using Java, the code audits and metrics.
TogetherSoft was bought by Borland a while back. You can find out more about the product on Borland's Together Control Center website.

Tony Blake posted a long comment in response to my entry about Ben Forta's thoughts on CFCs and Custom Tags. Tony's comment involves some interesting questions so I figured I'd turn it into a blog entry of its own and add my own thoughts:

Just read your comment on Ben's site. There are certainly cases where custom tags can still be used in Mach-II and Fusebox. I was actually asking whether people felt that by putting business logic into CFCs and common display into customtags, we can get away from using any kind of framework because all the real hard stuff is completely separate.

This raises an interesting question about the nature of frameworks: are they really there to handle the "real hard stuff" in an application design? My sense is, no, they exist to provide a standardized way to structure your application and, to some extent, provide certain common low-level functionality. The "real hard stuff" in my opinion is designing the right (business) model objects.

I used Fusebox 3 when that was common, warts and all, because it seemed quite popular and worked in our case. I'm uncomfortable with Fusebox 4 - even though it is very *very* fast - as the XML syntax just seems really messy. Those condition tags look nasty :), and it doesn't really integrate with CFCs that well. I know it can be done, but doesn't look like a snug fit IMO. I welcome being convinced otherwise.

I'm not going to take on the Fusebox question here except to say that Fusebox 4 seems like a good upgrade path for Fusebox 3 - it provides performance benefits, it replaces the nested layout model with a more flexible system and it clearly delineates what logic should be in the "fusebox" by using a well-defined set of XML commands instead of allowing developers to put arbitrary logic in their switch files. Fusebox (both 3 and 4) work for a lot of people because it provides structure.

Mach-II looks good too, but sometimes feels like an overkill. I don't know if it's really necessary for a web application. However, it works very nicely with CFCs, is buzzword compliant, and seems to becoming the de facto standard.

I'm naturally pleased that some people see Mach II as a developing de facto standard. I'm surprised Tony thinks Mach II is overkill - it's about as lightweight a framework I've seen that still does something useful.

In the Java-world, I used a framework known as Webwork, which is incredibly simple and powerful. It just made sense to me, and I'd recommend anyone doing J2EE development to look at it in place of Struts. I'm really after a CF equivalent.

I hear good things about Webwork but Struts appears to be the de facto standard in the Java world (and increasingly looks very compatible with JSTL and JSF as they emerge). My feeling is that Struts is unnecessarily complex, albeit very powerful. I don't know enough about Webwork to comment on it directly, but I'd say Mach II is substantially less complex than Struts and, from what I've read, about in line with Webwork.

Erm, this is a long post :) but I'm just wondering whether by putting all the business logic in CFCs and with plain old .cfm pages being so simple anyway, is there any benefit with using a framework?

Well, if Webwork provided value because it was a Java framework and, presumably, Fusebox 3 provided value because it was a ColdFusion framework, then I'd say that question is already answered - good frameworks add value and therefore they are worth using (on all but the smallest projects). I find myself using Mach II for pretty much any ColdFusion project now - even simple, "one-off" things - because it provides a simple, standardized structure that allows an application to grow and because it helps reduce coupling between components.

I remind you, this isn't a theoretical question - I have to make a decision soon, so my livelihood depends on the replies! Haha :)

Hopefully, this answer is useful and will draw further answers from other folks as comments on this entry!

As a comment on my MDA entry yesterday, Simon Horwith asked me about "Streamlined Object Modeling" by Nicola, Mayfield and Abney. That led me to search for references to Coad's work on archetypes when I tripped over a list of articles about object modeling by Stephen Palmer of Step 10 Limited. Lots of useful stuff here that will be helpful to folks struggling to get up to speed in the world of OO and UML.

A while back, I was asked, as part of an online interview, what I thought about MDA - Model Driven Architecture. I don't remember my exact answer but I was less than complimentary about it because it seems to be a wonderful academic exercise that really isn't providing an concrete benefits - in fact, it seems to add layers of unnecessary complication at a time when we are already beginning to see a bit of a backlash against some of the layers and practices common in OO programming (e.g., the recent anti-setter/getter sentiments).
Sometimes I feel very wary about dissing something that a lot of very smart people obviously think is a good thing, so I was heartened to read Martin Fowler making somewhat disparaging comments about MDA. Now, I'm quite a fan of CASE tools but only when they genuinely support your development lifecycle and make you more productive - hence my support over the years for Together Control Center with its simultaneous round-trip (re-)engineering for Java code. It's a CASE tool that can be used as a Java IDE. I don't adhere to the manifesto that you need to model everything in your application however and so, like Fowler, I tend to use UML as a sketch. To use MDA effectively seems to mean rigorous modeling with UML which in turn seems overwhelming to me, especially with talk of UML 2, and that just seems to 'price' MDA out of consideration for many folks in the trenches. If you've used MDA successfully, feel free to disagree...

Just as when I converted my site to use Fusebox 3, I have written up my experience of converting the site to use Mach II (and a lot quicker than my last write-up!). Since I did the conversion during a few 'off' hours on New Year's Eve, it should be no surprise that the write up is fairly short and indicates a relatively painless exercise.

N Alex Rupp has written an interesting and critical look at MVC and Servlets that is receiving some lively coverage on TheServerSide.com. His basic point seems to be that we've repeatedly tried to shoehorn the MVC design pattern onto Servlet-based frameworks but the 'fit' isn't really that good. Responses to the article are mixed but coherent. I've seen a similar point raised in the ColdFusion community: namely that MVC isn't always a good fit for web applications because of the nature of the stateless request-response architecture on which they are built. Given the popularity of Mach II and Fusebox (FB4 has an optional MVC skeleton), I think that CFers should read Alex's article (the first of three parts I believe) and the chatter on TheServerSide to temper and inform their adoption of MVC-based frameworks. Yes, there are some issues inherent in applying MVC to web applications but they are not, in my opinion, reason enough for complexity and inflexibility in some application frameworks (criticisms leveled at Struts quite regularly, for example).

Matt Liotta posted an excellent summary of his approach to Rich Internet Application design on the CFCDev mailing list today. He points out that traditional three-tier applications (presentation / business / data) don't really adapt well to Rich Internet Applications because you really need the logic from the business tier spread between your Flash front end and your ColdFusion (or other) back end. He uses a four-tier approach: presentation / business (both in Flash) / services / data (both on the server). His services tier is a generic but high-level set of APIs providing access to data and other, integration-level, services. He says that the service and data tier can be reused between Flash and HTML applications so that you only have to rewrite the presentation and business tiers.
You can refine this architecture somewhat further by splitting the business tier into three more tiers, which I would call: business-presentation, business-facade and business-model. The business-model tier contains the generic business logic for your application (that does not depend in any way on the presentation technology). The business-facade tier provides a Web Services or Flash Remoting interface that exposes key business methods from the business-model tier. The business-presentation tier is in Flash and provides a controller / manager layer for the UI (presentation tier) to use, wrapping the calls to the business-facade tier.
If you need both a Flash version and an HTML version of your application, you can write two presentation tiers (one Flash, one .cfm ColdFusion pages) and two business-presentation tiers (one ActionScript, one Mach II / CFCs) and then reuse the business-facade (CFCs), business-model (CFCs) and lower tiers. If you don't need the RIA, you can collapse the business-presentation tier (Mach II / CFCs) and the business-facade tier (CFCs). It's still worth keeping the business-model tier separate tho' (as discussed in the Mach II Development Guide).
For more information on n-tier architectures, you can read these articles:

• Application Architecture: An N-Tier Approach - Part 1
• Benefits of Using the N-tiered Approach for Web Applications (about ColdFusion)
• Extending Design Patterns into RIA (about Macromedia Flex)
• Macromedia Flash Communication Server MX Application Model