Hi Greg,
On Nov 7, 2006, at 9:54 AM, Greg Ederer wrote:
> Hi Craig,
>
> Thanks for the advice. This is essentially what I'm doing. I have
> created classes called CustomerNature, VendorNature, AuthorNature,
> and so on. These classes extend an AppUserNaturebase class.
The thing to watch out for here is not to use AppUserNature in your
persistence coding. This is to avoid artificial constraints on the
relational mapping, i.e. requiring a table for the persistent fields
in AppUserNature.
For example, don't try to implement the references from User to the
others via a Map<String, AppUserNature> or you might run into
performance issues. If you keep AppUserNature as an abstract class
and implement the persistent fields and methods in the subclasses you
should be ok.
> My AppUser class has methods addNature(AppUserNature a), getNature
> (String className) and hasNature(String className).
>
> (This is probably an established design pattern. But, I don't know
> what it's called. Anyone know?)
User is a Composite. The way you interact with a User could be a Facade.
>
> Navigating the resulting web of objects can be a bit cumbersome.
> But, this may just be the best way.
You can hide the complexity of navigation via a Facade pattern that
exposes the behavior you want while hiding the implementation.
Regards,
Craig
>
> Again, thanks.
>
> Cheers,
>
> Greg
>
> Craig L Russell wrote:
>> Hi Greg,
>>
>> Consider domain classes User, Customer, Vendor. User has a 1:0..1
>> relationship with Customer and Vendor (a Customer must have a User
>> but a User might not have a Customer). You can navigate from
>> Customer and Vendor to the corresponding User instance. You can
>> navigate from User to Customer and Vendor (might be null in the
>> object model).
>>
>> Represent each of User, Customer, and Vendor with its own table.
>> Customer and Vendor have a non-null foreign key to User table.
>>
>> Craig
>>
>> On Nov 7, 2006, at 8:54 AM, Greg Ederer wrote:
>>
>>> Hi,
>>>
>>> I am building a system that has various kinds of users. All
>>> users have first and last names, a username and a password.
>>> Customer users have a shopping cart and orders; vendor users have
>>> products and commissions, author users have articles; et cetera.
>>> Any user can be more than one kind of user; e.g., an author can
>>> also be a customer and a vendor all at the same time. What is
>>> the best way to architect this using JPA?
>>>
>>> Thanks in advance for any suggestions.
>>>
>>> Cheers,
>>>
>>> Greg
>>> --
>>> | E R G O N O S I S
>>> | Greg Ederer
>>> | Lead Developer
>>> | greg_at_ergonosis.com
>>> | 360.379.1157
>>> |
>>> | OpenDocument - OK
>>> |
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell_at_sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
> --
> | E R G O N O S I S
> | Greg Ederer
> | Lead Developer
> | greg_at_ergonosis.com
> | 360.379.1157
> |
> | OpenDocument - OK
> |
>
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s