可扩展/适应性强的Java EE应用程序:接口与拦截器和装饰器

Question

我们目前正在分析新版Java EE应用程序的技术要求.这是Java EE 6,但转到7是一个选项.到目前为止,这是一个单一的应用程序,一个EAR,提供定义明确的功能.但是,需要能够基于实现项目和/或客户以非常特定的方式定义某些功能.

例如,某些客户将具有非常特定的安全约束.可以显示框架处理的消息列表.对于一个客户,可以让用户看到所有内容,但另一个客户希望仅根据用户的组显示某些类型的消息.这是一个以特定于上下文的方式定义实现,调整核心功能的示例.另一个可能的要求是一些客户希望扩展给定的功能,增加新的可能性.这是可扩展的部分.

因此,有必要建立一个定义通用功能但具有可插拔部分的架构,以及扩展的可能性.在某些方面,我粗略地了解了如何处理这个问题.这个问题有一个完美适用于表示层的答案,我们将在JSF 2中做:如何创建模块化JSF 2.0应用程序？

我不太确定业务逻辑层,安全性等.我最初的想法是定义接口(几个外观)并在运行时或部署时找到实现.与服务提供商机制大致相同.可以提供默认实现,可以定义自定义实现.这确实感觉像是一种Java SE解决方案,我想知道我是否只是应用那些我熟悉的概念,如果没有更好的EE.我认为@Alternative注释有这样的目的.

另一种可能性是使用拦截器和装饰器.我不确定拦截器在日志记录,审计和其他不涉及核心业务逻辑的事情之外的用途有多大.装饰器似乎适合允许使用自定义功能扩展实现,也可能是可插拔部分.

有人可以提供一些见解,了解哪种解决方案最适合这一挑战的哪一部分？我应该将这些方法结合到问题域的各个部分吗？我有没有看到的可能性？

一个重要的要求:我们希望能够将特定于客户/项目的代码分开.我们不希望在每个实现的版本控制下拥有完整版本的应用程序,因为这将成为快速维护的噩梦.理想情况下,也没有必要将其构建为单片EAR,但能够将可插入部件添加到某些lib文件夹或单独部署它们.

Answer 1

坦率地说,没有那么多好的方法来制作你的应用程序modular(我认为这是重新定义你的要求的正确方法).

还请注意,有很多讨论,失败的尝试和奇怪的设计来简化模块化应用程序的开发,但我们仍然有这么多单片怪物.我一直在支持足够的企业系统受到惊吓,直到我的生命结束.

初始设计非常重要,不仅仅是关于基本概念interfaces.请不要误会我的意思.接口很重要,但我更喜欢使用一些不同的术语 - contracts或者extension points

让我们假设你已经extension points正确定义了.接下来你会做什么？我会说最终你会实现某种形式plugin framework.(您可以花一个小时玩JSPF,看看它如何简化模块化应用程序的开发并鼓励松耦合).

坏消息,这个解决方案可能对任何生产系统都有点危险.主要是因为复杂的类加载策略(由此方法引入)可能导致内存泄漏.所以你会发现自己很快就会分析内存转储.类加载器和所有相关的东西变得有点复杂:)

无论如何,让我们假设您已经解决了类加载的所有问题,但插件/模块生命周期呢？在任何松散耦合的系统中,您都需要严格定义模块的交互方式.插件框架不会完全解决这个问题.

最终,您将提出模块life-cycle以定义所有重要方面.例如:

我的建议是避免重新发明轮子.OSGi可能是一个很好的解决方案.还请注意OSGi很好,很成熟并提供了很多开箱即用的东西,但它也有些复杂:

所以你肯定需要一些时间来深入研究它.还请检查以下内容:OSGi的组件系统为您提供哪些好处？

另一个建议是检查任何已知的良好和模块化的大型软件产品(例如Jenkins).

更新

好的,考虑下面的讨论,我建议如下:

1. Reed或浏览几本相关书籍Real World Java EE Patterns重新思考最佳实践,真实世界Java EE Night Hacks解析业务层
2. 查看EE模式
3. 考虑使用ServiceLocator
4. 考虑使用Injection over ServiceLocator
5. 决定你是否需要DAO(一些帮助)
6. 不要忘记查看Java EE 7教程
7. 再次浏览所有模式并创建小的备忘单,以便不时刷新您的想法,如下所示 - 示例
8. 为未来而设计
9. 最后,创建几个PoC以证明您的方法足够好.

结论

对不起,答案很长,但我必须确保它背后有明确而合乎逻辑的观点.你的初衷是100%正确和良好.最好定义接口/契约并隐藏它们背后的所有复杂性.这正是OOP的意义所在.

无论如何,最重要的任务不是提供良好的设计,而是随着时间的推移保留它.我的建议是从同一个开始使用松散耦合的方法来强制执行良好的设计.服务定位器模式是您实际需要的.

它将成为保存项目和减少意大利面条代码的某种障碍.如果你发现一些有问题的模块 - 好的,没问题,它将被正确隔离并且易于更换.

如果你有足够的信心Service Locator,请跳过去Dependency Injection.补充阅读:依赖注入与服务定位器的Fowler