EntityFramework 可以支持 EAV 模型吗?
EntityFramework 可以支持 EAV 模型吗?这是一个可行的方案,还是一场噩梦?我想在系统中使用 EAV 模型,并且如果可能的话我想拥抱 EF,但我担心这两种理念是冲突的。
Can EntityFramework support an EAV model? Is this a workable scenario, or a nightmare? I want to use an EAV model for a system, and I'd like to embrace EF if possible, but I'm concerned that these two philosophies are in conflict.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这取决于您希望如何在应用程序中使用 EAV。 EF 可以用来映射这一点:
这就是可以持久化的内容以及可以通过 Linq-to-entities 查询的内容。现在,您可以通过定义辅助属性来使您的实体可用(只能在您的应用程序中使用,但不能用于持久化或查询)。这些辅助属性只能用于实体类型中始终存在的众所周知的属性 - 可选属性仍然必须在集合中访问:
由于转换和集合搜索,这不是很好。如果多次访问数据,它们将被执行多次。
我没有尝试过,但我认为可以通过每个实体实现类似的接口来避免这种情况:
现在您将处理
ObjectContext< 上的
ObjectMaterialized
和SavingChanges
事件/代码>。在第一个处理程序中,如果物化对象实现了IEavEntity
,则您将执行Initialize
;在第二个处理程序中,您将迭代ObjectStateManager
以获取所有更新或插入的实体IEavEntity
,您将执行Finalize
。像这样的东西:It depends how do you expect to use EAV in the application. EF can be used to map this:
This is what can be persisted and what can be queried by Linq-to-entities. Now you can make your entity usable by defining helper properties (can be used only in your application but not by persistance or querying). These helper properties can be used only for well known attributes which will always exists for entity type - optional attributes must be still accessed in collection:
This is not very nice because of conversions and collection searching. If you access data multiple times they will be executed multiple times.
I didn't tried it but I think this can be avoided by implementing a similar interface by each entity:
Now you will handle
ObjectMaterialized
andSavingChanges
events onObjectContext
. In the first handler you will executeInitialize
if materialized object implementsIEavEntity
in the second handler you will iterateObjectStateManager
to get all updated or inserted entities implementingIEavEntity
and you will executeFinalize
. Something like: