CFC question

[WestSide]

Hi,

I have a CFC that has basic get/set methods. In the init method you can pass in a jobId and it will call a DAO and populate the Job Object. In the database the table "Job" contains a column called "jobTypeId". This column essentially is a property of the Job Object. When I populate the job object I just get a numerical value for JobTypeId which makes sense, because I have a lookup table that actually stores the various job types. So when a user clicks edit job, I pass the jobId in and when it comes back the Job object is populated. So in my edit form I have the following code:

<table width="400" border="1" cellspacing="0" cellpadding="3">
<tr>
<td>Job Code:</td>
<td>#objJob.getJobCode()#</td>
</tr>
<tr>
<td>Job Title:</td>
<td>#objJob.getJobTitle()#</td>
</tr>
<tr>
<td>Job Type:</td>
<td>#objJob.getJobTypeId()#</td>
</tr>
</table>

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.

Is it best practice to just add another property to the CFC called "Job Type" ??? I have always thought that the get/set methods of a CFC would correspond to the database columns.

Hope this makes sense.

-westside

[Newsgroup_User]

> 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
object.

Well that's the theory. Often the pratice is a bit blurrier than that :-)

--
Adam

[Grizzly9279]

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:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

[WestSide]

Hi,

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.

Thanks,

-Westside

[BKBK]

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).