[英]How could virtual properties in model classes violate the persistence ignorance principle?
I've just read (revised) some architectural principles (as documented here https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles ) and felt a bit confused about the persistence ignorance
principle having a violation example like this:我刚刚阅读(修订)一些架构原则(如此处所述 https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles )并感到有点困惑关于
persistence ignorance
原则有一个这样的违规示例:
Properties requiring virtual keyword
So I don't get it clearly why such a requirement could violate the persistence ignorance principle.所以我不清楚为什么这样的要求会违反持久性无知原则。 Provided that our model classes are just in C#, compiled by .NET compiler.
假设我们的 model 类仅在 C# 中,由 .NET 编译器编译。 To load a model instance, just create the class instance normally (with all properties initialized from the corresponding persistent data, eg: a data record).
要加载 model 实例,只需正常创建 class 实例(所有属性都从相应的持久数据初始化,例如:数据记录)。 To save it just read the values from the model instance and put it back to persistent storage (of any kind).
要保存它,只需从 model 实例读取值并将其放回持久存储(任何类型)。
Actually Entity Framework
does have that requirement to enable some cool features such as lazy loading, … And I do see that EF has been doing its great job to support various kinds of persistent storage (databases), which as I understand should be contrary to the so-called a violation of the persistence ignorance principle
.实际上
Entity Framework
确实需要启用一些很酷的功能,例如延迟加载,......而且我确实看到 EF 在支持各种持久存储(数据库)方面做得很好,据我所知,这应该与所谓a violation of the persistence ignorance principle
。
Could you give me some real-world example to demonstrate that requiring virtual properties
could violate the persistence ignorance principle?你能给我一些真实的例子来证明
requiring virtual properties
可能违反持久性无知原则吗? If any present, isn't that sometimes we could not just comply with all the principles and we may have to take some trade-offs to balance between following good principles and having nice features (as in case of EF?如果有的话,是不是有时我们不能只遵守所有的原则,我们可能不得不在遵循好的原则和拥有好的特性之间进行权衡(比如 EF?
The reason it violates the persistence ignorance principle is very simple: you have to make the properties virtual
to make EF happy, so you changed the business code duo to a persistence concern.它违反持久性无知原则的原因很简单:您必须使属性为
virtual
才能使 EF 满意,因此您将业务代码二重奏更改为持久性问题。 And besides directly violating the principle, using features of EF that override members of your class change the type of the class, so, for example, in your Equals
implementation, you cannot use GetType()
anymore to compare the two instances, as the actual type of the object is generated by EF at runtime, so again, you start to change your domain logic according to persistence concerns.除了直接违反原则之外,使用覆盖 class 成员的 EF 功能会更改 class 的类型,因此,例如,在您的
Equals
实现中,您不能再使用GetType()
来比较两个实例,因为实际object 的类型是由 EF 在运行时生成的,因此,您再次根据持久性问题开始更改域逻辑。 On a side note, I would also advise against using EF's lazy loading in most cases, because it only works synchronously, blocking the current thread.附带说明一下,我还建议不要在大多数情况下使用 EF 的延迟加载,因为它只能同步工作,阻塞当前线程。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.