This content has been marked as final. Show 4 replies
> I have always thought that the get/set methods of a CFC would correspond
> to the database columns.
At the DAO level of things, yes, perhaps.
At the object level of things, the object should be completely ignorant of
how the data is stored (and the structure of that storage; normalised
tables, etc), and vagaries of that storage should not be reflected in the
Well that's the theory. Often the pratice is a bit blurrier than that :-)
Do you understand the difference between an ER (entity relationship) diagram, and a physical database schema? An ER diagram is supposed to be a high-level representation of the conceptual entities in a system, and how they relate to one another. On the other hand, a physical database schema is a lower-level diagram of the objects (tables, sequences, triggers, functions, procedures, etc) that are used in the physical implementation of those entities represented in the ER diagram.
That being said - you should really think of DAOs as "entity interfaces", rather than "database table interfaces". A well-designed DAO should provide enough abstraction that the caller (user/client) of the DAO doesn't need to know or understand how the entity is physically modeled in the database.
So for example, if you have "Jobs" physically implemented in one table, and "Job Types" physically implemented in another table (which is very common), than your DAO should abstract that out, and represent "jobType" as a attribute of the "job" entity since that's really what you're representing in the physical data model. The only reason job-types are physically implemented in a seperate table is to enforce data integrity, and normalize the data in your database. But from an higher-level, entity perspective, "job type" is not necessarily a seperate entity, but rather, an attribute of a "job" entity.
I hope this makes some sense. If you're interested in some further reason, this would be a good place to start:
The problem is I want to display the actual "Job Type" not the JobTypeId obviously. Job Type is not a property of the Job Object, only JobTypeId is.
As others have mentioned, it might not be necessary to be that particular. However, if you insist, you could cut it as follows. Create a JobType object, and also its own DAO. Then, in place of the JobTypeId, make instead the JobType object an attribute of Job. Use an instance of the attribute to do things like objJobType.getJobTypeId() and objJobType.getJobType(int jobTypeId).
Thanks for all the great replies. Everything you guys said makes good sense. Someone in another forum mentioned that Transfer ORM might be worth exploring. Have any of you used that or heard of it?
@BKBK, I do like idea, I believe what you mentioned here is called Object Composition, so for example a Customer Object could also contain an "Address Object", I would love to see an example of hows this is coded out. I think it would be nice to have this.