架构/维护/部署大型应用程序

Question

在工作中，我们有一个非常大的应用程序，其中包含多个子应用程序。(500 +dll)

作为一名开发人员，使用所有这些dll和依赖项是非常令人沮丧的。您可以创建一个新项目并添加5+ dll，以使系统的核心部分(日志、审计、安全、消息传递等)正常工作。每添加一个新的子应用程序，我们就会创建一个web项目、一个业务层、一个数据层以及在这三个层之间共享对象所需的任何其他项目，因此我们的列表会不断扩大。

我的问题是，管理这一问题的最佳方法是什么？我似乎想不出什么是最好的..模块化方法似乎很好地提高了可重用性，并且无需为一个应用程序关闭系统即可对项目进行热修补。但是，管理500个动态链接库令人头疼是一场噩梦。

每个子系统真的需要3-4个项目，并参考其他5个核心部分吗？

在管理/开发和部署的同时，管理大型项目的其他方法是什么？

Answer 1

我在所有类型的项目中都有很好的命名指南的经验(目前我在250+ dlls项目中工作)。如果您(或其他任何人)选择了良好的命名约定，您第一眼就会看到"it“是什么，并且您知道如何命名是您需要的东西。

不用担心项目中引用的数量。如果你对每次添加X引用感到沮丧，你可以创建一个宏来代替你。或者，您可以根据自己的特殊要求创建一个模板与解决方案/项目/项(文件)进行比较。

大型项目很大，所以如果您必须处理大量的dlls、类等，也就不足为奇了。

Answer 2

这是一场持续的战斗。我们的系统有大约100个不同的项目:大部分是C#，还有一些低级的C++项目。如果我们添加一个新的C#项目，我们必须添加对半打其他项目的引用，只是为了获得基本功能。

在您的示例中，您可以为每个子应用程序创建三个或更多项目(web项目、业务层、数据层等)。虽然我们创建了这些层，但我们尽可能地将它们保留在同一个项目中，特别是为了避免添加不必要的项目。我们不会将一个子应用程序分解为不同的项目，除非它将分布在多个进程中，或者如果我们知道整个系统的其他部分将需要与该子系统进行通信。

很可能每个子系统确实需要引用核心部分。它是否需要3-4个项目取决于你是如何构建它的。我们发现，将新项目的创建限制在与其他项目通信或由多个子系统使用的部分，大大减少了我们必须处理的项目数量。