I guess the point here is - if you were using an ORM, you would build relationships, so you wouldn't expose the FK data.
Again, Objects aren't simply a way to expose relational data - the idea behind OO is to represent real world objects. So your Event should have a Location, and have an Organiser, much like it would do in the real world. Good luck! Mark On Thu, Dec 2, 2010 at 2:11 PM, Phil Rasmussen <[email protected]> wrote: > 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]> > <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]<cfaussie%[email protected]> > . > 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 Australia http://www.cfobjective.com.au Hands-on ColdFusion ORM Training www.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.
