Phil, Assuming you need to stick to the current architecture, I would suggest a super pragmatic approach like:
#application.someLookupHelperService.getLookUpDesc( "userType", objUser.getUserTypeId() )# Obviously someLookupHelperService contains referenced tables (structure) as private members, and it is cached. I personally prefer to objUser.getUserType().getName() approach if possible though. Cheers, Terry On 2 December 2010 15:22, Phil Rasmussen <[email protected]> wrote: > Yeah look i understand what you are saying about ORM, but our > applications just aren't built that way and the DAO/Entity beans are > more like a direct mapping to the entity tables. The Event does have > all those properties you have specified, except they are not stored as > objects themselves so i currently use getter/setter methods for > handling that additional information. I guess once a related entity is > over a couple of fields in size i will create an object structure out > of it and then store that object reference against the parent. > > My initial question was more along the lines of how are other people > dealing with simple reference data against objects and displaying this > information on the frontend. > > Thanks anyways. > Phil > > On Dec 2, 2:27 pm, Mark Mandel <[email protected]> wrote: >> 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] >> > > > om> >> > <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] >> > 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. > > -- 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.
