在企业Java/.Net项目中，是否每个开发人员的类路径中都有所有依赖项？

Question

在大规模的Java/.Net企业项目中，是否每个开发人员都需要在它们的类路径/本地开发环境中拥有所有组件/库/依赖项，以使其生成？

或者它们被划分成更小的部分，可以单独构建(这样它们就不需要引用所有的依赖项)？

换句话说，如果他们想运行整个应用程序，他们需要所有的组件；但是如果他们只运行应用程序的一个子集，他们只需要相应的组件子集。

大型企业项目通常是以第一种方式组织还是以第二种方式组织？

一个可能的组织是，如果您正在处理整个项目的模块，该模块是独立的，但被其他模块引用(换句话说，依赖树中的叶节点)。

另一个组织是，如果动态加载使用的类，则可以在类路径中不包含任何类。要运行它，您的类路径只需要访问您实际加载的类路径(可能还有许多其他的类路径构成了项目的不同部分，没有加载)。

这些都是理论上的可能性，但是企业项目的标准实践是什么呢？嗯，在实践中？

我已经将其扩展到包括.Net，因为我认为会出现同样的问题(DLL地狱？)

Answer 1

对于每个项目，这个问题都有不同的答案。以下是几点一般性意见：

• “运行应用程序的子集”通常是不可能的，因为很少有应用程序是模块化的，因此它们的每个部分实际上都可以独立运行。
• 有时你拥有的是一个始终需要的应用程序内核，以及在这个核心上构建的模块，它们或多或少是相互独立的。
• 最大的区别通常不是拥有和不拥有所有组件，而是将它们作为源代码与将它们作为JAR文件。
• 在大型应用程序中，开发人员通常只在源代码中使用他们正在处理的部分，其余部分作为JAR文件使用。
• 如果您需要运行时模块化(即组件在运行时按需加载和卸载)，这就是OSGi的目的。

Answer 2

一个好的项目结构会分解一些东西，这样你就可以运行独立的模块了。

但在现实生活中，我所见过的大多数项目直到有人厌倦并主动打破它们时才会这么做。

如果正确使用Maven或Ivy等良好的依赖管理基础设施，可以在服务器上存储已编译的模块，并根据需要下载这些依赖项。

您还可以使用许多模拟对象和服务来帮助分解对其他产品组件的测试依赖。

Answer 3

我当然同意这样的意见，即分开办事是“好”的。但在实践中，这是非常罕见的。

假设您必须在一个没有分离的环境中工作，那么还有另一个组织策略，这就是我所看到的。由于您的问题同时涉及构建和运行依赖关系，所以您讨论的似乎不是进程，而是类和jars。

简单的解决方案是在共享服务器上建立完整的、经过集成测试的(或集成测试就绪的)依赖关系。

然后，开发人员在他们的本地环境中构建他们正在工作的系统的各个部分，使用类路径首先引用他们的开发，然后引用适当的共享服务器。