寻找设计模式以将框架层彼此隔离

Question

我想知道是否有人有任何相互“隔离”框架对象的经验（Spring，Hibernate，Struts）。我开始看到设计“问题”，其中来自一个框架的对象被用于来自不同框架的另一个对象。我担心的是我们正在创建紧密耦合的对象。

例如，我有一个应用程序，我们有一个带有几个属性的DynaActionForm ......其中一个属性是由Hibernate Tools生成的POJO。这个POJO到处使用...... JSP将数据填充到它，Struts Action将它发送到服务层，DAO将保持它... ack！

现在，想象有人决定对该POJO进行一些重构......这意味着JSP，Action，Service，DAO都需要更新......这有点痛苦...有了是一个更好的方式？！

有一本名为Core J2EE Patterns：Best Practices and Design Strategies（第2版）的书......这值得一看吗？我不相信它涉及任何特定的框架，但看起来它可能会提供一些关于如何正确分层应用程序的见解......

谢谢！

Answer 1

  

例如，我有一个应用程序，我们有一个带有几个属性的DynaActionForm ......其中一个属性是由Hibernate Tools生成的POJO。这个POJO随处可用...... JSP将数据填充到它，Struts Action将其发送到服务层，DAO将保留它... ack！

对我来说，将Domain Objects作为Web应用程序中的“transveral”图层没有任何问题（毕竟，你希望他们的状态从数据库转到UI，我看不到需要映射他们进入中间结构）：

  

现在，想象有人决定对该POJO进行一些重构......这意味着JSP，Action，Service，DAO都需要更新......这有点痛苦...有了是一个更好的方式？！

当然，您可以在DAO层级别从数据库中读取“Beans”，将它们映射到服务层的“域对象”，并将域对象映射到表示层的“值对象”，您将拥有它低耦合。但是你会意识到：

1. 在数据库中添加列通常意味着在视图上添加一些信息，反之亦然。
2. 重复对象和映射是非常痛苦的事情和维护。

你会忘记这个想法。

  

有一本名为Core J2EE Patterns：Best Practices and Design Strategies（第2版）的书......这值得一看吗？我不相信它涉及任何特定的框架，但看起来它可能会提供一些关于如何正确分层应用程序的见解......

本书是如何使用整个J2EE堆栈（使用EJB 2.x）实现（过度设计）应用程序的“展示”，并且总是被认为太复杂（太多模式）。最重要的是，它今天显然已经过时了。所以它很有意思，但必须带上一大堆盐。

换句话说，我不推荐这本书（至少肯定不是最先进的）。相反，如果您不使用Java EE，请查看Real World Java EE Patterns - Rethinking Best Practices（请参阅第3章 - 将核心J2EE模式映射到Java EE）和/或Spring文献。

Answer 2

首先，避免Struts 1.必须扩展框架类（如DynaActionForm）是这个框架不再是一个好选择的原因之一。

在通常情况下，您不使用spring类。 Spring是非侵入性的 - 它只是连接你的对象。只有在使用某些接口（如ApplicationContextAware）或者使用hibernate或jdbc扩展时才依赖它。将这些扩展与hibernate / jdbc一起使用就完全没问题了，这不是一种不受欢迎的耦合。

更新：如果你被迫使用Struts 1（老实说，尝试协商Struts 2，Struts 1已经过时了！），通常的方法是创建Form类的副本，包含完全相同的字段，但没有扩展框架类。将有一个工厂方法接受表单类并返回简单的POJO。这是代码的重复，但我在实践中看到它并没有那么糟糕（与使用Struts 1相比:)）

Answer 3

我认为你的问题并不像看起来那么大。

让我们想象一下，你在POJO中真正改变了什么：

1）其类的名称：任何具有重构支持的IDE将自动为您进行所有必要的更改

2）添加一些字段/方法：它几乎总是意味着添加新功能，总是应该手动和仔细地完成。它通常会导致服务层发生一些变化，很少在DAO中，通常在您的视图中（jsp）。

3）改变方法实现：如果设计良好，这将导致其他类的任何变化。

这就是全部，imho。

决定实现繁忙逻辑（EJB或Spring）的技术并使用其依赖注入工具。使用DI将使程序的不同部分通过接口相互通信。它应该足以达到必要的（足够小的）耦合水平。

Answer 4

如果可以并且将图层分开等，那么保持清晰总是很好。但是不要过分。我已经看到系统中开发人员如此倾向于严格遵守他们采用的模式和实践，最终他们的系统比他们试图避免的虚构系统更糟糕。

良好设计的艺术是理解良好实践和模式，知道何时以及如何应用它们，但也知道什么时候适合打破或忽略它们。

因此，请仔细研究如何实现您的目标，阅读模式。然后对单独的概念验证或系统的一小部分进行试验，以便在实践中查看您的想法。我的经验是，只有当你真正实施一些代码时，你才真正看到了这个想法的优点和缺点。完成后，您将能够就您将要或不会介绍的内容做出明智的决定。

最后，可以构建一个系统来处理您所关注的所有问题，但务实 - 您尝试达到的每个目标都值得为了达到它而必须引入的额外代码和API。

Answer 5

我认为核心J2EE模式：最佳实践和设计策略（第2版）解决了EJB 2.0问题，其中一些问题今天将被视为反模式。知识永远不会浪费，但我不会把它作为我的第一选择。

问题在于，不可能将所有层分离。重构POJO意味着修改您正在解决的问题，因此必须修改所有层DO。没有办法解决这个问题。

彼此不了解的层的纯粹解耦需要进行大量的复制，转换和映射。不要认为松耦合意味着这项工作消失了。

您可以做的一件事就是拥有一个以XML请求和响应表达的服务层。它强制您将XML映射到服务端的对象，但它确实将UI与其余部分分离。