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@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@sun.com

P.S. A good JDO? O, Gasp!

-- 

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@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@sun.com

P.S. A good JDO? O, Gasp!

-- 

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@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@sun.com

P.S. A good JDO? O, Gasp!

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@ergonosis.com
| 360.379.1157
| 
| OpenDocument - OK
|