流暢なナショナル化:弁別者との多対多関係をマッピングする方法
質問
私は、流暢なナイカエートにマッピングされる必要がある次の表とエンティティを持っています。
テーブル:
CREATE TABLE workarea
(
id uuid NOT NULL,
name character varying(255) NOT NULL,
CONSTRAINT pk_workarea PRIMARY KEY (id),
)
CREATE TABLE element
(
id uuid NOT NULL,
name character varying(255) NOT NULL,
CONSTRAINT pk_element PRIMARY KEY (id),
)
CREATE TABLE attachment
(
id uuid NOT NULL,
filename character varying(255) NOT NULL,
CONSTRAINT pk_attachment PRIMARY KEY (id),
)
CREATE TABLE objectattachment
(
id uuid NOT NULL,
attachmentid uuid NOT NULL,
attachmenttype string NOT NULL,
objectid uuid NOT NULL,
CONSTRAINT pk_objectattachment PRIMARY KEY (id),
CONSTRAINT fk_oa_a FOREIGN KEY (attachmentid)
REFERENCES attachment (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_oa_at FOREIGN KEY (attachmenttypeid)
REFERENCES attachmenttype (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)
.
このデータベース設計の下の考え方は次のとおりです。
-
「ワークエリア」または「要素」には、いくつかの「添付ファイル」ファイルと「添付ファイル」ファイルをいくつかの「ワークエリア」または「要素」と参照することができます。
-
「ワークエリア」または「要素」は、同じ「添付ファイル」ファイルを参照することができます。
だから「添付ファイル」と「ワークエリア」や「要素」の関係は、「ObjectAthment」に保存されています。 "テーブル、
-
「attachmentID」フィールドは、特定の「添付ファイル」の識別子を指します。
-
"attachmentType"フィールド(識別子)この関係を定義します 「添付ファイル」と「ワークエア」の間、または「添付ファイル」の間 "要素"
-
"objectid"フィールドは、上記の「attachmentType」フィールドの値に応じて、特定の「ワークエリア」または「要素」の識別子を指します。
データベース設計に基づいて、次にドメインモデルクラスを次のように定義します。
.public class WorkArea { private Guid _id = Guid.Empty; private string _name; public virtual Guid Id { get { return _id ; } set { _id = value; } } public virtual string Name { get { return _name ; } set { _name = value; } } } public class Element { private Guid _id = Guid.Empty; private string _name; public virtual Guid Id { get { return _id ; } set { _id = value; } } public virtual string Name { get { return _name ; } set { _name = value; } } } public class Attachment { private Guid _id = Guid.Empty; private string _fileName; public virtual Guid Id { get { return _id ; } set { _id = value; } } public virtual string FileName { get { return _fileName; } set { _fileName= value; } } } public class WorkAreaAttachment : Attachment { private WorkArea _workArea; public virtual WorkArea WorkArea { get { return _workArea; } set { _workArea = value; } } } public class ElementAttachment : Attachment { private Element _element; public virtual Element Element { get { return _element; } set { _element = value; } } }
今私の質問は、これらのドメインモデルクラスを上記のデータベースデザインでマッピングできるかどうかです。もしそうなら、それでどうやってそれをすることができますか?いいえの場合、現在のデータベースの設計を変更したくないので、デザインされたデータベースに対する流暢なノヒチャースマッピングをサポートするには、ドメインモデルクラスを変更します(つまり、「Workorea」と「要素」の添付ファイル "テーブルを作成します)。 。
Quan
-
解決
public class AttachmentLink
{
private Attachment _attachment;
public virtual Attachment Parent
{
get { return _attachment; }
set { _attachment = value; }
}
private IHasAttachments _linkedTo;
public virtual IHasAttachments LinkedTo
{
get { return _linkedTo; }
set { _linkedTo = value; }
}
}
// in AttachmentMap
HasMany(x => x.Links)
.Table("objectattachment");
// map the component
sealed class AttachmentLinkMap : ComponentMap<AttachmentLink>
{
public AttachmentLinkMap()
{
References(x => x.Attachment, "attachmentid");
ReferencesAny(x => x.LinkedTo)
.IdentityType<Guid>()
.EntityIdentifierColumn("objectid")
.EntityTypeColumn("attachmenttype")
.AddMetaValue<WorkArea>(typeof(WorkArea).Name.ToLower())
.AddMetaValue<Element>(typeof(Element).Name.ToLower())
.Not.LazyLoad(); // to prevent false proxies
}
}
// in ElementMap, and almost the same in WorkAreaMap
HasManyToMany(x => x.Attachments)
.Where("attachmenttype='element'")
Note: you don't need an Id column in the link table