我刚刚开始使用 .NET ORM，甚至还没有在 Entity Framework 和 NHibernate 之间做出决定。但是在这两种情况下，我都遇到了一个问题，他们似乎希望我以各种方式损害我的域模型的完整性，尤其是在 C# 对象设计的更精细点上。这是有关该主题的几个问题之一。
有a reason virtual is not the default for methods in C# .我的领域模型中的对象不准备对子类的行为做出 promise ，除非在非常特殊的情况下我将它们标记为此类。换句话说，对于我的域对象上的极少数方法，为未指定的新功能添加一个钩子(Hook)是合适的。
然而 NHibernate 想要我做一切 virtual ，而 Entity Framework 希望我将所有实体引用 virtual .我意识到他们为什么需要它(创建代理对象)，并且我意识到这实际上是对继承和 virtual 的合法使用。 ---他们实际上是为了添加新功能而连接到我的属性。但令我感到恼火的是，我必须用完全关于持久性的东西来注释我的域模型类，而不是表达它们与实现者和消费者的实际契约(Contract)。
作为一个较小的问题，我意识到我可能无能为力，通常用 sealed 注释我的类是富有表现力的。 for all the usual reasons .不过，这有点不那么令人讨厌，因为为了持久性而从我的域对象中省略注释似乎没有添加注释那么糟糕。
令人沮丧的是，在阅读了诸如 Effective C# 之类的书籍或 Eric Lippert 之类的博客(它们为如何设计富有表现力和防弹的 C# 对象提供了很好的建议)之后，使用 ORM 的需要让我把很多知识抛在了脑后。 window 。我希望这里有人能指出我错在哪里，无论是在我对他们能力的掌握中，还是在我对领域建模和 ORM 角色的思考中。
最佳答案
There is a reason virtual is not the default for methods in C# [link to interview with Anders Hejlsberg].
Hejlsberg 实际上是在谈论框架 API 设计。他没有提及业务线应用程序。因此，他的规则在 LOB 应用程序中的应用较少。由于您使用的是 O/RM，因此您可能正在编写 LOB 应用程序。
often it is expressive to annotate my classes with sealed for all the usual reasons [link to Eric Lippert's blog].
您正在引用 Eric Lippert 的一篇文章，该文章是在他在 C# 编译器团队工作的背景下撰写的。一般的 Framework Design Guidelines 实际上包含相反的准则:
DO NOT seal classes without having a good reason to do so. [paragraph 6.3]
换句话说，Eric Lippert 所说的不是一般规则。
就个人而言，当我编写 LOB 应用程序时，我实际上会密封我的类并尽可能编写非虚拟方法。但是，这与在以后的版本中引入破坏性更改的更改无关，因为这几乎完全是一个框架设计问题。
不，我这样做是因为它使我更容易对我的代码做出假设。换句话说:它使我的代码更易于维护。
但是，当我需要这样做时，我完全没有问题解封一个类或虚拟化一个方法。我这样做的主要原因是让我的代码可测试。
显然您也需要这种灵 active ，并且由于您正在编写 LOB 应用程序，因此请切合实际并记住:
They're More Like Guidelines Anyway
关于.NET ORM 需要虚拟，不能处理密封？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5364547/