.NET解决方案 - 许多项目与一个项目

Mik*_*e Q 18 .net c# projects-and-solutions visual-studio

我们目前有一个快速增长的C#代码库.目前我们有大约10个项目,分为通常类别,common/util东西,网络层,数据库,ui组件/控件等.

我们遇到偶尔的循环依赖,其中项目x依赖于y中的某些东西,反之亦然.我们正在考虑将项目简化为一个,只使用结构文件夹/命名空间进行管理.我们有一个Java项目,当然只使用文件夹/包进行组织,所以我们不确定有多个项目带来的好处(如果有的话).我们的项目都不需要特殊的项目属性,除了主要运行项目,我们可以将它们分开(并且非常薄).

有没有人有任何先前的经验,为什么一个项目比多个项目更好/更差,并可以建议最好的方法?而且循环依赖的任何问题在这两种方法中都很有用.

任何输入赞赏.

Jon*_*gel 22

如果您的项目具有循环依赖性,则表明代码设计存在问题,而不是解决方案/项目模型.

  • 为什么这么多的投票.这并不是真的有用,除了说一个问一个真正问题的人"你不知道你做了什么". (41认同)
  • 如此多的赞成,因为它是正确的.类本身应该提供它的组件的抽象层.如果两个类具有循环依赖性,那么将两个类放在单独的项目中是没有意义的.通常,两者都依赖的组件需要被提取并放置在它自己的上面. (5认同)
  • 关键是合并项目只是为了保持循环依赖关系不会打扰构建系统隐藏你的问题,而不是解决它们.适当的解决方案是将代码重构为合理的非循环项目结构; 从长远来看,这将始终提高可理解性,可测试性和可维护性. (5认同)
  • System.Xml.dll和System.Configuration.dll之间也存在循环依赖关系 (2认同)
  • 这并不是出于敌意。只是在这种情况下,转换解决方案/产品结构似乎是出于错误的原因。至于所有的赞成票,我不知道,这取决于社区。<耸肩> (2认同)

Hei*_*nzi 17

根据我的经验,如果您愿意,在多个项目中创建单个可执行文件的代码分离可能很有用

  • 在不同的部分使用不同的编程语言,
  • 开发也被其他应用程序使用的库,或
  • 在概念上分离多个层(即,让Visual Studio确保没有项目Lib到项目App的直接引用).

就个人而言,我的大多数决定都是基于第二点.我认为应用程序的一部分可能是我在其他应用程序中可能需要的更通用的库吗?把它放在一个单独的项目中.否则,正如您所指出的,拥有一个项目通常会使开发变得更容易.

关于循环依赖:推荐的解决方法是将引用的东西的接口放入第三个项目.例如,如果有两个应用程序都通过远程处理共享某些对象,则将共享对象的接口放在库项目中,以确保它们可供两个应用程序使用.

如果不知道应用程序的确切设计,就很难给出更具体的建议.


Nei*_*l N 15

在项目之间建立依赖关系时,总是将其视为"较低",将另一个视为"较高"

更高级别的项目(例如Web界面)应该仅依赖于较低级别的项目.较低的项目(例如实用程序)不应该依赖于更高的东西,例如Web界面.如果发生这种情况,则意味着您的更高级别的项目确实应该在较低的项目中,反之亦然.


Jur*_*uri 8

一般来说,拥有多个VS项目(在VS解决方案中)在这些情况下才有意义

  • 您可以在另一个项目(类库)中重用生成的DLL
  • 您希望将分层​​架构中的内容分开,您可以放弃DAO dll并将其与另一个进行交换
  • 只有不同的前端项目(即ASP.net MVC应用程序)需要部署在不同的物理位置,但使用相同的BL,DAL.

如果你说你有循环依赖的问题,那么你的代码设计就会遇到问题.也许您可以将多个项目使用的逻辑放在一个类库中,该类库被设计为在许多项目中重用.

一般来说,如果你真的不需要,我会说你不应该添加更多的项目.分裂成项目意味着增加更多的复杂性,所以当你这样做时,你应该从中获得合理的好处.


Rob*_*ker 7

我们注意到随着项目数量的增长,Visual Studio的性能会显着下降.从"调试"切换到"发布"配置这样简单的事情可能需要15秒才能获得包含大约12个C#项目的解决方案.

另外,作为Reed关于构建时间的评论的反对点,我看到构建时间增长,因为Visual Studio似乎花费了大量时间在项目开销上.实际的编译时间似乎很快,但是从命中构建到能够运行的总时间非常重要.

我的建议是将项目数量保持在最低限度.如果你有充分的理由需要多个项目,那么必要时使用它们,但更喜欢将它们放在一起.如有必要,您还可以重构将项目拆分为两个.