Has anyone here used CFB to generate CFCs for database tables?

Hi, BKBK, thanks for your reply.

Yeah, I'm none too keen on them, either.  Seems like it's complex for the sake of complexity.  My opinion is the same for MVCs, like FuseBox.  But I can at least work with FuseBox.  This is completely out of control.

I've been trying to refactor the code, but I'm second-guessing myself.  The database that I'm working with has about twenty tables, each of which now has a Bean, Dao, DocGateway, and a Gateway CFC in the components folder.  Trying to do a site-wide FIND for TCID has found over 160 instances.  In the pages that were human-coded, going through and making the change is simple.  But for the CFB CFCs.. (shudder, cringe).

V/r,

^ _ ^

I last worked with automatically generated CFCs, DAOs and Gateways more than 10 years ago. Some colleagues were keen about them; I wasn't.

What I remember from that experience was:

• machine-generated CFCs had the advantage of speed and a low entry barrier. A ColdFusion beginner could create a battery of CFCs, and get a data-based application off the ground in seconds. But that came at a cost;
• the CFCs got too complex too quickly; automation churned out an inordinate amount of code and documentation, even for small database tables having a handful of columns;
• errors in the machine-generated code were hard to debug.

Each of the Data Access Objects and Gateways you mention is, in software design terms, just a gateway. That is, an abstraction between the database layer and the business (CFC) layer. The gateway ensures separation-of-concerns between the database (SQL, queries, database connections, etc.) and the business (CFCs, classes, entities, etc.).

That is what the book says, and it's what we all want. But designing blocks of code that implement separation-of-concerns is hard to do. In practice, most implementations end up only halfway there. Some concerns are separated, hence decoupled, while parts of the database, gateway and business code are coupled.

So, my suggestion is to look for those parts of the code that are coupled. Then proceed to decouple them by refactoring the code.

For example, was the old ID derived from concepts that are particular to the business code, but that overarch to the gateway and database? If so, you might resolve the problem by refactoring using two new IDs. One between business and gateway/DAO, the other between gateway/DAO and the database.