我们用mvc形式链接dao实体类好不好答案

【问题标题】：Is it good that we link dao entity classes with mvc form我们用mvc形式链接dao实体类好不好
【发布时间】：2017-07-05 10:48:08
【问题描述】：

我正在用 spring 学习休眠。在实现时，我正在创建如下所示的实体类

@Entity
@Table(name = "USER_DETAILS", uniqueConstraints = @UniqueConstraint(columnNames = "USER_ID"))
public class UserInfo implements Serializable {


    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "USER_KEY", unique = true, nullable = false)
    private Long userKey;

    @Column(name = "USER_ID", unique = true, nullable = false)
    private String userId;

//getters and setters
}

我正在设计一个 html 页面来获取用户的上述输入。根据教程，他们正在创建一个具有相同变量的 DTO 类，这些变量在 DAO 实体类中，并在将该 DTO 附加到如下表单之后实现 JSR303 验证。

<sf:form action="/addUser" commandName="userDTO"
                method="post">
//input text boxes

</sf:form>

很难理解为什么我们需要再次创建一个相同的 DAO 实体类，而没有休眠注解和 DTO 名称中的相同变量。请分享一些指导方针。

这是一种最佳实践，还是我们需要为 html 表单创建 DTO 类的任何性能/结构原因。

如果我们直接用表单附加DAO实体类会发生什么。

请提供一些想法/指南。

【问题讨论】：

标签： java spring hibernate spring-mvc spring-boot

【解决方案1】：

这个问题的简单答案：

考虑一个例子：

为了获得客户订单的摘要，每行都取自客户、地址、产品、订单等实体。在这种情况下，将所有实体加载到内存中以呈现它们既浪费又缓慢在平面搜索结果屏幕中。

现在，每当视图更改时，都无法更改实体（这会很耗时），但 DTO 可以轻松更新或删除，因为它们仅用于获取数据并呈现它们。

强烈建议将尽可能多的业务逻辑放入实体中，并尝试将创建和连接实体的所有代码默认/包保护并尽可能隐藏。当你这样做时，你会得到更好的 OO 设计。一个例子是 Order 实体有一个方法 getOrderItems 来列出 OrderItem 实体，但有一个受保护的 setOrderItems 方法。客户端将在 Order 上调用一个名为 addItem 的公共方法，该方法使用受保护的构造函数在内部获取构造 OrderItem 条目所需的所有字段，并将其添加到其订单项列表中。订单成为管理从属实体的关系和业务逻辑的“根/聚合实体”。与业务逻辑完全在服务类中的“无行为” DTO 相比，这是一种更自然的 OO 设计；或者更糟的是分散在 UI 代码中。让服务类查询和加载根实体，然后在包含业务逻辑的根实体上调用方法。这样，使用相同根实体的不同服务类方法不会重复逻辑，因为逻辑将在共享的实体中。

简单来说：如果你的实体是愚蠢的，没有逻辑，那么它们只是 DTO。

【讨论】：

谢谢。很好的解释。

【解决方案2】：

对于像宠物应用程序这样的简单应用程序，您可以将实体用于 Web 层。当您在实体模型中添加 N 对多关系时，第一个问题就出现了。

Hibernate 使用接口列表 Set ，但使用它自己的实现，例如 PersistentSet ，它保留了有关休眠会话的信息，您的 Web 部件 /level 也应该有 hibernate jar 来使用这个 set 实现:)
延迟加载。如果你关闭 hibenate 会话，你会得到 LazyInitializationException ，你应该避免这种情况，你应该保持你的 hib 会话打开，直到你没有完成与 web 级别的实体的工作

【讨论】：

【解决方案3】：

在我看来，我们将 dao 实体类与 mvc 形式链接起来很糟糕。

将您的应用程序分离到某些层是一个更好的主意。最常用的方法是有 3 层：持久层、服务层和表示层。

通常，每一层都使用自己的对象：

持久性：存储库、实体
业务：服务、域对象
演示文稿：控制器、DTO

我们需要这个，因为我们希望每一层都与其他层分开。如果您想在控制器中使用实体，您的演示文稿将取决于您的数据的存储方式。这真的很糟糕。它甚至不应该知道这些或数据是如何存储的。

【讨论】：