アカウントの電子メールアクティベーションの設計（Hibernateを念頭に置いて）

Question

私はいくつかの入力を希望します。

1. アカウントを登録するには、各ユーザーに電子メールアドレスが必要です。ユーザーアカウントを登録するときは、アカウントを有効にするために必要なアクティベーションコードを含むアクティベーションEメールを送信する必要があります。
2. 各ユーザーアカウントは、正確に1つの会社に存在する1つのオフィスにのみ存在します。
3. 会社の最初の登録ユーザーは、会社と1つのオフィスを作成します。残りの企業ユーザは、最初のユーザによって招待されます。
4. 企業は相互にやりとりすることができますが、会社の最初のユーザーがアクティブ化されている（登録後にそれぞれのアクティベーションリンクをクリックした）場合のみです。ここ

解決することができる方法の小UMLダイアグラムである：上記の図で

alt text http://i43.tinypic.com/2dj5bhh.png

いくつかの詳細が省略されています。この図はクラスとフィールドのみを示しています。フィールドになると、概念的にどの情報を格納するかを示すために使用されますが、その範囲を無視してください。

いくつかの考えや質問：

• ユーザーとNotActivatedUserはほとんど同じです。彼らは1つのクラスでなければならないのでしょうか？それらが分離されている場合、どのような形のHibernate継承永続性を使用しますか？
• アカウントが特定の時間の後にアクティブ化されない場合は、アカウントを削除する必要があります。それが最初のユーザーであった場合は、ユーザーと会社も作成されています。これらの両方を削除する必要があります。 NotActivatedOfficeとNotActivatedCompanyも必要ですか？ （データベース内の完全な分離のため）

このようなソリューションをどのように設計しますか？アクティブでないアクティブなエンティティをデータベース内で別々のものにすることは重要だと思いますか？なぜ、なぜそうではないのですか？

Answer 1

ユーザーオブジェクトの状態（アクティブ化/非アクティブ化）を表すために継承を使用しません。組成（集約）はここでははるかに良い選択です。

集約を使用することによって、AbstractUserは単にUserになります。アクティベーションに関連する属性を持つUserクラスを汚染する代わりに、クラスを使用してアクティベーションをモデル化することをお勧めします。このようにして、素敵できれいなオブジェクトモデルが得られます。それでもComponent mappingとして知られている同じテーブル/レコードで2つのオブジェクトを格納するために決定することができ、データベースレベルで

。あるいは、ユーザーとアクティベーションを別々のテーブル（別名Entity mapping）に保存することもできます。

Hibernateは、両方のタイプのマッピングをサポートしています。ほとんどの場合、設定の問題です。

Userクラスは、以下の属性を含むであろう：

• givenName属性
• 姓
• メール
• 活性化（アクティベーションオブジェクトへの参照）

活性化クラスが含まれているであろう次の属性：

ユーザが起動した場合

• activationCode（列）
• は（電子メールが送信された）sentOn
• activatedOn（ユーザが起動リンクをクリックすると、現在の日付/時刻に設定NULLデフォルトは、システムに指示します自分のアカウントあなたは、少なくとも1人の活性化されたユーザーを持つ企業を知るためにHQLクエリを使用することができないときはヌル）

：

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

このクエリをyと仮定しあなたのOfficeクラスに '管理者'属性が定義されています。 「管理者」は、Officeを作成したユーザーへの参照です。データベースでは、 'offices'テーブルにUserレコードに対する外部キーがあります。

が関係をこのようにモデル化することにより、あなたはオフィスの管理者変更されることがあり（例、彼は左またはOffice /会社から解雇します）。それはすべて私も（自分のUMLダイアグラムで行方不明になった）一定の時間が経過した後のクリーンアップの不活化アカウントに使用アクティベーションクラスにsentOn属性を追加

...あなたのユースケースに依存します。

Answer 2

NotActivatedUserとActivatedUserを区別しません。 Userテーブルを持っていて、 "Activated"のカラムを持っています。デフォルトは0（アクティブではありません）です。

1つのこと;私は別のテーブルに、おそらく "ActivationMethod"でアクティベーションコードを分割したいと思います。これにより、ユーザーが電子メール以外のアカウントをアクティブにする方法を持ち、ユーザーテーブルから "activationCode"列を削除する目的にも役立つようにするために、将来の拡張性が可能になります。

私は不活性化されていないオフィスや会社について心配しません。上記の使用計画に従って、ユーザーが自分自身（したがってOfficeと会社）をアクティブにするまで、他のユーザーが使用することはできません。一つの質問;あなたはなぜ非活性化されたユーザーにオフィスと会社を作ることを許可しますか？そのアクティビティをアクティブなユーザーだけに制限するのはなぜですか？

Answer 3

個人的には、アクティブなユーザーと非アクティブなユーザーの2つのクラスは、単なる状態なので書きません。アクティベーション前のこの状態が複雑になると、アクティベーション状態などを参照することができます。

ユーザーの「OfficeOwner」旗を持っている場合は、任意の複雑なロジックなしでオフィスを削除する際に知っています。活性化し、非活性のユーザーに対して同じテーブルを使用して

Answer 4

は、ユーザーの状態を確認する必要があります、だけでなく、どこにでもアプリケーションに事務所や企業のこと。アクティベーションが行われたとき、私はおそらく、ユーザーを作成するために必要なすべての情報、オフィスアリで会社をactivationrequestテーブルを使用します。そのため

。