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

[WolfShade]

Hello, all,

We had a lead developer, here, who used CFB to generate CFCs for the database tables of a project, and actually used them.  But there has been a change to the way part of this app is going to work, and it involves editing this Celtic-knot cluster to fix.  Basically we are switching from using an old ID to a new ID for authentication, processing, accessing, etc.

I thought that I could just remove references in code to the old ID and add the new ID, but without even testing it, I suspect I'm going down the wrong path.  Any insight into how I can get this accomplished would be greatly appreciated.

Basically, I don't know/understand how all of the {tablename}Dao, {tablename}Gateway, and others interact.  Please advise.

V/r,

^ _ ^

[BKBK]

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.

[WolfShade]

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,

^ _ ^

[BKBK]

Ah, I see: change! Someone once said it is the constant factor.

Challenging.

Suggestion:

I would refactor the CFCs, one by one, as follows. Create for each CFC a child CFC that extends it.

The parts of the parent CFC that have remained the same, or that will likely remain the same in future, stay, untouched. The parts that change or will likely change are moved to the child CFC. 

Not my idea. Just borrowing from Bertrand Meyer.