EF Codefirst,一类,带鉴别器的多个表
我做了一些调查,我想知道以下是否可能。
我希望创建一个 BaseEntityWithDetails 类,我可以将其重用于我想要可扩展的任何类型。例如,
public abstract class EntityDetail
{
}
此类用于保存实体的键和值。
“Products”将通过执行以下操作来扩展...
public class ProductDetail : EntityDetail
{
}
public class Product : BaseEntityWithDetails<ProductDetail>
{
}
基类“BaseEntityWithDetails”将提供一些用于设置和获取的辅助方法。你怎么认为?
使用 EF CodeFirst 进行映射的最有效方法是什么,同时又非常容易允许其他类型实现如下所示的 DetailsEntityTypeConfiguration
public class ProductMap : DetailsEntityTypeConfiguration<Product, ProductDetail>
{
}
提前致谢!
I doing a little investigation and I am wondering if the following is possible.
I am looking to create a BaseEntityWithDetails class that I can reuse for any type that I would like to have extendable. For example
public abstract class EntityDetail
{
}
This class is used to persist a key and value for the entity.
"Products" would be extended by doing the following...
public class ProductDetail : EntityDetail
{
}
public class Product : BaseEntityWithDetails<ProductDetail>
{
}
The base class "BaseEntityWithDetails" will provide some helper methods for setting and getting. What do you think?
What is the most effective way of mapping this with EF CodeFirst while being super easy to allow another type implement an DetailsEntityTypeConfiguration like the following
public class ProductMap : DetailsEntityTypeConfiguration<Product, ProductDetail>
{
}
Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我想引用一个对此非常聪明的人的话:重用是一个谬误。不要费心做这样的事情,因为它只会让你的设计更加混乱和复杂。将您的继承保存到域中真正共享相同行为的实体,不要预先进行此类假设。
作为旁注:您可以将其映射为 每种类型的表 如果您将“EntityDetail”放入数据库中,但正如我所说以前,这并不是一个好主意。
I would like to quote someone really smart on this: Reuse is a fallacy. Don't bother doing stuff like this because it will only make your design more obfuscated and complex. Save your inheritance to the entities in your domain which really share the same behavior, don't do this type of assumptions up front.
As a side note: You can map this as a table per type if you put your "EntityDetail" into your database, but as I said before, this is just not a good idea.