Hi Mark thanks for your response. Yes this is a custom framework that
is modelled off the Bean/DAO/Gateway principles. I guess in general
when setting up new entity beans i will base them off a database
entity, much the same way Hibernate would perform the mapping so an
entity property corresponds to a table field, and many-to-many
relationships will be handled by an array of object instances against
the entity.

I guess my main issue arises when some tables may have many reference
data fields for very simple id/name style tables. Ie in my current
project, and Event table will contain up to 8 foreign keys for things
like EventContactId, EventTypeId, EventLocationId, EventOrganiserId
etc... So the lazy way would be to just add additional getter/setter
methods for the displayname of each of these properties so I would end
up with. getEventContactName(), getEventTypeName() and so on. This way
avoids additional gateway calls and removes the object coupling,
however it seems like i'm just creating unncessary properties for the
Object purely to assist my output at the View layer.

Cheers
Phil

On Dec 1, 3:11 pm, Mark Mandel <[email protected]> wrote:
> Phil,
>
> You using ORM, or you writing this yourself?
>
> Generally, you don't expose your foreign keys in your model as that is
> Relational data, as opposed to Object data.
>
> Academically when building an OO model, you want to model real world
> objects, so injecting relational data really steps away from that.
> (Obviously there are pragmatic reasons to do this at times, however).
>
> Generally speaking, yes, you would set up your objects to have
> relationships, so as you rightly described below, you would have a
> user.getType().getName() style API on your User object.
>
> Hope that helps.
>
> Mark
>
>
>
>
>
>
>
>
>
> On Wed, Dec 1, 2010 at 1:55 PM, Phil Rasmussen <[email protected]> wrote:
> > Hi Everyone,
>
> > Just wondering what the best practices were when it comes to
> > displaying friendly names of foreign key based values in an Entity
> > Bean at the View layer. So lets say for example I have a User bean
> > with all the standard getter/setter methods for id/name/dob/age etc,
> > but I also have a UserTypeId property which is stored as an ID value
> > only corresponding to the foreign key "variables.instance.usertypeid"
>
> > Now i will obviously have a getter and setter for getUserTypeId and
> > setUserTypeId, however at the View layer i also want to display the
> > actual User Type name somewhere, and I don't like the idea of making
> > additional Gateway calls just to grab a single name value? I've read
> > that some people will create objects out of all reference data such as
> > having a UserType object which is stored against the User directly,
> > and I can then output the name by writing
> > #objUser.getUserType.getName()# for example.
>
> > I seem to run into this issue a lot as the bigger the Entity bean the
> > more foreign key references will usually exist and somewhere at the
> > View layer i need to get the user friendly name value and display it.
> > Would love to hear what others are doing with regards to this?
>
> > Cheers
> > Phil
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "cfaussie" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<cfaussie%[email protected] 
> > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/cfaussie?hl=en.
>
> --
> E: [email protected]
> T:http://www.twitter.com/neurotic
> W:www.compoundtheory.com
>
> cf.Objective(ANZ) - Nov 18, 19 - Melbourne 
> Australiahttp://www.cfobjective.com.au
>
> Hands-on ColdFusion ORM Trainingwww.ColdFusionOrmTraining.com

-- 
You received this message because you are subscribed to the Google Groups 
"cfaussie" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/cfaussie?hl=en.

Reply via email to