帐户电子邮件激活的设计（考虑Hibernate）

我有一个设计问题，我想输入一些信息。以下是限制条件：

每个用户在注册其帐户时必须有一个有效的电子邮件地址。注册用户帐户时，应发送一封激活电子邮件，其中包含一个带有激活码的链接，激活该帐户必须遵循该链接

每个用户帐户存在于恰好存在于一个公司的一个办公室中

公司的第一个注册用户创建公司和一个办公室。然后，第一个用户邀请公司的其他用户

公司之间可以进行交互，但前提是公司的第一个用户被激活（即，他们在注册后单击了各自的激活链接）

下面是一个小的UML图，说明了如何解决这个问题：

上图中省略了一些细节。该图仅显示类和字段。当涉及到字段时，它们只是在概念上用于显示应该存储哪些信息，请忽略它们的范围

一些想法和问题：

• User和NotActivatedUser基本相同。它们应该是一个单独的类还是分开的类？如果它们是分开的，您会使用哪种形式的Hibernate继承持久性
• 如果某个帐户在一段时间后未激活，则应将其删除。如果它是第一个用户，也创建了用户公司和办公室，这两个都应该删除。我们不需要激活办公室和激活公司吗？（用于数据库中的干净分离。）

---

您将如何设计这种解决方案？您是否认为在数据库中保持非活动实体和活动实体分开很重要？为什么或者为什么不？

我不会将NotActivatedUser与ActivatedUser分开；只需有一个用户表，并有一列“已激活”，默认为0（未激活）

一件事；我将激活代码拆分到一个单独的表中，可能使用“ActivationMethod”。如果您希望用户能够激活其帐户（而不是电子邮件），这将允许将来进行扩展，并且还可以用于从用户表中删除“activationCode”列

---

我不会担心没有活动的办公室和公司；根据您的使用计划（如上所述），在用户激活自己（以及办公室和公司）之前，他们不应该被其他任何人使用。一个问题；为什么允许未激活的用户创建办公室和公司？为什么不将该活动仅限于激活用户？

就个人而言，我不会为激活用户和非激活用户编写两个类，因为它只是一个状态。如果激活前的状态变得复杂，可以引用激活状态等

---

如果用户上有“OfficeOwner”标志，则您知道何时删除该办公室，而无需任何复杂的逻辑。

对激活和未激活的用户使用相同的表时，您需要检查用户的状态，以及应用程序中各地的办公室和公司的状态

---

因此，我可能会使用activationrequest表，其中包含在执行激活时创建用户、办公室和公司所需的所有信息。

我不会使用继承来表示用户对象的状态（激活/停用）。在这里，组合（聚合）是一个更好的选择

通过使用聚合，AbstractUser就变成了用户。您可能希望使用类对激活进行建模，而不是使用激活相关属性污染用户类。这样你就得到了一个漂亮干净的对象模型

在数据库级别，您仍然可以决定将这两个对象存储在同一个表/记录中，称为。或者，您可以决定将用户和激活存储在单独的表（aka）中

Hibernate支持这两种类型的映射，主要是配置问题

用户类将包含以下属性：

• 吉文纳姆
• 姓
• 电子邮件
• 激活（对激活对象的引用）

激活类将包含以下属性：

• 激活代码（字符串）
• sentOn（电子邮件是什么时候发送的）
• activatedOn（默认为null，设置为用户单击激活链接时的当前日期/时间，在不为null时告知系统用户是否已激活其帐户）

您可以使用HQL查询了解哪家公司至少有一个激活的用户：

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

此查询假定您已在Office类中定义了“管理员”属性。“管理员”是对创建办公室的用户的引用。在数据库中，“offices”表具有用户记录的外键

通过以这种方式对关系建模，您可以更改办公室的管理员（例如，他离开或被办公室/公司解雇）。这完全取决于您的用例

---

我还向Activation类添加了一个sentOn属性，用于在一段时间后清理未激活的帐户（在您的UML图中丢失了该属性）。

office owner标志似乎没有必要；查找由给定用户创建的办公室应该是一个非常简单的查询。只有当您有从办公室到用户的反向引用时。这将是另一种选择。