【问题标题】:Passing Presentation Modal objects to the service and business layer将 Presentation Modal 对象传递给服务和业务层
【发布时间】:2017-01-30 18:20:32
【问题描述】:

我正在使用 struts2 EJB3(服务/业务层)和 Hibernate 开发一个 Web 应用程序。我使用 Wildfly 10 作为服务器。 Struts 在后面介绍,EJB3 在业务层以及简单的 java 类作为服务层,hibernate 在后面用于持久性。 现在,在我的一个动作类中,我已将模态对象传递给服务层(简单的 java 类)。现在,当我创建 EAR 并尝试在 WIldfly 上部署它时。 WIldfly 拒绝启动。然后我意识到我的 ejb 模块无法找到 web 模块的类。所以现在我有两种方法可以解决这个问题:-

1) 要么在 EJB jar 中包含我的 web 类:- 我认为这将彻底扼杀分层架构以及表示层和服务层的解耦。

2) 或者将模态类映射到服务层中存在的一些其他模态类:- 它也需要在服务层中创建冗余的 POJO 类。

真的不知道在这种情况下我应该怎么做,如果有人可以建议我一些更好的分层结构

【问题讨论】:

标签: java hibernate struts2


【解决方案1】:

您可以通过多种方式为每一层构建模型,但归根结底,这取决于您希望将每一层相互耦合的程度。

显然,最精细和最简洁的解决方案是让每一层都有自己的模型,并在每个集成点进行相应的映射。

  1. 持久性模型,例如你的@Entity 课程
  2. 域模型,例如您的服务层将其作为输入并作为输出返回。
  3. 查看模型,例如那些您的表示层将其作为输入并作为输出返回。

这种区别的优点是它允许每个级别的模型随着时间的推移而变化,而不会对其上方的层产生重大影响。换句话说,添加新字段或使用持久性模型更改某些内容并不一定意味着您的域模型必须更改,而只是它们之间的映射代码。

显然,互联网上有许多资源主张简单地重用您的 @Entity 类作为每一层的模型,对于简单的应用程序,这绝对是可以接受的。但在更复杂、可扩展的解决方案中,最终会成为一种负担。

有时可以将 (1) 和 (2) 折叠成一个模型,@Entity,然后使用特殊的视图模型进行渲染,这样至少在您随时间更改模型时,您的视图代码不会受到影响,但在许多情况下,对于复杂的应用程序,我通常会为所有三层使用不同的模型。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-03-12
    • 1970-01-01
    • 2010-11-01
    • 1970-01-01
    • 2011-07-06
    • 1970-01-01
    • 2017-03-05
    相关资源
    最近更新 更多