Design of account e-mail activation (with Hibernate in mind)

Answer 1

I would not separate the NotActivatedUser from the ActivatedUser; just have a User table, and have a column for "Activated", defaulting to 0 (not activated).

One thing; I'd split out the activation code to a separate table, perhaps with "ActivationMethod". This allows for extensibility in the future if you want to have a way for a user to activate their account other than email, and also serves the purpose of removing the "activationCode" column from the User table.

I wouldn't worry about unactivated Offices and Companies; according to your usage plans as described above, they shouldn't be able to be used by anyone else until that user activates himself (and therefore the Office and Company). One question; why do you allow a non-activated user to create an Office and Company? Why not restrict that activity to only activated users?

Answer 2

Personally I wouldn't write two classes for activated and non-activated users, because it is just a state. If this state before the activation gets complex, you can reference to a activation state or the like.

If you have a "OfficeOwner" flag on the user, you know when to remove the office without any complex logic.

Answer 3

Using the same table for activated and non-activated users requires you to check the status of the user, as well as that of the offices and companies everywhere in the application.

For that reason I would probably use an activationrequest table with all the information needed to create the user, the office ant the company when the activation is performed.

Answer 4

I would not use inheritance to represent a state (activated/deactivated) of your User objects. Composition (aggregation) is a much better choice here.

By using aggregation, AbstractUser simply becomes User. You may wish to model the Activation with a class instead of polluting the User class with activation related attributes. This way you get a nice and clean object model.

At the database level you can still decide to store the two objects in the same table/record, known as Component mapping. Or you can decide to store User and Activation in separate tables (aka Entity mapping).

Hibernate supports both type of mappings, it's mostly a matter of configuration.

The User class would contain the following attributes:

• givenName
• surname
• email
• activation (reference to an Activation object)

The Activation class would contain the following attributes:

• activationCode (string)
• sentOn (when was the email sent)
• activatedOn (defaults to null, set to current date/time when the user clicks the activation link, tells the system if the user has activated his account when not null)

You could use an HQL Query to know which company has at least one activated user:

from Office o 
   left join fetch o.company 
where 
   o.administrator.activatedOn != null

This query assumes that you have defined an 'administrator' attribute in your Office class. The 'administrator' would be a reference to the User who created the Office. In the database, the 'offices' table has a foreign key to a User record.

By modeling the relationship this way, you may change the Administrator of an Office (example, he left or got fired from the Office/Company). It all depends on your use cases ...

I also added a sentOn attribute to the Activation class used to cleanup inactivated account after a certain time (was missing in your UML diagram).