Java 将表示模式对象传递到服务和业务层

我正在使用struts2 EJB3（服务/业务层）和Hibernate开发一个web应用程序。我使用Wildfly 10作为服务器。Struts在稍后的演示中，EJB3在业务层，简单java类作为服务层，hibernate在稍后的持久化中使用。 现在，在我的一个动作类中，我将模态对象传递给了服务层（简单java类）。现在，当我创建了EAR并试图将其部署到WIldfly上时。WIldfly拒绝启动。然后我意识到我的ejb模块无法找到web模块的类。现在我有两种方法来解决这个问题：-

1） 或者在EJBJAR中包含我的web类：-我认为这将彻底破坏分层体系结构以及表示层和服务层的解耦

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

---

我真的不知道在这种情况下我该怎么办，如果有人能给我推荐一些更好的分层结构，你可以用几种方法为每一层构建模型，但最终，这取决于你希望将每一层与另一层耦合的程度

显然，最细粒度和最干净的解决方案是允许每个层拥有自己的模型，并在每个集成点相应地映射

持久性模型，例如您的

@实体

类

域模型，例如，您的服务层将其作为输入并作为输出返回

查看模型，例如，表示层将其作为输入并作为输出返回的模型

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

显然，互联网上有许多资源主张简单地重用

@Entity

类作为每一层的模型，对于简单的应用程序，这是绝对可以接受的。但在更复杂、可扩展的解决方案中，这最终会成为一种负担

---

有时，可以将（1）和（2）折叠为单个模型，即

@实体

，然后使用特殊视图模型进行渲染，这样，随着时间的推移进行模型更改时，视图代码至少不会受到影响，但在许多情况下，对于复杂的应用程序，我通常会对所有三层使用不同的模型。

没有更好的分层结构。