I have done this from time to time as well (simply using FK ids rather than creating relationships in Transfer), and as a sole developer I have not run into any problems with confusion over what is a relationship and what isn't... yet. Perhaps it's because I have only done this in certain situations for specific reasons, so it's not that hard to keep track of.
An example of when I've done this is the Product object in a large online catalog. This Product has dozens of attributes that are actually foreign keys to "lookup" tables. I didn't really want to treat each of those lookup objects as full-fledged objects as I don't see any value in that. They are never actually used for anything on their own. When an administrator is editing a product, each of those properties is always set via an id (chosen from a select box by the user), so I didn't want to complicate what is essentially just a simple single table insert by introducing dozens of relationships that Transfer would have to deal with. For output, I have taken a mixed approach, which involves 2 techniques neither of which would probably be palatable to OO "purists", but I find work very well for me from a practical standpoint: One is to simply use queries which access a view that has the product table and all of it's "lookup" tables joined. The other technique involves using a ValueListService/ValueListGateway that I use to interact with all of these "lookup" objects. The single service allows me to manage all of the objects (i.e., CRUD) and also contains a cache of all of the values, which makes lookups very easy and quick. This allows me to look up the description that corresponds to a given "lookup" object from within a service and/or decorator. For example, the Product object has a property called "DensityTypeId", which is an FK that is treated as a property rather than a relationship. I have a method in my decorator called getDensityTypeDesc, which uses the ValueListService to return the description that corresponds to the current DensityTypeId. So I can treat it (the Product) as one big object from any code that utilizes the Product object. I wrote this whole ValueList thing quite a long time ago, and it does some other cool things too, but I can see now how it is really a bit of a "hack" that moves away from a truly object oriented approach, but from a practical approach it works quite well and has not caused me any grief from a maintainability perspective... yet. Cheers, Bob On Sun, Jan 11, 2009 at 8:24 AM, Nando <[email protected]> wrote: > Jared, > > You point is quite valid, something I hadn't fully appreciated until you > brought it up. I'm wondering if it would be possible to use decorator > methods to cover get/setProperty methods that go MIA when someone decides to > convert them to a relationship, rather than go digging in the codebase. I'm > not good enough thinking in the abstract with Transfer, so I would need to > try it to see how it worked in practice, but I thought I'd throw the idea > out here. > > On Sun, Jan 11, 2009 at 4:57 AM, Jared Rypka-Hauer <[email protected]> > wrote: >> >> Nando, >> We've done very much the same thing in most cases... however it has lead >> to conflicts and confusion in some cases because things like <property >> name="userID" /> were reasonably converted to relationships and broke other >> code that had to then be fixed. This was in part because there's more than >> one dev on this project and it's our first major project with Transfer, so >> we had some of our own kinks to work out. OTOH, even working on your own it >> can be really hard to remember which properties you used as properties and >> which ones you are converting to relationships as you get further and >> further in. >> So I guess I'd suggest a similar approach with the proviso that you need >> to document which properties are "safe" as relationships and which ones >> aren't... >> J >> On Jan 9, 2009, at 5:28 AM, Nando wrote: >> >> I might have something to add to this discussion in regards to taking a >> practical approach toward relationships in Transfer. >> >> I'm working on quite a complex application where I could construct a >> variety of very complex relationships in Transfer - if I decided that every >> relationship in the application should be modeled in Transfer. But that's >> not how I'm handling it. Instead, I'm only constructing the relationships >> that I need to handle a particular transaction with the database in >> Transfer. ... >> > > > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > [email protected] > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" 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/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
