Hi Greg,
On Nov 7, 2006, at 12:15 PM, Greg Ederer wrote:
> Hi Craig,
>
> Greatly appreciate your input.
>> 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.
>>
> Here is my current implementation of AppUser.getNature():
>
> public AppUserNature getNature(String name)
> {
> Class clazz = null;
> try
> {
> clazz = Class.forName(name);
> }
> catch (ClassNotFoundException ex)
> {
> return null;
> }
>
> for(AppUserNature nature : this.natures)
> {
> if(clazz.isInstance(nature))
> {
> return nature;
> }
> }
>
> return null;
> }
>
> Is this likely to cause performance problems?
I believe so. The issue comes to how you define the natures
persistent field. If you have a finite, known set of natures, then
it's probably best to define a field per nature and go directly to
it. The way I assume you defined natures (Set<AppUserNature>
natures;) the persistence layer needs to have some way to query and
join all the natures tables, which will in itself be inefficient.
>
> AppUserNature has id, appUser, enabled and createdDate properties,
> which are common to all subclasses. Should I declare AppUserNature
> abstract, and I move the implementation of these properties (and
> related methods) into the subclasses?
That's what I'd do.
>
> If I move all of these properties into the concrete subclasses,
> would it be just as well to make AppUserNature an interface rather
> than an abstract class (not sure if JPA supports this) and simply
> implement the interface in the concrete classes?
Again, I'd hide AppUserNature from the persistence layer. Either
making it an interface or an abstract class would do the trick.
Craig
>
> Again, thanks for the help.
>
> Cheers,
>
> Greg
>
>>> 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!
>>
>
>
> --
> | 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