Visual Studio解决方案:这些解决方案有太多项目吗？

Question

在我目前工作的公司中,我们支持4个与之相关的Windows应用程序.对于每个应用程序,我们都有一个解决方案,每个解决方案从50到100个项 一个或多个解决方案之间可能共有40或50个项目.

为了给你一个想法,更大的解决方案有近90个项目,其中20个是UI项目(主要应用程序,自定义控件项目,UI助手项目),另外20个是业务层项目,可能有30或40个数据访问层项目其余的是Windows服务项目和专业项目

我一直觉得每个解决方案中都有太多项目.当然,我们正在谈论大型应用程序,但我不明白为什么许多项目无法合并.在我以前的公司中,我们实际上有一个用于业务层的项目,一个用于DAL的项目,显然每个窗口或Web应用程序都有一个项目.

以下是由于大量项目而遇到的一些问题:

• 编译时间很长.
• 通常应该为Private的类需要是Public才能被同一层中的其他项目访问.
• 我最近开始使用剖面仪Eqateq.试用版允许分析最多10个dll.我的情况显然使用此应用程序变得复杂.
• 跟踪项目之间的引用是非常复杂的.我确信项目之间有很多未使用的引用.

相反,我没有发现这种情况的优势.

所以,我的问题是:

• 您何时决定创建一个新项目,而不仅仅是在当前项目中创建一个文件夹？
• 我有什么优势可以忽略吗？

更新:

请记住,我并不是建议为所有事情设计一个项目.至少应该有一个DAL项目,一个用于BL,一个用于每个UI应用程序.我意识到即使这对大多数应用来说也是不现实的.我想要了解的是,为组装定义"单一责任"级别的最佳实践是什么？我的意思是,这是一个非常主观的问题,如果采取极端措施,将导致每个班级有一个集会.

更新2:

所有三个答案都提供了有价值的信息,但我只能选择一个我正在选择Doc的评论,以评估如何确定DAL项目的数量.我还链接到我刚发现的其他问题,这些问题都有相关信息:这里和这里.我也建议你阅读这篇文章.

Answer 1

我们主要讨论的是.NET项目,对吧？将应用程序拆分为不同的项目/程序集会强制您避免这些项目之间的循环依赖关系,因为C#和VB.NET编译器会禁止这样做.如果您将所有内容放入一个大项目中,则每个类都可以引用该项目中的每个其他类,从而允许您创建真正的依赖性噩梦.如果您要在团队中使用单元测试和开发,那么团队成员可以在不同的,隔离的DLL上工作并单独测试它们会更容易.

问题的"跟踪引用"部分:如果你把所有东西放到一个大的DLL中,你的类之间就有相同的引用,就好像你有单独的DLL一样,但你不能再控制它们了."私人"课程也是如此(我认为你的意思是"内部")？

当然,我不能告诉你的是,如果你的90个项目是精心挑选的工作单元.这是一个"单一责任"的问题,正确的抽象级别和由此产生的依赖关系,只有那些详细了解您的应用程序系统的人才能回答.

编辑:到目前为止,我已经阅读了一些关于通过命名空间定义组件边界,并将几个组件放入一个物理组件/一个VS项目来降低编译时间的文章(如此).为了使这种方法可行,可能需要像NDepend或类似的工具来确保组件之间没有循环依赖关系.对于大型项目,这可能是更好的选择.