java - 使用 Spring Web MVC 解耦后备存储

Question

这是一个设计模式问题，所以我将用一个地址簿应用程序的简单示例来说明它。

首先是一些假设。1. 直接使用 DB 域对象作为 Spring MVC 表单的后备存储似乎是可以接受的。

我的应用程序的第 1 次迭代我创建了一个 JPA 映射的 Person 对象，并附加了各种属性。我使用 DAO 模式创建了一个持久性对象，它可以从数据库中获取、存储和删除人员。此外，我还有一个工厂方法 create，因此我可以获得一个 person 对象。我使用这个 DAO 对象创建了一个简单的 Web 前端。一切都很好。

在迭代 2 中，我需要支持多种存储类型，因此我为 person 创建了一个接口(interface)，它有多个实现，为 DAO 持久性创建了一个接口(interface)，同样有多个实现。此外，person 被扩展为能够拥有多个地址。

interface IPerson {
    public String getName();
    public List<IAddress> getAddresses();
}

但是，在更新 Web 界面以处理这些多重实现时，我遇到了一个问题。持久化实现由 Spring 注入(inject)。而且，因为该持久性对象有一个工厂方法，所以我非常适合创建 IPerson 实现。但是，如果我想做一些奇特的事情，比如允许将多个地址作为一个请求的一部分提交，那么我就有问题了。为了让它与 Spring 一起工作，您似乎需要使用 AutoPopulatingList，因此 spring 可以只 .get(#) 记录并将属性复制到其中。

因此，实现这项工作的一种解决方案是要求所有持久性实现使用自动填充列表，并为所有子类创建正确的实现。这是否合适，因为我们需要将此 @PostLoad 与 JPA 一起应用，因为基本列表已被 Hibernate 取代。

另一种方法是不对传递给持久性实现的实现做任何假设，并将对象转换/复制到适当的类型。这看起来更好，因为域对象保持简单，所有存储复杂性都在 DAO 中。在这种情况下，我们将使用 IPerson 和 IAddress 接口(interface)的 Default* 实现。

尽管我更喜欢第二种选择，但我不一定能适应这种情况。谁能提供任何见解或建议？

Answer 1

The alternative is to not make any assumptions about the implementation passed into the persistence implementation and convert/copy the objects across to the appropriate type. This looks better, as then the Domain object are kept simple, and all the storage complexity is in the DAO.he alternative is to not make any assumptions about the implementation passed into the persistence implementation and convert/copy the objects across to the appropriate type.

这是我在 Spring MVC 中遵循的模式

• 域对象包，不引用服务/DAO 代码(将其视为您的模型)
• Controller 层、服务层和 DAO 层对域对象进行操作
• 要处理表单 Controller ，请使用单独的“命令”或“表单”对象层来模拟用户在表单中填写的数据，而不是您的域对象。用户提交给 Controller ，该 Controller 将请求绑定(bind)到“命令”/“表单”对象，您的 Controller 将这些 bean 映射或转换为您的域 bean。

例如，您可能有一个非常丰富的 User 对象，但是当新用户注册时，他们只需要提供 2 或 3 个字段。我会将其建模为 UserSignupCommand 并且 UserSignupController 将其用作命令类(而不是 User 域对象)。然后 Controller 负责获取 UserSignupCommand bean，并将数据转换为 User bean 或您的服务层需要的任何其他类型的输入。

我不建议使用域对象作为表单支持对象，因为在大多数情况下，“我正在建模的域中的对象”和“用户在表单中提供的数据”之间没有真正的匹配。