限制架构违规 - asp.net MVP

Question

如果我们在应用程序中有一个定义好的层次结构，例如三层架构，我们如何限制后续开发人员违反规范？

例如，在MVP（不是ASP.NET MVC）架构中，Presenter应该始终绑定Model和View。这有助于编写正确的单元测试程序。然而，我们曾经遇到过直接在View中导入Model并调用函数违反规范的情况，因此测试用例无法正确编写。

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

- Srikanth Venugopalan

Answer 1

我恐怕这是不可能的。我们尝试使用属性来实现，但没有成功。你可能想参考我在SO上的past post。

最好的方法是使用NDepend定期检查您项目中的程序集。NDepend会显示您项目中程序集的依赖关系图，您可以立即跟踪违规情况并采取相应措施。
_{(来源：ndepend.com)}

- this. __curious_geek

---

@this.__curious_geek：感谢您指引我使用NDepend。我会去看看的。顺便说一句，很酷的昵称。 - Srikanth Venugopalan

你能否回答一下 http://stackoverflow.com/questions/8851933/event-bubbling-and-mvp-asp-net 这个问题？ - LCJ

Answer 2

那么NetArchTest呢？它受到了ArchUnit的启发。

例如：

// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
    .ShouldNot()
    .HaveDependencyOn("NetArchTest.SampleLibrary.Data")
    .GetResult()
    .IsSuccessful;

// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()
    .That().HaveDependencyOn("System.Data")
    .And().ResideInNamespace(("ArchTest"))
    .Should().ResideInNamespace(("NetArchTest.SampleLibrary.Data"))
    .GetResult()
    .IsSuccessful;

这个项目允许您创建测试，以强制执行 .Net 代码库中的类设计、命名和依赖关系约定。这些测试可以与任何单元测试框架一起使用，并纳入构建流程中。

- eduardo.bbs

---

是的，在2023年，我认为ArchUnit及其衍生产品有助于解决这个问题。在我写这个问题的时候，这还不是一个选择。 - undefined

Answer 3

距离我发布这个问题已经快3年了。我必须说，尽管这里有很好的答案，但我仍然试图探索这个问题。到目前为止，我学到了一些课程：

1. 通过查看使用者可以发现更多的代码异味（如果您拥有单元测试，则单元测试是最好的地方）。

   • 构造函数中的参数数量直接表示依赖项的数量。太多依赖项 => 类正在做太多事情。
   • 类中（公共）方法的数量
   • 单元测试的设置几乎总是会暴露出这一点

2. 代码会随着时间的推移而恶化，除非有专注于清理技术债务和重构的努力。这与语言无关。

3. 工具只能在一定程度上帮助。但是，工具和测试的结合通常足以给出各种异味的足够提示。需要一点经验才能及时捕捉它们，特别是要理解每种异味的重要性和影响。

- Srikanth Venugopalan

Answer 4

你想用软件来解决人的问题？那就准备好迎接痛苦的世界吧！

解决问题的方法是确保你有与人合作的方式，以免出现这些问题...例如：配对编程/代码审查、项目初期对新成员进行培训等。

话虽如此，你可以编写工具来分析软件并寻找常见问题。但人类非常有创造力，可以找到各种奇怪的做事方式。

- Keith Nicholas

---

哦，我感觉痛苦了！！！我一直希望有一种框架/工具可以分析/验证一些架构规则，但似乎没有捷径来代替审查啊？ - Srikanth Venugopalan

通过将程序集分离并使视图完全独立于模型，因此Presenter提供视图处理的所有对象，您可以验证视图不使用模型。但这比它值得的更加痛苦。大多数情况下。 - Keith Nicholas

但这可能只会把你的问题转移到其他地方...需要更多关于如何在你所拥有的架构风格内工作的培训。 - Keith Nicholas

Answer 5

就在你满意地锁定一切之际，新的要求就会出现，你将不得不突破它的限制。

在.NET编程层面强制执行这种严格性几乎是不可能的，因为程序员可以通过反射访问所有私有成员。

为自己着想，安排定期的代码审查，提供教育并实施适当的培训。正如你所说，当你无法对其编写单元测试时，问题很快就会显现出来。

- John K