【问题标题】:Is it bad practice to use entity objects across all layers of a web application?在 Web 应用程序的所有层中使用实体对象是不好的做法吗?
【发布时间】:2015-07-25 20:00:05
【问题描述】:

我正在使用分层架构开发 Web 应用程序。我有:

  1. 应用层(控制器)
  2. 服务层(服务)
  3. 数据访问层 (DAO)

连接到后端 Oracle 数据库。

我使用 JPA 和 Hibernate 作为实现。因此,我创建实体来为关系数据库表的对象视图建模。

我的问题是......在我的所有 3 个图层中使用这些实体对象是否被认为是不好的做法?

我知道它至少需要被数据访问层使用,但是在服务和应用层之外呢?

我看到有些人在服务和应用程序层中使用 DTO,他们在 DTO 和服务和数据访问层之间的实体之间进行转换。

只是想知道这方面的最佳做法是什么,最好的方法应该是什么?

【问题讨论】:

  • 实体的适当范围/生命周期通常取决于其实体管理器的生命周期/范围。它们可能在管理器范围之外是陈旧的,但过早丢弃它们,您可能无法有效地使用管理器的一级缓存。没有一种万能的方法。您应该做什么取决于平台选择、JPA 的集成方式以及需求。

标签: java hibernate jpa standards


【解决方案1】:

在某些情况下,数据对象与用户在屏幕上操作的对象完全匹配。另一方面,在某些情况下,用户根据业务逻辑处理派生和/或影响多个对象的情况。许多报告应用程序都是后者的示例。

根据您的域和用户配置文件,匹配数据/UI 对象的频率有高有低。您应该在需要时定义单独的模型,并且通过更改项目来维护它们的成本。因此,过度分离的模型是不好的做法。另一方面,如果你坚持在各处传递数据模型,你的业务逻辑或 UI 代码可能不是很干净。

区分数据访问层对象和传递给用户界面的对象的决定还取决于使用的工具。例如,在控制器以静态方式(*)序列化为 JSON 的情况下,可以选择为对象图的每个不同的树遍历(要使用)定义类。另一方面,相同的对象可能也可以用于基于 JSP 的 UI。

(*) 一个例子是jackson,它使用注释来固定对象(图)被序列化成树的方式。存在限制树的方法——对于防止不需要的数据泄漏很有用——但是在我遇到的情况下,它们的实用性和可维护性是有限的。

【讨论】:

    【解决方案2】:

    你不应该在所有层中使用你的实体对象。通过在所有层中使用相同的对象,您可以在 UI 表单数据和数据库表之间实现紧密耦合。

    如果您想在 UI 上更改字段名称,则需要修改表格中的相应列。因此建议 DTO、VO 将数据从 DAO 传送到您的前端。使用市场上可用的不同类型的映射器。其中一个例子是 orika mapper。

    【讨论】:

    • 有什么替代方法,为每一层创建一个新的数据模型?那将是非常愚蠢的。
    • 不是每一层。至少将您的实体对象和携带您的数据的对象与 UI 隔离开来。
    猜你喜欢
    • 1970-01-01
    • 2016-02-19
    • 1970-01-01
    • 1970-01-01
    • 2010-09-09
    • 1970-01-01
    • 2016-08-17
    • 1970-01-01
    相关资源
    最近更新 更多