将项目打包成 JAR 的最佳实践（和影响）是什么？答案

【问题标题】：What is best practice (and implications) for packaging projects into JAR's?将项目打包成 JAR 的最佳实践（和影响）是什么？
【发布时间】：2011-01-30 18:24:23
【问题描述】：

决定如何为项目（例如 Swing GUI）定义 JAR 集的最佳实践是什么？有许多可能的分组：

每层的 JAR（表示、业务、数据）

每个（重要？）GUI 面板的 JAR。对于重要的系统，这会导致大量 JAR，但 JAR （应该）更可重用 - 细粒度

每个“项目”的 JAR（在 IDE 项目的意义上）； “common.jar”、“resources.jar”、“gui.jar”等

我是一位经验丰富的开发人员；我知道创建 JAR 的机制，我只是在寻找关于最佳实践的智慧。

就个人而言，我喜欢每个组件（例如面板）一个 JAR 的想法，因为我非常热衷于封装以及跨项目重用的圣杯。然而，我担心，在实际的性能级别上，JVM 将难以加载数十个甚至数百个小型 JAR 的类。每个 JAR 将包含； GUI 面板代码，必要的资源（即不集中），因此每个面板都可以独立。

当我说“重用的圣杯”时，我之所以这么说，是因为它展示了一种干净的解耦、封装的设计，而不是一定期望它在其他地方重用。我认为自己是一个“通常很聪明”的人；我认为在我的职业生涯中不得不处理的那些交织在一起的废话让我的速度慢了 10 到 100 倍。一个清晰解耦的设计允许我一次处理一个概念，一层，一个类。

谁有智慧可以分享？

【问题讨论】：

标签： java swing jar

【解决方案1】：

我会建议尽可能少的 JAR。

其背后的逻辑是，磁盘存储是市面上最便宜的商品，但花在追踪复杂依赖项上的时间是无价的。

因此出现了 .war 文件，其中 Web 应用程序的所有依赖项都放在一个文件中。

顺便说一句，Eclipse 有一个 JAR 导出器插件，它将所有依赖的 jar 放入一个超级 jar 并公开入门级 main 方法，因此您可以使用 java -jar file.jar 命令启动您的应用程序。尽管生成的 jar 可能很大，但另一方面并没有为您的应用程序维护非常复杂的类路径。

所以，在你的情况下，我会为每个项目使用一个 jar。如果您确定确实需要在另一个项目中重用某些代码，只需将其重构到基础项目中，并使其成为您现有项目和另一个项目中的依赖项。

【讨论】：

嗯，我听到了，但我想支持重用，也支持可理解性。有谁知道许多罐子是否会对性能产生影响？
我接受这个答案，因为它是务实和“现场”的最佳实践。从软件工程的角度来看，我仍然不同意，但这就是 Java 给我们的。在 Java 9（叹气）中，我们应该有适当的模块（Project Jigsaw），这将允许更小的模块。也许那时我的问题需要重新审视（例如，每个模块的组件，未导出私有实现细节）。

【解决方案2】：

您实际上可以同时使用这两种方法。例如，Spring 提供了一个大型的整体 jar 文件，其中包含最常见的功能。但是，如果您愿意，您也可以下载独立的 jar 文件。然后留给用户选择最好的。大 jar 文件更容易部署，但更难升级。此外，您可能需要添加一个大罐子，而您只需要一个简单的类。我发现使用小 jar 文件更容易发现依赖关系。我还认为更新/升级更容易。

【讨论】：

我同意你关于使用多个 jar 更容易找到依赖项的观点。

【解决方案3】：

Java 在类层提供封装和重用——jar 文件格式并没有真正提供它。除非您认为很多人会下载它，否则我认为将重要组件放入自己的 jar 中没有多大优势。

【讨论】：

是的，我知道，但是我们是否应该将 Swing 组件（1 个主要的“公共”类，加上 pkg 私有的附属类 + 资源）视为一个单独的“组件”，可单独交付。我想鼓励在领域类和必要的编辑器（等）方面进行思考。

【解决方案4】：

我在某处读到（当我发现这个时我正试图找到它）每层的项目是最好的。这是我一直在做的。 Struts、Spring MVC、Swing，无论在一层，EJB 在另一层，业务服务在另一层，DAO 在另一层。我也将所有 DTO 都放在了它自己的项目中，即使它们不代表层，而是通过层传递。我记得读过的主要好处是能够分别对每个 jar 进行版本控制。哦，顺便说一句，每一层实际上有两个 jar，一个用于上层使用的接口，另一个用于实现。

【讨论】：