Castle ActiveRecord OneToOne 和 JoinedBase/Key 全部在一起,没有创建 SQL 关系
我想模拟以下关系。
[JoinedBase]
MasterForm{
Guid MasterFormId {get;set;}
/* some base properties like modifiedBy etc... */
}
[ActiveRecord]
TerminationForm{
[PrmaryKey(Foreign)]
Guid MasterFormId {get; set;}
/* Some more properties specific to terminations */
}
[ActiveRecord("TermStaffing")]
public class TermStaffing : StaffingBase, ITermStaffing
{
}
public abstract class StaffingBase : EntityBase<StaffingBase>, IStaffingBase
{
protected StaffingBase()
{
}
protected StaffingBase(string createdBy)
{
this.CreatedBy = createdBy;
}
[PrimaryKey(PrimaryKeyType.Foreign)]
public virtual Guid MasterFormId
{
get; set;
}
}
这一切都形成了主类继承......基本形式,然后是一些特定的形式 ..TerminationForm,另一个表单...等等...
然后我打算在每个子表单上挂一些其他表单部分。我将这些子表单建模为 [OneToOne]
即,如果 TerminationForm 类似于上面的 FormOne.. 我在它下面有“Staffing”.. 这是链接.. 及其相互链接(注意...我还拉出了一些将人员配备属性放入抽象基础中,因为我有 TerminationStaffing 和 LeaveStaffing)
[OneToOne(MapType = typeof(TermStaffing), Cascade = CascadeEnum.All, PropertyRef = "MasterFormId", ForeignKey = "FK_TerminationFormsStaffing", Constrained = true)]
public virtual ITermStaffing Staffing
[OneToOne(MapType = typeof(TerminationForm), PropertyRef = "MasterFormId", ForeignKey = "FK_StaffingTerminationForms", Constrained = true)]
public virtual ITerminationForm TerminationForm
当 AR 创建架构时..它通过约束其主键的关系正确地将 TerminationForm 与 MasterForm 相关联...
但是,即使 TerminationStaffing 表包含 MasterFormId 我不查看创建的关系。我应该担心这个吗?也许我可以稍后添加它,但我很惊讶。
我考虑过在 TerminationStaffing 上使用 [BelongsTo],但是 TerminationForm 中的关系是什么(关系是一对一......而不是一对多)
我是不是偏离了基地?
I'd like to model the following relationship.
[JoinedBase]
MasterForm{
Guid MasterFormId {get;set;}
/* some base properties like modifiedBy etc... */
}
[ActiveRecord]
TerminationForm{
[PrmaryKey(Foreign)]
Guid MasterFormId {get; set;}
/* Some more properties specific to terminations */
}
[ActiveRecord("TermStaffing")]
public class TermStaffing : StaffingBase, ITermStaffing
{
}
public abstract class StaffingBase : EntityBase<StaffingBase>, IStaffingBase
{
protected StaffingBase()
{
}
protected StaffingBase(string createdBy)
{
this.CreatedBy = createdBy;
}
[PrimaryKey(PrimaryKeyType.Foreign)]
public virtual Guid MasterFormId
{
get; set;
}
}
This all forms the main class inheritance... base form and then some specific forms
..TerminationForm, another form... etc...
And then I was going to hang some other form-sections off each child form. I modeled those child forms as [OneToOne]
I.e. if TerminationForm is analogous to FormOne above.. I have "Staffing" below it.. this is the link.. and its reciprocal link (Note... I've also pulled up some Staffing properties into an abstract base because I have TerminationStaffing and LeaveStaffing)
[OneToOne(MapType = typeof(TermStaffing), Cascade = CascadeEnum.All, PropertyRef = "MasterFormId", ForeignKey = "FK_TerminationFormsStaffing", Constrained = true)]
public virtual ITermStaffing Staffing
[OneToOne(MapType = typeof(TerminationForm), PropertyRef = "MasterFormId", ForeignKey = "FK_StaffingTerminationForms", Constrained = true)]
public virtual ITerminationForm TerminationForm
When AR creates the schema.. it properly relates TerminationForm to MasterForm via the relationship that constrains their Primary Key...
However, even though TerminationStaffing table includes a MasterFormId I don't see the relation created. Should I worry about this? Maybe I can just add it after but I was surprised.
I thought about using [BelongsTo] on TerminationStaffing but then what relation goes in TerminationForm (the relation is one to one.. not one to many)
Am I way off base?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
事实证明,如果您在 OneToOne 关系的“子”端使用 Constrained = true,则会影响记录的插入顺序。我相信,它也可能会影响 AR 添加到数据库的外键关系。
OneToOne 对我来说是一个很棒的功能,可以将大数据模型逻辑分离为责任较少的表。
It turns out that if you use Constrained = true on the "child" side of a OneToOne relationship that this impacts the order in which records are inserted. It also, I believe, may impact the foreign key relationships which AR adds to your Database.
OneToOne has been a great feature for me to do logical separation of a big datamodel into tables which have less responsibility.