2009-01-26 32 views
2

这里工作中我们有一个非常大的应用程序和多个子应用程序。 (500名+的dll)构建/维护/部署大型应用程序

作为开发商这是非常令人沮丧,所有这些DLL和相关工作。您创建一个新项目并添加5个以上的dll以使系统的核心部分可以工作(记录,审计,安全,消息传递等)。我们添加的每个新的子应用程序,我们都会创建一个Web项目,一个业务层,一个数据层以及其他需要在3之间共享对象的项目,因此我们的列表不断扩展。

我的问题是管理这个最好的方法是什么?我似乎无法想象什么是最好的......模块化方法似乎对于重用性和热补丁项目而言都很好,而无需为一个应用程序取下系统。但管理500个DLL的头痛是一场噩梦。

每个子系统是否真的需要3-4个项目,并参考其他5个核心项目?

什么是管理大型项目保持管理/开发和部署记其他的方式?

+0

这并不回答你的问题,但它隐约相关。而且 - 我感到你的痛苦。 http://stackoverflow.com/questions/152053/structuring-projects-dependencies-of-large-winforms-applications-in-c – Benjol 2009-09-29 09:04:11

回答

1

我有一个在所有类型的项目命名规则(目前我在250+的dll项目的工作)非常不错的体验。 如果您(或任何其他人)选择了良好的命名约定,您首先会看到“它”是什么,您知道如何命名是您需要的。

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

大的项目规模大,所以它不会感到惊讶,如果你必须使用大量的DLL,类等等的工作......

-1

这是一个持续的争斗。我们的系统有大约100个不同的项目:主要是C#,以及一些用于低级别的C++项目。如果我们添加一个新的C#项目,我们必须添加对其他六个项目的引用,以获得基本功能。

在你的例子中,你会说每个子应用程序都会创建三个或更多的项目(web项目,业务层,数据层等)。尽管我们创建了这些图层,但我们尽可能地尝试将它们保留在同一个项目,专门避免添加不必要的项目。我们不会将子应用程序分解到不同的项目中,除非它将分散在多个进程中,或者我们知道整个系统的其他部分需要与该子系统进行通信。

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

+0

如果你不把图层分解成不同的项目,你怎么知道你不是无意中创建了循环引用,从而摧毁了在需要时将它们分开的能力? – 2009-01-26 20:43:30

相关问题