如何模块化（大型）Java App？ [英] How to modularize a (large) Java App?

问题描述

我有一个相当大的（几个MLOC）应用程序，我想分成更易于维护的单独部分。目前，该产品由大约40个Eclipse项目组成，其中许多项目具有相互依赖性。仅这一点使得连续构建系统变得不可行，因为每次签入都需要非常重建。

I have a rather large (several MLOC) application at hand that I'd like to split up into more maintainable separate parts. Currently the product is comprised of about 40 Eclipse projects, many of them having inter-dependencies. This alone makes a continuous build system unfeasible, because it would have to rebuild very much with each checkin.

是否有最佳实践方式如何

Is there a "best practice" way of how to

• 识别零件可立即分离


• 直观地记录相互依赖性


• 解开现有代码


• 处理补丁我们需要申请库（目前通过将它们放在实际库之前的类路径中来处理）

• identify parts that can immediately be separated
• document inter-dependencies visually
• untangle the existing code
• handle "patches" we need to apply to libraries (currently handled by putting them in the classpath before the actual library)

如果有（免费/支持这一点的工具，我很感激指针。

If there are (free/open) tools to support this, I'd appreciate pointers.

尽管我对Maven没有任何经验，但它似乎强制采用非常模块化的设计。我现在想知道这是否可以反复进行改装，或者是否一个项目使用它必须从一开始就考虑到模块化。

Even though I do not have any experience with Maven it seems like it forces a very modular design. I wonder now whether this is something that can be retrofitted iteratively or if a project that was to use it would have to be layouted with modularity in mind right from the start.

编辑2009-07-10

我们正在使用 Apache Ant / Ivy 。非常有用且设计精良的工具，不像maven那样强加给你。

We are in the process of splitting out some core modules using Apache Ant/Ivy. Really helpful and well designed tool, not imposing as much on you as maven does.

我写了一些更为一般的细节和个人意见，说明我们为什么在我的博客上这样做 - 这里发布的时间太长，也许每个人都不感兴趣，所以请关注您自行决定： www.danielschneller.com

I wrote down some more general details and personal opinion about why we are doing that on my blog - too long to post here and maybe not interesting to everyone, so follow at your own discretion: www.danielschneller.com

推荐答案

使用 OSGi 可能非常适合您。它允许从应用程序中创建模块。您还可以以更好的方式组织依赖项。如果您正确定义了不同模块之间的接口，那么您可以使用持续集成，因为您只需要在签入时重建受影响的模块。

Using OSGi could be a good fit for you. It would allow to create modules out of the application. You can also organize dependencies in a better way. If you define your interfaces between the different modules correctly, then you can use continuous integration as you only have to rebuild the module that you affected on check-in.

机制由OSGi提供将帮助您解开现有代码。由于类加载的工作方式，它还可以帮助您更轻松地处理补丁。

The mechanisms provided by OSGi will help you untangle the existing code. Because of the way the classloading works, it also helps you handle the patches in an easier way.

OSGi的一些概念似乎很适合你，如维基百科所示：

框架在概念上划分为以下几个区域：

The framework is conceptually divided into the following areas:

• 捆绑包 - 捆绑包是具有额外清单头的普通jar组件。


• 服务 - 服务层通过为普通旧Java对象（PO​​JO）提供publish-find-bind模型以动态方式连接bundle。


• Services Registry - 用于管理的API服务（ServiceRegistration，ServiceTracker和ServiceReference）。


• 生命周期 - 生命周期管理的API（安装，启动，停止，更新和卸载软件包）。


• Modules - 定义依赖关系的封装和声明的层（bundle如何导入和导出代码）。


• 安全性 - 通过将捆绑功能限制为预定义功能来处理安全性方面的层。

• Bundles - Bundles are normal jar components with extra manifest headers.
• Services - The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects(POJO).
• Services Registry - The API for management services (ServiceRegistration, ServiceTracker and ServiceReference).
• Life-Cycle - The API for life cycle management (install, start, stop, update, and uninstall bundles).
• Modules - The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).
• Security - The layer that handles the security aspects by limiting bundle functionality to pre-defined capabilities.

这篇关于如何模块化（大型）Java App？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！