In short, my humble opinion is that any CFC is a "Bean" as long as it follows two simple rules:

<ol>
  <li>All member variables are kept private, living in the variables scope.</li>
  <li>Members are accessed only through methods named "get[MemberName]" and "set[MemberName]."</li>  
</ol>

That's it.  

What's nice about this loose of a definition is that it doesn't mean that only CFCs like Contact with Get/SetFirstname() and Get/SetLastname() are beans.  Many things can be beans:  service facades, Model-Glue Controllers, Mach-II Listeners, and even DAOs can act as beans.  

<strong>A Simple Example</strong>

"How's this," you say?  "Isn't a Bean just like a structure on steroids, good for representing a database table?"

"No," I say, "a Bean is any CFC that implements the two rules:  private member variables accessed through Get/Set pairs."

"Why's this cool," you ask?  

It provides a convention through which things like frameworks can rely upon to make your life easier.

For one, it lets Mach-II and Model-Glue developers utilize "Event Beans" to collect user-entered data.  If you used something that didn't act like a bean, and instead used the Set/GetValue() style to collect a Contact's information, you'd have code in a Model-Glue Controller looking a lot like this:

<div class="code"><FONT COLOR=MAROON>&lt;cfset contact = createObject(<FONT COLOR=BLUE>"component"</FONT>, <FONT COLOR=BLUE>"myapp.model.Contact"</FONT>).init() /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"firstname"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"firstname"</FONT>)) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"lastname"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"lastname"</FONT>)) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"address"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"address"</FONT>)) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"city"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"city"</FONT>)) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"state"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"state"</FONT>)) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset contact.setValue(<FONT COLOR=BLUE>"zip"</FONT>, arguments.event.getValue(<FONT COLOR=BLUE>"zip"</FONT>)) /&gt;</FONT></div>

That gets ugly if you've got a lot of data.

Instead, if we force Contact to conform to the Bean pattern, Model-Glue/Mach-II can predict the names of specific Get/Set methods, see if those methods exist, and try to automatically populate your bean.  In Model-Glue, we'd replace the above code with this:

<div class="code"><FONT COLOR=MAROON>&lt;cfset contact = arguments.event.makeEventBean(<FONT COLOR=BLUE>"myapp.model.Contact"</FONT>) /&gt;</FONT></div>

A lot easier!

<strong>Getting More Complex:  Beans, Model-Glue, ColdSpring, and "Autowiring"</strong>

For something more complex, let's examine the typical Model-Glue constructor for managing a table called SomeTable.  It'd probably have a constructor a lot like this:

<div class="code"><FONT COLOR=GRAY><I>&lt;!--- Some attributes omitted for clarity ---&gt;</I></FONT><br>
<FONT COLOR=MAROON>&lt;cffunction name=<FONT COLOR=BLUE>"Init"</FONT>&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfargument name=<FONT COLOR=BLUE>"ModelGlue"</FONT> /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfargument name=<FONT COLOR=BLUE>"InstanceName"</FONT> /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset var datasource = <FONT COLOR=BLUE>""</FONT> /&gt;</FONT><br>
<br>
  <FONT COLOR=GRAY><I>&lt;!--- Init the base ModelGlue.Core.Controller we extend ---&gt;</I></FONT><br>
  <FONT COLOR=MAROON>&lt;cfset super.Init(arguments.ModelGlue) /&gt;</FONT><br>
<br>
  <FONT COLOR=GRAY><I>&lt;!--- Set up DAO and Gateway Factories ---&gt;</I></FONT><br>
  <FONT COLOR=MAROON>&lt;cfset <br>
datasource = getModelGlue().getConfigBean(<FONT COLOR=BLUE>"datasource"</FONT>) /&gt;</FONT><br>
<br>
  <FONT COLOR=MAROON>&lt;cfset variables._daoFactory = createObject(<FONT COLOR=BLUE>"component"</FONT>, <FONT COLOR=BLUE>"myapp.model.data.daoFactory"</FONT>).init(datasource) /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset variables._gatewayFactory = createObject(<FONT COLOR=BLUE>"component"</FONT>, <FONT COLOR=BLUE>"myapp.model.data.gatewayFactory"</FONT>).init(datasource) /&gt;</FONT><br>
<br>
  <FONT COLOR=MAROON>&lt;cfreturn this /&gt;</FONT><br>
<FONT COLOR=MAROON>&lt;/cffunction&gt;</FONT></div>

That's some ugly, repetitive code that you have to add to each controller.

If we decide that, instead of building the DAO and Gateway factories manually in the controller, we'll allow them to be set Bean-style (through methods named setDAOFactory() and setGatewayFactory() ), we have an understood contract through which something else can do the work for us.

In Model-Glue, that something else is ColdSpring;  Model-Glue's ColdSpring adapter knows to look for methods on your Controller named set[BeanId/Type] and then to "autowire" appropriately named/typed beans it knows about in the ColdSpring.xml file.

Again, by relying on the Get/Set convention that's the heart of the ColdFusion "Bean" pattern, a framework can do a lot of legwork for us.

So, we can ditch the constructor altogether, and simply add two methods:

<div class="code"><FONT COLOR=MAROON>&lt;cffunction name=<FONT COLOR=BLUE>"setDAOFactory"</FONT>&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfargument name=<FONT COLOR=BLUE>"DAOFactory"</FONT> /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset variables._daoFactory = arguments.daoFactory /&gt;</FONT><br>
<FONT COLOR=MAROON>&lt;/cffunction&gt;</FONT><br>
<br>
<FONT COLOR=MAROON>&lt;cffunction name=<FONT COLOR=BLUE>"setGatewayFactory"</FONT>&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfargument name=<FONT COLOR=BLUE>"GatewayFactory"</FONT> /&gt;</FONT><br>
  <FONT COLOR=MAROON>&lt;cfset variables._gatewayFactory = arguments.gatewayFactory/&gt;</FONT><br>
<FONT COLOR=MAROON>&lt;/cffunction&gt;</FONT></div>

Now, when Model-Glue loads your controller, it'll hand the Controller instance to ColdSpring, and ColdSpring will collect all methods named set[something], and if it contains a definition for a bean (see, there it is again!) called [something], it'll call the set[something] method.

In English, I'd set up the DAOFactory in the Coldspring XML file, then Model-Glue would automagically "autowire" the DAOFactory to the Controller the moment Model-Glue starts.

<strong>Conclusion</strong>

Following the convention of get/set pairs means some extra typing up front, but with tools like Model-Glue, Mach-II, and ColdSpring all providing utilities that leverage this convention, the time saved writing and maintaining application code is well worth it!