相关疑难解决方法(0)

更新:
这是我最常访问的问题之一,但我仍然没有找到一个令人满意的解决方案.我在回答另一个问题时读到的一个想法是创建一个工具,可以为您从列表中选择的项目"动态"构建解决方案.我还没试过.

你如何构建一个非常大的应用程序？

• 一个大解决方案中的多个小型项目/组件？
• 一些大项目？
• 每个项目一个解决方案

在没有一个解决方案的情况下,如何管理依赖关系.注意:我正在寻找基于经验的建议,而不是您在Google上找到的答案(我可以自己做).

我目前正在开发一个应用程序,它有80个dll,每个都在自己的解决方案中.管理依赖项几乎是一项全职工作.有一个自定义的内部"源代码控制",增加了复制依赖dll的功能.对我来说似乎是次优解决方案,但有更好的方法吗？我担心,在实践中制定一个包含80个项目的解决方案将非常粗糙.

(上下文:winforms,而不是web)

编辑:( 如果您认为这是一个不同的问题,请给我留言)

在我看来,之间存在相互依存关系:

• 应用程序的项目/解决方案结构
• 文件夹/文件结构
• 源代码控制的分支结构(如果使用分支)

但是如果可能的话,我很难将它们分开来单独考虑它们.

我在这里问过另一个相关的问题.

我正在计划一些工作,将依赖注入引入当前的大型单片库,试图使库更容易进行单元测试,更容易理解,并可能更灵活地作为奖励.

我决定使用NInject,我真的很喜欢Nate的"做一件事,做得好"(转述)的座右铭,而且它似乎在DI的背景下特别好.

我现在想知道的是,我是否应该将当前单个大型装配拆分为具有不相交特征集的多个较小装配.这些较小的程序集中的一些将具有相互依赖性,但远非所有这些程序集,因为代码的体系结构已经非常松散地耦合.

请注意,这些功能集不是微不足道的,也不是很小......它包含客户端/服务器通信,序列化,自定义集合类型,文件IO抽象,常用例程库,线程库,标准日志记录等.

我看到前一个问题:什么是更好的,许多小型装配,或一个大装配？有点解决这个问题,但是看起来更精细的粒度,这让我想知道那里的答案是否仍适用于这种情况？

此外,在接近这个主题的各种问题中,一个常见的答案是,"太多"集会导致了未指明的"痛苦"和"问题".我真的想要具体了解这种方法可能存在的缺点.

我同意在仅需要1个之前添加8个组件是"有点痛苦",但是必须为每个应用程序包含一个大的单片库也不是完全理想的...加上8个组件只是你做的事情曾经,所以我对这个论点很少有同情心(即使我最初可能会和其他人一起抱怨).

附录:
到目前为止,我已经看到没有针对小型装配的任何理由,所以我想我现在将继续进行,好像这是一个非问题.如果有人能够用可验证的事实来考虑好的可靠理由来支持它们,我仍然会非常有兴趣了解它们.(我会尽快增加赏金以提高知名度)

编辑:将性能分析和结果移到单独的答案中(见下文).

这个问题涉及到其他一些相关的问题,我只想让他们每一个都随意回答其中一个或多个问题.

• 分离Projects/DLL有什么好处？
• 分离Projects/DLL有什么缺点？
• 如果我为每个可共享资源创建一个新的解决方案/ DLL,是不是会有很多项目？
• 经过太多项目(如40+)后,这会对IDE性能造成一些不良影响(VS.NET 2008)？

我问这个问题是因为我有这么多不同类的这个大解决方案,因为现在我需要分离一些接口,它们都崩溃了(循环依赖问题)现在我需要创建多个DLL,我只是想一定要这次以正确的方式做到这一点.