限制违反架构 - asp.net MVP答案

【问题标题】：Restrict violation of architecture - asp.net MVP限制违反架构 - asp.net MVP
【发布时间】：2010-04-27 05:11:23
【问题描述】：

如果我们在应用程序中定义了层次结构。比如三层架构，我们如何限制后续开发者违反规范？

例如，在 MVP（不是 asp.net MVC）架构的情况下，presenter 应该始终绑定模型和视图。这有助于编写适当的单元测试程序。但是，我们也遇到过一些人直接在视图中导入模型，调用违反规范的函数，导致无法正确编写测试用例。

有没有一种方法可以限制允许从一组类继承的类？我正在研究各种可能性，包括采用不同的设计模式，但新方法应该值得所涉及的代码更改。

【问题讨论】：

标签： asp.net mvp

【解决方案1】：

恐怕这是不可能的。我们试图借助属性来实现这一点，但没有成功。你可以参考我的past post on SO。

您能做的最好的事情就是通过 NDepend 继续检查您的程序集。 NDepend 向您显示项目中程序集的依赖关系图，您可以立即跟踪违规并采取相应措施。

_{（来源：ndepend.com）}

【讨论】：

【解决方案2】：

我发布这个问题已经快 3 年了。我必须说，尽管这里有出色的答案，但我已经尝试过探索这一点。到目前为止我学到的一些经验教训 -

查看消费者会发现更多代码异味（如果有单元测试，最好查看它们）。
- 构造函数中的参数数量是依赖项数量的直接指示。依赖项太多 => 类做的太多了。
- 类中（公共）方法的数量
- 单元测试的设置几乎总是会泄露这一点
代码会随着时间的推移而恶化，除非集中精力清除技术债务和重构。不管是什么语言都是如此。
工具只能在一定程度上有所帮助。但是工具和测试的组合通常可以为各种气味提供足够的提示。及时捕捉它们需要一些经验，尤其是要了解每种气味的重要性和影响。

【讨论】：

【解决方案3】：

您想用软件解决人员问题？为痛苦的世界做好准备！

解决问题的方法是确保您有办法与不会遇到此类问题的人合作......结对编程/复习。当人们第一次进入项目时的诱导等。

话虽如此，您可以编写分析软件并查找常见问题的工具。但是人们非常有创意，可以找到各种奇怪的做事方式。

【讨论】：

【解决方案4】：

只要一切都按照你的满意锁定，新的要求就会到来，你必须突破它的一面。

考虑到程序员可以通过反射访问所有私有成员，在 .NET 的编程级别执行这种严格性几乎是不可能的。

做好自己，支持并安排定期的代码审查，提供教育并实施适当的培训。而且，正如您所说，当您无法针对它编写单元测试时，它会很快变得明显。

【讨论】：