我可以看到可能接近至少一個「沒有導航性質的關係」是開創了一個手寫的遷移數據庫中的FK contraint,像這樣的唯一方法:
using System;
using System.Data.Entity.Migrations;
public partial class CreateCompanyAndEmployee : DbMigration
{
public override void Up()
{
CreateTable(
"Companies",
c => new
{
Id = c.Guid(nullable: false),
CompanyName = c.String(nullable: false, maxLength: 100)
})
.PrimaryKey(t => t.Id);
CreateTable(
"Employees",
c => new
{
Id = c.Guid(nullable: false),
Name = c.String(nullable: false, maxLength: 100),
CompanyId = c.Guid(nullable: false)
})
.PrimaryKey(t => t.Id);
AddForeignKey("Employees", "CompanyId", "Companies", "Id");
CreateIndex("Employees", "CompanyId");
}
//...
}
由於你必須使用沒有導航性能與LINQ到實體加盟,如果你想加載如公司在內的所有相關員工,像這樣的例子:
var companiesWithEmployees = context.Companies
.GroupJoin(context.Employees,
company => company.Id,
employee => employee.CompanyId,
(company, employees) => new
{
Company = company,
Employees = employees
})
.ToList();
你總是必須明確指定屬性employee.CompanyId
那個代表對這種聯接中的外鍵不滿意。 EF不知道CompanyId
是外鍵屬性。這只是EF模型中一個普通的標量屬性,沒有任何關係的含義。
companiesWithEmployees
將是匿名對象的集合。每個對象都包含一個Company
實體和與該公司有關的員工的集合IEnumerable<Employee>
。
但是,我沒有看到避免導航屬性的好處。
如果您沒有導航屬性,您希望如何在代碼中使用它們?或者你只是想讓EF爲你創建外鍵約束? – nemesv