【发布时间】:2021-07-11 04:34:56
【问题描述】:
如果我创建一个像 (T is A) 这样的别名,我有 A 和 ICollection<A> 的属性
public virtual T Children
{
get
{
return ICollection<T>;
}
set
{
ICollection<T> = value;
}
}
在哪里执行实体查找?在代码中还是在 SQL Server 中? EF 喜欢这个解决方案吗?
补充:问题...我有一个 10 年前的旧系统,带有 nHibernate(版本 1.X)和 c#。它以链形式继承,使写入数据库的类具有一定的标记。每个人都继承了一组groundproperties,有些人有子/父关系(来自遗留代码)
public abstract class GroundpropertiesTreeBaseEntity<T> : GroundpropertiesEntity
{
[JsonIgnore]
public virtual T Parent { get; set; }
public virtual IList<T> Children { get; set; }
}
如果我在数据库中查看生成的内容,每个人都有自己实体的 parentID。
但是如果我在 EF 中尝试这个,问题将是如何命名 T Parent 外键。它期望它是类型 T 然后是 _Id 而不是其他任何东西。您可以为此编写别名,但它不会解决 Id 问题,因为您无法编写 [Foreignkey(GetType(T)+"_Id"]。如果我无法找到解决方案来完成这项工作,那么我宁愿使用非常疯狂的解决方案不这样做,因为我要重写整个系统,因为有很多方法使用这种语法来处理它的类。
我希望这可以解决这个问题。
【问题讨论】:
-
这不会编译,你的实际代码是什么?
-
还没有 .. 试图找到一个解决方案来实施。我现在允许使用别名。但不是如果我这样做是通用的和/或尝试在哪里执行它。在 SQL 服务器上或在代码中...
-
trying to find a solution to implement.什么的解决方案?将表字段映射到具有不同名称的属性?您可以使用OnModelCreating中流利API 的Column属性来做到这一点。你发布的是一个属性,它根本不会执行 -
这是XY Problem。你有一个问题 X 并假设 Y 是解决方案。当这不起作用时,你问的是 Y,而不是真正的问题 X。这里真正的问题是什么? 实际的类和属性是什么样的?为什么你不能按原样使用它们?
-
在问题本身中解释真正的问题,而不是您认为的解决方案。该评论毫无意义 - FK 在运行时设置。 NH 也没有在内存中设置自动生成的 FK。即使在 NH 中,继承也仅用于具有实际继承关系的实体,映射到特定的表。其他任何东西都是与 ORM 无关的 C# 代码。你一直在描述尝试的解决方案,而不是实际的问题
标签: c# sql-server entity-framework-6