[Seaside] Smalltalk design advice - how to implement genericbi-directional pointers?

[Ch Lamprecht]

Ramon Leon wrote:

> However, a better solution, one that relies on real code and not dnu, is to
> stop thinking objects are relational tables and start thinking in objects.
> Rooms don't know what house they're in, tires don't know what car they're
> on, products don't know what basket they're in, line items don't know what
> order they belong to.  They don't need to, because if you have access to a
> room/tire/product/line item, it's because you already have the
> house/car/basket/order object.  The house/car/basket/order is the aggregate
> root, it's the meaningful object. It's composite parts are only interesting
> in relation to their parent and ideally only accessible through their
> parent.  
> 
> Other objects should not reference the children of an aggregate, only the
> aggregate itself.  This being the case, they don't need to know how their
> parent is.  They're actually more composeable and better objects when they
> don't.  I should be able to remove a room/tire/product/line item from one
> house/car/basket/order object and put it into another house/car/basket/order
> object without any weird side effects like on of them pointing to the wrong
> parent.  
> 
> Objects are not tables and bi-directional relationships, in general, are not
> desirable.

Hello,

sorry if it gets too far OT for this list. Also the 'beginners' list might be
more appropriate for me to post on... However, I am making up my mind about this
for quite some time now, and maybe I can get some clues here.
Given the examples above, I understand your point. But thinking of the following
I don't see an obvious solution:
Let's say I have employees and projects where each employee might work on many
projects and each project has many employees working on it. Now in a RDB I
would have three tables one for each projects/employees and a linking table for
the m:n relationship, possibly containing details of the association.
Users of my application would expect to be able to search for all the employees
working on a given project and vice versa.
Trying to find an OO model to represent this, I end up with three Classes that 
correspond to the three tables mentioned above ( maybe this is wrong already??). 
Each of the project/employee instances would hold a collection of association 
objects. Each association object would have instance vars to reference a project 
and an employee. But that way I would have bidirectional links on both sides of 
the association object...
I could avoid the collections of associations in employee/project and create 
class-side methods in the association class instead answering collections of 
associations referencing a given employee (or project). But that seems even 
worse  to me - like simulating a database table.

I would be very thankful if anybody could point me into a better direction, ( or 
recommend some books to read )

Regards, Christoph