Thanks Jaime, I'm glad to hear that the idea is sound, but I'll also heed your advice and leave it alone for now. I'll let Mark figure out how best to crack this nut ;-)
Cheers, Bob On Wed, Mar 4, 2009 at 5:58 PM, Jaime Metcher <jmetc...@gmail.com> wrote: > Bob, > > That sounds about right. Essentially you are providing the same gateway/DAO > functionality that Transfer would normally provide, but you're having to do > it manually. You might consider giving your new class a similar API to > Transfer, but that would be a considered trade-off of API convenience vs > ease of implementation. > > The main thing to emphasise at this point, however, is a healthy dose of > pragmatism. You really are straying into "write your own ORM" territory > here, so I'd advocate doing the minimum that works and then waiting for > Transfer to evolve as far as supporting inheritance. It's also a real > uphill struggle to really abstract database tables into collections in > ColdFusion, so while thinking in terms of collection semantics is really > useful while modelling, the practical implementation in CF is often quite > different. > > Jaime > > On Thu, Mar 5, 2009 at 12:36 AM, Bob Silverberg <bob.silverb...@gmail.com> > wrote: >> >> Jaime, >> >> Ah, I understand. In my experiment I hadn't considered collections of >> employees. I had just assumed that there was no such thing as an >> employee object - only analyst, designer, etc, which I think remains >> true when we're talking about individual objects, but yes, it falls >> apart when you need to deal with a collection of employees. >> >> I did envision that a Department, for example, would have a collection >> of Analysts, a collection of Designers, etc. But didn't think about >> having a general collection of all employees. Good catch. It >> definitely shows my lack of experience with working with object >> models. >> >> I may be way off base here, but thinking about this, it seems like >> what is needed is some sort of EmployeeCollection object. Something >> that has the smarts built into it to understand that an >> EmployeeCollection is a collection of all of the possible employee >> subtypes. If it were possible to build that, then maybe it could be >> used in the following situations: >> >> - If I want to ask for an employee by name, I can ask the >> EmployeeCollection for it. In that case I would inject the >> EmployeeCollection into my EmployeeGateway, as that's where all of >> that logic is centralized anyway. I'd still have the issue of not >> knowing which employee type I've gotten in return, but that can easily >> be checked. >> - If a department needs a list of employees, it could have the >> EmployeeCollection injected into it. >> >> It _does_ sound a bit ugly, and would definitely require some >> handcoding of certain decorators to make it all work, but also sounds >> like it might work. >> >> Does that approach make any sense? Would that address all of the >> collection issues of which you speak? >> >> Bob >> >> >> On Wed, Mar 4, 2009 at 3:28 AM, Jaime Metcher <jmetc...@gmail.com> wrote: >> > Bob, >> > >> > Having no mapping for the Employee class means the ORM can't hand you a >> > collection of Employees. If you wanted such a beast, you'd need combine >> > the >> > collections of all the subclasses. The common Employee.cfc superclass >> > gives >> > you common instance logic, but not common collection logic. >> > >> > Another example - I know I have an employee called Bob, how do I load >> > his >> > record as an object? The naive approach is to ask the ORM to load >> > employee >> > where name = Bob. In some ORMs, we can do exactly that. Without a >> > mapped >> > superclass, however, we have to either hand-code a query to hit the >> > employee >> > table, grab an ID and a type, then ask the ORM to load an instance of >> > that >> > type, or iterate over all the subclasses asking the ORM for "Bob" for >> > each >> > of them until we find Bob. >> > >> > None of this is onerous in practice, but it's definitely part of the >> > impedance mismatch. >> > >> > Jaime >> > >> > >> > On Mon, Mar 2, 2009 at 11:24 PM, Bob Silverberg >> > <bob.silverb...@gmail.com> >> > wrote: >> >> >> >> I think that this addresses the issue of behaviour that is common to >> >> all Employees, so I'm not sure what you mean when you say: "but you >> >> then need to hand-code anything that relates to all employees". Could >> >> you elaborate on that? >> >> >> >> Thanks, >> >> Bob >> >> >> >> >> > >> > >> > > >> > >> >> >> >> -- >> Bob Silverberg >> www.silverwareconsulting.com >> >> > > > > > -- 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
