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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
