我一直在使用的工具之一着眼于“模块”与作为分发单元的模块之间的耦合（在本例中为 .net 程序集）。
我觉得我应该对查看包（或命名空间）之间的耦合比关注分发单元更感兴趣。
我应该更关心包/命名空间之间的耦合（确保抽象只依赖于抽象，具体类型依赖于抽象并且它们在依赖关系中没有循环，因此重构和扩展很容易）还是应该关心我是否可以无需更新未更改的分发单元即可部署新版本？
别人衡量什么？
对于它的价值，我的直觉是，如果我专注于包/命名空间耦合，那么分发耦合单元将免费或至少更容易。
Hamish Smith
问问题
214 次
2 回答
3
首先，很容易过分关注依赖和耦合。确保你没有过度复杂化。
有了免责声明，这就是我的建议。
依赖/耦合管理实际上有 3 种不同的视图：1）物理结构（即程序集依赖） 2）逻辑结构（即命名空间依赖） 3）实现结构（即类依赖）
对于大型应用程序，您至少需要检查所有 3 个，但您通常可以优先考虑。
对于客户端部署的应用程序，数字 1 可能非常重要（即对于插件之类的东西）。对于部署在企业内部的应用程序（即 asp.net），第 1 项通常证明不是那么重要（不包括跨多个应用程序重用的框架）。您通常可以很容易地部署整个应用程序，而不必为 #1 承担复杂结构的开销。
第 2 项往往是一个可维护性问题。了解您的层边界及其与命名空间的关系（即，您是在每个命名空间做 1 层，还是在逻辑级别以不同方式打包）。有时，工具可以通过查看逻辑依赖结构来帮助您强制执行层边界。
Item #3 真的是关于做好类设计。每个优秀的开发人员都应该付出相当多的努力来确保他只在他的类中承担适当的依赖关系。这说起来容易做起来难，通常是一项必须随着时间的推移而获得的技能。
为了更接近您问题的核心，第 1 项实际上是关于项目在 VS 解决方案中的布局方式。所以这不是一个要衡量的项目。它更多的是您在开始时设置并运行的东西。第 2 项是您可以在构建期间使用工具检查的内容，以查看开发人员是否违反了任何规则。实际上，这更像是一种检查而不是一种措施。第 3 项确实是您想要仔细查看测量的项。在您的代码库中查找具有大量耦合的类将成为未来的痛点，确保这些人的质量。此外，在这个级别进行测量可以让您对代码库的质量（整体）有一些了解，因为它正在发展。此外，如果有人将一些非常粗俗的代码检查到您的代码库中，它会给您一个危险信号。
因此，如果您想确定优先级，请快速查看#1 和#2。知道他们应该是什么样子。但对于大多数应用程序来说，第 3 项应该花费的时间最多。
当然，这个答案不包括大型框架（如 .NET BCL）。那些婴儿需要非常小心地注意#1。:-)
否则，您最终会遇到这样的问题：“.NET Framework 的当前版本包括各种基于 GUI 的库，这些库在 Server Core 中无法正常工作” http://www.winsupersite.com/showcase/win2008_ntk。 ASP
您无法在 Windows Server 2008 的无 GUI 安装上运行 .NET，因为该框架依赖于 GUI 库...
最后一件事。确保您熟悉良好的依赖/耦合管理背后的原则。你可以在这里找到一个不错的列表：
于 2008-09-23T21:04:17.183 回答
0
分发单元之间的耦合和依赖循环更加“致命”，因为它会使部署程序变得非常困难 - 有时它甚至会使编译程序变得非常困难。
你是对的，一个好的顶层设计将代码划分为逻辑包和清晰和预定义的依赖关系只会让你大部分时间，唯一缺少的是将包正确分离为分布单元。
于 2008-09-23T20:54:05.337 回答