public class t_OS_User
{
public int ID { get; set; }
public String Name { get; set; }
public int? EmpID { get; set; }
[ForeignKey("EmpID")]
public virtual t_OS_Emp t_OS_Emp { get; set; }
}
一个员工emp，不一定需要一个登陆的角色User，例如公司的保安
public class t_OS_Emp
{
public int ID { get; set; }
public String Name { get; set; }
public virtual t_OS_User t_OS_User { get; set; }
}
如果t_OS_User是主表，t_OS_Emp是依赖表，那么API应该怎么指定？
这个是我写的，报错
modelBuilder.Entity<t_OS_User>()
.HasOptional(q => q.t_OS_Emp)
.WithOptionalDependent(q => q.t_OS_User)
.WillCascadeOnDelete(false);
One or more validation errors were detected during model generation:
t_OS_User_t_OS_Emp_Source: : Multiplicity is not valid in Role 't_OS_User_t_OS_Emp_Source' in relationship 't_OS_User_t_OS_Emp'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be '*'.
5 个解决方案
#1
Staff应该是独立的。
然后User是Staff的子类，而且扩展了有关于登录的信息。
如果你所谓的EF（我基本上不用EF）不支持继承，你首先要知道这个EF的缺点（在以后设计时要每一次都注意到），那么你可以采取变通的做法。
例如，你可以把登录信息从Staff中分离出来，定义为
也就是说，如果不支持继承，那么你就需要为“子类对父类的扩展”单独建立表。
例如如果还有“小时工”类，也是从Staff继承的，并且扩展了针对小时工的工作时间和费用的资源优化信息，那么现在你就可以与“可登录用户”一样对待。
然后User是Staff的子类，而且扩展了有关于登录的信息。
如果你所谓的EF（我基本上不用EF）不支持继承，你首先要知道这个EF的缺点（在以后设计时要每一次都注意到），那么你可以采取变通的做法。
例如，你可以把登录信息从Staff中分离出来，定义为
public class LoginInfo
{
public string UserId;
public string .......
}
也就是说，如果不支持继承，那么你就需要为“子类对父类的扩展”单独建立表。
例如如果还有“小时工”类，也是从Staff继承的，并且扩展了针对小时工的工作时间和费用的资源优化信息，那么现在你就可以与“可登录用户”一样对待。
#2
再比如说，一个“临时软件外包开发人员”同时继承了“小时工资源信息、Staff、登录信息、软件开发人员信息”的部分，你就可以先写4个Id字段，然后才写这个类型的对象它自己（对于同时多重继承上述4种类型之后的）扩展的字段。
#3
可以这样说，由于传统关系数据库是不具有面向对象功能的，因此在你将程序中的对象与数据库中的记录进行转换时经常会发生“阻抗不匹配现象”。既然你的数据库驱动工具对面向对象功能支持的能力不强，你也没有什么更好的ORM系统，那么就只有靠子自己去注意写代码时晦涩地去一点点地弱化这种问题了。
#4
....好像很复杂的样子。。。
但是。。。员工emp和用户user之间，算是继承关系吗？
但是。。。员工emp和用户user之间，算是继承关系吗？
#5
自己顶。。。。。。。。。。。。。。。。。。
#1
Staff应该是独立的。
然后User是Staff的子类，而且扩展了有关于登录的信息。
如果你所谓的EF（我基本上不用EF）不支持继承，你首先要知道这个EF的缺点（在以后设计时要每一次都注意到），那么你可以采取变通的做法。
例如，你可以把登录信息从Staff中分离出来，定义为
也就是说，如果不支持继承，那么你就需要为“子类对父类的扩展”单独建立表。
例如如果还有“小时工”类，也是从Staff继承的，并且扩展了针对小时工的工作时间和费用的资源优化信息，那么现在你就可以与“可登录用户”一样对待。
然后User是Staff的子类，而且扩展了有关于登录的信息。
如果你所谓的EF（我基本上不用EF）不支持继承，你首先要知道这个EF的缺点（在以后设计时要每一次都注意到），那么你可以采取变通的做法。
例如，你可以把登录信息从Staff中分离出来，定义为
public class LoginInfo
{
public string UserId;
public string .......
}
也就是说，如果不支持继承，那么你就需要为“子类对父类的扩展”单独建立表。
例如如果还有“小时工”类，也是从Staff继承的，并且扩展了针对小时工的工作时间和费用的资源优化信息，那么现在你就可以与“可登录用户”一样对待。
#2
再比如说，一个“临时软件外包开发人员”同时继承了“小时工资源信息、Staff、登录信息、软件开发人员信息”的部分，你就可以先写4个Id字段，然后才写这个类型的对象它自己（对于同时多重继承上述4种类型之后的）扩展的字段。
#3
可以这样说，由于传统关系数据库是不具有面向对象功能的，因此在你将程序中的对象与数据库中的记录进行转换时经常会发生“阻抗不匹配现象”。既然你的数据库驱动工具对面向对象功能支持的能力不强，你也没有什么更好的ORM系统，那么就只有靠子自己去注意写代码时晦涩地去一点点地弱化这种问题了。
#4
....好像很复杂的样子。。。
但是。。。员工emp和用户user之间，算是继承关系吗？
但是。。。员工emp和用户user之间，算是继承关系吗？
#5
自己顶。。。。。。。。。。。。。。。。。。