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

例如,我有一个应用程序,其中我们有一个具有多个属性的dynaActionForm……其中一个属性是由Hibernate工具生成的POJO。这个pojo在任何地方都可以使用……JSP向它填充数据,struts操作将其发送到服务层,DAO将保持它……ack!

对我来说,将域对象作为Web应用程序中的“transveral”层没有什么错(毕竟,您希望它们的状态从数据库转到UI,而我看不到将它们映射到中间结构的必要性):。

现在,假设有人决定对这个pojo进行一点重构……这意味着JSP、操作、服务、DAO都需要更新……这有点痛苦……必须有更好的方法吗?

当然,您可以从DAO层的数据库中读取“bean”,将它们映射到服务层的“域对象”,并将域对象映射到表示层的“值对象”,这样您的耦合度就会非常低。但你会发现:

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

你会忘记这个想法。

< Buff行情>

有一本书叫做核心J2EE模式:最佳实践和设计策略(第二版)…这值得一看吗?我不相信它涉及到任何特定的框架,但它似乎可以提供一些关于如何正确地对应用程序分层的见解…。

这本书是关于如何使用整个J2EE堆栈(使用EJB2.x)实现(过度工程)应用程序的“展示”,并且一直被认为是太复杂(模式太多)。除此之外,它今天显然已经过时了。所以这很有趣,但必须用一粒巨大的盐来吃。

换句话说,我不推荐这本书(至少肯定不是最新的)。取而代之的是,看看 EM>真实世界的JavaEE模式——重新思考最佳实践 (参见第3章——核心J2EE模式到JavaEE的映射)和/或如果不使用JavaEE的Spring文学。

对我来说,将域对象作为Web应用程序中的“transveral”层没有什么错(毕竟,您希望它们的状态从数据库转到UI,而我认为不需要将它们映射到中间结构):

现在,假设有人决定对这个pojo进行一点重构……这意味着JSP、操作、服务、DAO都需要更新……这有点痛苦……必须有更好的方法吗?!

当然,您可以从DAO层的数据库中读取“bean”,将它们映射到服务层的“域对象”,并将域对象映射到表示层的“值对象”,这样您的耦合度就会非常低。但是你会发现:

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

你会忘记这个想法的。

有一本书叫做核心J2EE模式:最佳实践和设计策略(第二版)…这值得一看吗?我不相信它涉及到任何特定的框架,但它似乎可以提供一些关于如何正确地分层应用程序的见解…

这本书是关于如何使用整个J2EE堆栈(使用EJB2.x)实现(过度工程)应用程序的“展示”,并且一直被认为是太复杂(模式太多)。除此之外,它今天显然已经过时了。所以这很有趣,但必须和一粒巨大的盐一起吃。

换句话说,我不推荐这本书(至少肯定不是最新的)。相反,看看 Real World Java EE Patterns - Rethinking Best Practices (参见第3章,如果不使用JavaEE,则将核心J2EE模式映射到JavaEE)和/或Spring文档。

首先,避免支柱1。必须扩展一个框架类(比如 DynaActionForm )这是框架不再是一个好选择的原因之一。

在通常的场景中不使用Spring类。春天是 无创 -它只是连接你的对象。只有在使用诸如 ApplicationContextAware 或者如果您使用的是Hibernate或JDBC扩展。将这些扩展与hibernate/jdbc一起使用完全可以,而且这不是不需要的耦合。

更新:如果您被迫使用struts 1(老实说,尝试协商struts 2,struts 1已过时!),通常的方法是创建 Form 类,包含完全相同的字段,但未扩展框架类。有一个工厂方法,它采用Form类并返回简单的POJO。这是代码的重复,但我在实践中已经看到了,并没有那么糟糕(与struts 1的使用相比)。

我认为你的问题并不像看上去那么严重。

让我们想象一下,你的POJO真正能改变什么:

1)类名:任何支持重构的IDE都会自动为您进行所有必要的更改。

2)添加一些字段/方法:它几乎总是意味着添加新的功能,总是应该手动和小心地完成。它通常会导致服务层发生一些变化,在DAO中很少,而且通常在您的视图(JSP)中也很少。

3)变更方法实现:如果设计良好,则会导致其他类发生任何变更。

就这些,imho。

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

如果你能做到的话,最好把事情弄清楚,把每一层都分开,但不要太过分。我见过这样的系统:开发人员如此专注于严格遵循他们所采用的模式和实践,以至于他们最终得到了一个比他们试图避免的假想系统更糟糕的系统。

好的设计艺术是理解好的实践和模式,知道何时和如何应用它们,同时也知道何时打破或忽略它们是合适的。

所以好好看看你是如何实现你所追求的,阅读模式。然后对一个单独的概念证明或系统的一小部分进行试验,以在实践中看到您的想法。我的经验是,只有当你把一些代码放在适当的位置上,你才会真正看到这个想法的利弊。一旦你做到了这一点,你将能够对你将要介绍或不介绍的内容做出一个明智的决定。

最后,有可能建立一个系统来处理你所关心的所有问题,但是要务实——你试图达到的每一个目标都值得你为达到这个目标而引入额外的代码和API。

我想说,核心J2EE模式:最佳实践和设计策略(第二版)解决了EJB2.0的问题,其中一些问题在今天被认为是反模式的。知识永远不会被浪费,但我不会让这成为我的第一选择。

问题是不可能将所有层分离。重构POJO意味着修改要解决的问题,所以所有层都必须修改。这是不可能的。

完全分离彼此不了解的层需要进行大量的复制、翻译和映射。不要以为松耦合意味着这项工作就要结束了。

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