【EF Core】聊聊“复合”属性

李氏祖昂 發表於 2025-8-10 21:52:00

复合（或复杂）属性，即 Complex Property，怎么理解呢？这是相对于常见的基础类型，比如 string、int、byte、long 等类型的属性就是基础类型值，而由多个基础类型构成的类型就是复合类型（当然，复合类型的属性也可以其他复合类型，这里就不套娃了）。
比如，某顿饭由米饭、菜、肉、汤组成。
<div class="cnblogs_code">
<pre>public class 大餐
{
public MiFan 饭 { get; set;} // 复合
public Tang 汤 { get; set; } // 复合
public CaiRou 主菜 { get; set; } // 复合
}

public class MiFan
{
public string 原料 { get; set; } // 用什么煮的
public string 单位 { get; set; } // 千克
public float 量 { get; set; } // 吃多少饭
}

public class Tang
{
public string 主材 { get; set; } // 用什么煲的汤
public string? 配材 { get; set; } // 配哪些辅料
public float 水用量 { get; set; } // 用多少水
public DateTime 用时 { get; set; } // 煮了多久
}

public class CaiRou
{
public string 分类 { get; set; } // 肉还是青菜
public double? 分量 { get; set; } // 吃多少
public bool? 是否混合 { get; set; } // 是菜肉混合还是吃素的
}</pre>
</div>
其中，饭、汤、主菜几个属性都引用了其他的类，就是复合类型。这时候你会发现：咦，这怎么看着像导航属性？
是的，很像，但只是很像而已，实际上是有区别的。老周总结如下：
1、导航属性是一个实体引用另一个实体，强调的是引用和被引用者都是实体类；而复合属性所引用的实例并不作为实体类来看待，纯粹是复杂一点的类型；
2、正因为导航属性引用的实体类实例，所以，被引用的类型通常要有主键的（特殊配置除外）。复合属性引用的对象不需要主键；
3、导航属性引用的对象是实体，它会映射到数据库中的表。复合属性引用的对象不会做表映射（只成为主表的字段，后文会演示）；
4、由于导航属性引用的是实体，所以它可以是单个实例或集合类型。而复合类型没有映射单独的表，而是被拆解为主表的字段，所以它引用的对象不能是集合（至少目前是不支持的）。
那么，应该在什么时候，或什么场景下使用复合属性（而不是导航属性）？一句话斯基：你只想用一个类来组织一些信息，但不希望它成为实体的时候。有大伙伴会质问老周：你不是废话吗。这不是废话，本来就是这个用途的。
例如，一个比 SARS 还典型的应用场景——我的产品订单信息中会包含订货者的信息，但这个信息用一个字段描述显然不够，因为它包含联系人是谁、什么电话号码、住在哪里。当然你也可以单独用一个表来存放联系人信息，如果这样它就是实体类了，就要用导航属性。可是，有些时候是没必要单独去存储的（比如，订你货的人或单位不是常客，何必多建一张表呢）。
光说不练等于白说，咱们就动手试试。
假如我有个 Person 实体类，它可以表示任意人员（员工、学生、罪犯、外星人），其中，Contact 属性表示联系方式。这个信息量超出单个字段的描述范围（用XML或JSON字段的当我没说），于是，我另外定义了一个 ContactInfo 类存放联系信息。
<div class="cnblogs_code">
<pre>public class ContactInfo
{
public string Phone { get; set; } = string.Empty;
public string? Email { get; set; }
public string City { get; set; } = string.Empty;
public string Town { get; set; } = "";
public string? Street { get; set; }
}

public class Person
{
public Guid ID { get; set; }
public string FirstName { get; set; } = "";
public string LastName { get; set; } = "";
public DateOnly? RegistDate { get; set; }
public ContactInfo Contact { get; set; } = new();
}</pre>
</div>
目前来说，EF Core 是不允许复合属性引用 null 值的，即不能声明为 ContactInfo?。但复合类型中的属性是可以为 null 的。
咱们写个 DbContext 来建立模型。
<div class="cnblogs_code">
<pre>public class MyContext : DbContext
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
 optionsBuilder.UseSqlServer(
 "Server=(localdb)\\MsSQLLocalDB; Database=person_db"
 )
 .LogTo(m => Console.WriteLine(m));// 启用日志
 }

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Person>(eb =>
 {
 // 表名
 eb.ToTable("tb_persons")
 .HasKey(x => x.ID).HasName("PK_Person");
 // 个别字段限制一下长度
 eb.Property(x => x.FirstName).HasMaxLength(10);
 eb.Property(nameof(Person.LastName)).HasMaxLength(25);
 // 复合属性
 eb.ComplexProperty(x => x.Contact);
 });
}
}</pre>
</div>
A、LogTo 方法配置一个委托，接收一个字符串对象，它就是日志消息。这是配置日志输出最简单的用法；如果不配置应用程序就不会收到日志呗。
B、重写 OnModelCreating 方法，构建实体模型。Person 实体在映射时具有以下特征：
      1、数据表名为 tb_persons；
      2、主键的名称为 PK_Person；
      3、表示姓和名的字段设置长度限制；
      4、Contact 属性配置为复合属性。注意，EF Core 的“预置”约定是发现不了复合属性的，得手动去配置。约定会识别为导航属性，但 ContactInfo 类没有被配置为实体，运行后会发生异常。
有大伙伴可能不解了：FK，你这 Context 类不对劲，没有公开 DbSet<> 类型的属性，能访问实体吗？EF 能找到实体吗？
1、公开 DbSet<> 的属性是为了让预置约定自动添加实体集合，但，我不公开也不影响使用，只要调用 Set 方法，DbContext 也会添加实体集合的；
2、DbSet<> 实际上是提供一个窗口让我们执行查询，它不负责构建模型。真正用来建模的是你重写的 ModelBuilder，只要你调用 Entity 方法，它就知道你要把 Person 类作为实体添加到模型中了（如你所见，并未为 ContactInfo 类调用 Entity 方法，表明它不是实体类）。
注：这个项目要引用 Microsoft.EntityFrameworkCore.SqlServer 包，我用的是 SQL Server 数据库（LocalDB），你也可以用其他数据库，就要引用对应的包。操作方法请参考巴巴尔星人的博客。
前面提了，EF 的约定不会发现复合属性，所以你要调用 ComplexProperty 方法明确告诉 EF 这是个复合属性。
为了方便演示，本示例每次运行都会先删除数据库，再创建一个新——每次都是全新的。
<div class="cnblogs_code">
<pre>using (var ctx = new MyContext())
{
// 确定数据库每次都是新的
 ctx.Database.EnsureDeleted();
ctx.Database.EnsureCreated();
// 如果空的，添加点料
DbSet<Person> persons = ctx.Set<Person>();
if (persons.Any() == false)
{
 persons.Add(new Person
 {
 FirstName = "洪",
 LastName = "水",
 RegistDate = new DateOnly(2024, 2, 10),
 Contact = new ContactInfo
 {
 Phone = "18808828811",
 Email = "axax@ktv.edu.cn",
 City = "天津市",
 Town = "黄牛镇",
 Street = "番茄路狗头街333号"
 }
 });
 persons.Add(new Person
 {
 FirstName = "高",
 LastName = "大桂",
 RegistDate = new DateOnly(2023, 8, 25),
 Contact = new()
 {
 Phone = "18925531100",
 Email = "GreenMan123@tbcg.net",
 City = "成都市",
 Town = "金龙镇",
 Street = "迷路1008号"
 }
 });
 // 更新数据库
 ctx.SaveChanges();
}
}</pre>
</div>
上面代码没什么要点，如果数据库已存在，删之；若不存在，建之。新数据库是没数据的，所以插入些新记录。
由于咱们在配置上下文时已经开启了日志功能，运行后咱们看看 EF 是如何对待复合属性的（主要看生成的 SQL 语句）。
<div class="cnblogs_code">
<pre>CREATE TABLE [tb_persons] (
 [ID] uniqueidentifier NOT NULL,
 [FirstName] nvarchar(10) NOT NULL,
 [LastName] nvarchar(25) NOT NULL,
 [RegistDate] date NULL,
 [Contact_City] nvarchar(max) NOT NULL,
 [Contact_Email] nvarchar(max) NULL,
 [Contact_Phone] nvarchar(max) NOT NULL,
 [Contact_Street] nvarchar(max) NULL,
 [Contact_Town] nvarchar(max) NOT NULL,
 CONSTRAINT [PK_Person] PRIMARY KEY ([ID])
);</pre>
</div>
这下你是否已明白，为什么复合属性的类型不需要主键了吧，因为它不会单独成表，只不过是把属性成员分散到 tb_person 表的字段列表中。所以，在数据库层面，复合对象其实是主表的一部分；而在实体层面，将其作为一个整体，我们在写.NET 代码时才有面向对象的感觉。这是为咱们程序服务的。
我们还得关心一个问题：复合属性是否支持更改跟踪——能不能自动生成更新的 SQL。咱们试一下修改其中一条记录的复合属性所引用的 ContactInfo 对象的属性值。
<div class="cnblogs_code">
<pre>using (var c = new MyContext())
{
// 修改
Person? firstOne = c.Set<Person>().FirstOrDefault();
if (firstOne != null)
{
 firstOne.Contact.Town = "石头镇";
 // 只输出了跟踪，并未真正提交
 Console.WriteLine(c.ChangeTracker.ToDebugString());
}
}</pre>
</div>
上述代码把第一条记录的联系人信息更新了，但没有调用 SaveChanges 方法，ToDebugString 方法可以输出哪些更改被跟踪到了。也就是说，这次修改实际上不会更新到数据库的。输出内容如下：
<div class="cnblogs_code">
<pre>Person {ID: f9a372f8-849b-420b-8cb3-08ddd7ec9422} Unchanged
ID: 'f9a372f8-849b-420b-8cb3-08ddd7ec9422' PK
FirstName: '洪'
LastName: '水'
RegistDate: '2024/2/10'
Contact (Complex: ContactInfo)
 City: '天津市'
 Email: 'axax@ktv.edu.cn'
 Phone: '18808828811'
 Street: '番茄路狗头街333号'
 Town: '石头镇' Originally '黄牛镇'</pre>
</div>
它已经跟踪到了 Town 属性的变更。
现在，咱们把更新正式提交到数据库，在更新后从数据库重新查询一下。
<div class="cnblogs_code">
<pre>using (var c = new MyContext())
{
Console.WriteLine("修改前：");
PrintInfo(c.Set<Person>().AsEnumerable());

 // 修改
Person? firstOne = c.Set<Person>().FirstOrDefault();
if (firstOne != null)
{
 firstOne.Contact.Town = "石头镇";
 // 提交更新
 c.SaveChanges();
 // Console.WriteLine(c.ChangeTracker.ToDebugString());
 }
}

using (var c = new MyContext())
{
Console.WriteLine("\n修改后：");
PrintInfo(c.Set<Person>().AsEnumerable());
}

// 此方法用来打印实体信息
static void PrintInfo(IEnumerable<Person> persons)
{
foreach (var p in persons)
{
 Console.Write("姓{0}名{1}，来自{2}", p.FirstName, p.LastName, p.Contact.City + p.Contact.Town + p.Contact.Street);
 Console.Write("\n");
}
}</pre>
</div>
更新前后各打印一次，效果如下：
<div class="cnblogs_code">
<pre>修改前：
姓洪名水，来自天津市黄牛镇番茄路狗头街333号
姓高名大桂，来自成都市金龙镇迷路1008号

修改后：
姓洪名水，来自天津市石头镇番茄路狗头街333号
姓高名大桂，来自成都市金龙镇迷路1008号</pre>
</div>
 
接下来，老周再介绍一种特殊情况，目前来说是不能用复合属性处理的。先介绍一下实体关系：
有一个 Album 实体，它表示一张 CD 专辑。其中，它有个 Tracks 属性表示本专辑包含的曲目，这是个集合，其中每个元素是 Track 对象；
Track 实体表示单首曲子的信息，其中，它有个 Artist 属性，表示表演/演唱这首曲子的人（歌手），该属性的类型是 Performer 类。
总结一下就是：Album 类的Tracks 属性中包含 Track 类，而 Track 类的 Artist 属性引用了 Performer 类。
实体定义如下：
<div class="cnblogs_code">
<pre>/// <summary>
/// 歌手信息
/// </summary>
public class Performer
{
/// <summary>
/// 姓名
/// </summary>
public string Name { get; set; } = string.Empty;
/// <summary>
/// 别名
/// </summary>
public string? Alias {get; set; }
/// <summary>
/// 性别
/// </summary>
public string? Gender {get; set; }
/// <summary>
/// 艺名
/// </summary>
public string? StageName { get; set; }
/// <summary>
/// 年龄
/// </summary>
public int? Age { get; set; }
/// <summary>
/// 生日
/// </summary>
public DateOnly? Birthday {get; set; }
/// <summary>
/// 简述
/// </summary>
public string? Brief {get; set; }
}

/// <summary>
/// 音轨
/// </summary>
public class Track
{
/// <summary>
/// 轨道ID
/// </summary>
public int ID { get; set; }
/// <summary>
/// 编号
/// </summary>
public int TrackIndex {get; set; }
/// <summary>
/// 标题
/// </summary>
public string TrackName { get; set; } = string.Empty;
/// <summary>
/// 歌手
/// </summary>
public Performer Artist { get; set; } = new();
/// <summary>
/// 时长
/// </summary>
public long? Duration { get; set; }
/// <summary>
/// 注释
/// </summary>
public string? Comment {get; set; }
}

/// <summary>
/// 专辑信息
/// </summary>
public class Album
{
/// <summary>
/// 专辑ID
/// </summary>
public int ID {get; set; }
/// <summary>
/// 专辑标题
/// </summary>
public string Title { get; set; } = string.Empty;
/// <summary>
/// 发行年份
/// </summary>
public int Year {get; set; }
/// <summary>
/// 专辑风格
/// </summary>
public string? Style {get; set; }
/// <summary>
/// 曲子数量
/// </summary>
public int TrackNum {get; set; }
/// <summary>
/// 曲目
/// </summary>
public List<Track> Tracks { get; set; } = new();
}</pre>
</div>
如果你不想给歌手/表演者实体独立建表，那此情况可以使用“从属实体”解决，即 Album 管着 Track，Track 管着 Performer。
<div class="cnblogs_code">
<pre>public class TestContext : DbContext
{
// 构造函数
public TestContext(DbContextOptions<TestContext> options) : base(options)
{
}

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Album>(ae =>
 {
 ae.HasKey(a => a.ID);
 // 第一层：Album --> Track，一管多
 ae.OwnsMany(a => a.Tracks, obuilder =>
 {
 // 第二层：Track --> Performer，一管一
 obuilder.OwnsOne(x => x.Artist);
 });
 });
}

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
 configurationBuilder.Conventions.Remove<ForeignKeyIndexConvention>();
}

public DbSet<Album> Albums { get; set; }
}</pre>
</div>
<div>configurationBuilder.Conventions.Remove<ForeignKeyIndexConvention>() 是把 ForeignKeyIndexConvention 约定删除，因为 Album 与 Track 之间会产生外键，而这个约定默认为外键创建索引。把这个约定从预置列表中删掉，表明不会自动创建索引。</div>
<div>然后咱们看一下 EF 是如何创建表的。</div>
<div>
<div class="cnblogs_code">
<pre> // 配置选项
var ctxOptions = new DbContextOptionsBuilder<TestContext>()
.UseSqlServer("server=(localdb)\\MSSQLLOCALDB;
database=db_songs")
.LogTo(msg => Console.WriteLine(msg))
.Options;
// 先初始化数据库
using (var context = new TestContext(ctxOptions))
{
// 确定数据库已创建
 context.Database.EnsureDeleted();
context.Database.EnsureCreated();
// 如果空的，放点东西进去
if (!context.Albums.Any())
{
 context.Albums.Add(new Album
 {
 Title = "神曲集",
 Year = 2025,
 TrackNum = 2,
 Style = "魔幻",
 Tracks = [
 new Track{
 TrackIndex = 1,
 TrackName = "我是初音未来",
 Duration = 5556329L,
 Artist = new Performer{
 Name = "洛天依",
 Alias = "ルオ・テンイ",
 Age = 15,
 Birthday = new DateOnly(2012, 7, 12),
 Gender = "动态性别",
 StageName = "洛天依",
 Brief = "我不吸熊猫烧香"
 }
 },
 new Track{
 TrackIndex= 2,
 TrackName = "我是洛天依",
 Duration = 652224L,
 Artist = new Performer{
 Name = "初音未来",
 Age = 16,
 Alias = "初音ミク",
 Birthday = new DateOnly(2007, 8, 31),
 Gender = "动态性别",
 StageName = "天下第一的fufu殿下",
 Brief = "山东省最具代表性农作物"
 }
 }
 ]
 });
 context.SaveChanges();
}
}
// 筛选数据
using (var ctx = new TestContext(ctxOptions))
{
var q = from a in ctx.Albums
 select new
 {
 a.Year,
 a.Title,
 Tracks = (from k in a.Tracks select new { k.
TrackIndex, k.TrackName, Artist = k.Artist.
Name })
 };
foreach(var obj in q)
{
 Console.WriteLine($"{obj.Year} - {obj.Title}");
 foreach(var t in obj.Tracks)
 {
 Console.WriteLine($"\t{t.TrackIndex}. {t.TrackName}\t
演唱： {t.Artist}");
 }
}
}</pre>
</div>
运行程序，看到创建表的 SQL 语句：
<div class="cnblogs_code">
<pre>CREATE TABLE [Albums] (
 [ID] int NOT NULL IDENTITY,
 [Title] nvarchar(max) NOT NULL,
 [Year] int NOT NULL,
 [Style] nvarchar(max) NULL,
 [TrackNum] int NOT NULL,
 CONSTRAINT [PK_Albums] PRIMARY KEY ([ID])
 );

CREATE TABLE [Track] (
 [ID] int NOT NULL IDENTITY,
 [AlbumID] int NOT NULL,
 [TrackIndex] int NOT NULL,
 [TrackName] nvarchar(max) NOT NULL,
 [Artist_Name] nvarchar(max) NOT NULL,
 [Artist_Alias] nvarchar(max) NULL,
 [Artist_Gender] nvarchar(max) NULL,
 [Artist_StageName] nvarchar(max) NULL,
 [Artist_Age] int NULL,
 [Artist_Birthday] date NULL,
 [Artist_Brief] nvarchar(max) NULL,
 [Duration] bigint NULL,
 [Comment] nvarchar(max) NULL,
 CONSTRAINT [PK_Track] PRIMARY KEY ([AlbumID], [ID]),
 CONSTRAINT [FK_Track_Albums_AlbumID] FOREIGN KEY ([AlbumID]) REFERENCES [Albums] ([ID]) ON DELETE CASCADE
 );</pre>
</div>
由于一个 Album 有多首曲子（Track），所以 Track 需要建立表，而 Track 只引用一个 Performer 实例，故，Track 的 Artist 属性的处理就跟复合属性很像了。Performer 类没有单独建表，而是把它的属性成员分散在 Track 表中。
注意 Track 表是有两个主键的：曲目自己的 ID 和专辑 ID，其中，AlbumID 是外键，引用专辑表中的记录。Track 表可能放着来自同一专辑的曲目，两个主键可以更好地标识。
看看两个表中的记录。
<img src="https://img2024.cnblogs.com/blog/367389/202508/367389-20250810182035539-333842767.png" alt="image" width="440" height="43" loading="lazy">
<img src="https://img2024.cnblogs.com/blog/367389/202508/367389-20250810182420687-1162195842.png" alt="image" width="790" height="56" loading="lazy">
 
但是，如果你坚持 Track 和 Performer 不要建表，那有没有办法解决呢？这个嘛，还真有，可以考虑只建 Album 表，把 Track 和 Performer 变成 JSON 列。其实就是将其化作 JSON，如同文本一样存到一个列中。
看配置代码：
<div class="cnblogs_code">
<pre>protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Album>(eb =>
{
 eb.OwnsMany(x => x.Tracks, ob =>
 {
 ob.ToJson();
 ob.OwnsOne(d => d.Artist);
 });
});
}</pre>
</div>
这个 ToJson 方法只要在根对象上调用一次即可，不用每层对象都调用。比如，咱们这里是让 Tracks 属性存储一个 Track 集合（列表），所以先用 OwnsMany 确定 Album 实体与 Track 对象的主从关系，然后内层操作都用 OwnedNavigationBuilder 类来完成，这时，JSON 对象的顶层（根对象）就是这个 Track 集合，故在 ob 实例上调用一次 ToJson 方法就行，之后不管 Track 类嵌套了多少对象，都自动成为 JSON 对象的一部分（本例中， Performer 对象会自动被处理）。
再次运行程序，这时 Tracks 列只是普通的文本列。
<div class="cnblogs_code">
<pre>CREATE TABLE [Albums] (
 [ID] int NOT NULL IDENTITY,
 [Title] nvarchar(max) NOT NULL,
 [Year] int NOT NULL,
 [Style] nvarchar(max) NULL,
 [TrackNum] int NOT NULL,
 [Tracks] nvarchar(max) NULL,
 CONSTRAINT [PK_Albums] PRIMARY KEY ([ID])
 );</pre>
</div>
然后查询一下这个表，看看 Tracks 字段里面存了啥东东。
<div class="cnblogs_code">
<pre>[
{
"Comment": null,
"Duration": 5556329,
"ID": 0,
"TrackIndex": 1,
"TrackName": "\u6211\u662F\u521D\u97F3\u672A\u6765",
"Artist": {
 "Age": 15,
 "Alias": "\u30EB\u30AA\u30FB\u30C6\u30F3\u30A4",
 "Birthday": "2012-07-12",
 "Brief": "\u6211\u4E0D\u5438\u718A\u732B\u70E7\u9999",
 "Gender": "\u52A8\u6001\u6027\u522B",
 "Name": "\u6D1B\u5929\u4F9D",
 "StageName": "\u6D1B\u5929\u4F9D"
}
},
{
"Comment": null,
"Duration": 652224,
"ID": 0,
"TrackIndex": 2,
"TrackName": "\u6211\u662F\u6D1B\u5929\u4F9D",
"Artist": {
 "Age": 16,
 "Alias": "\u521D\u97F3\u30DF\u30AF",
 "Birthday": "2007-08-31",
 "Brief": "\u5C71\u4E1C\u7701\u6700\u5177\u4EE3\u8868\u6027\u519C\u4F5C\u7269",
 "Gender": "\u52A8\u6001\u6027\u522B",
 "Name": "\u521D\u97F3\u672A\u6765",
 "StageName": "\u5929\u4E0B\u7B2C\u4E00\u7684fufu\u6BBF\u4E0B"
}
}
]</pre>
</div>
现在因为 Track 类是存到 JSON 中，而不映射到数据表，所以 ID 属性不再作为主键，自然就不存在自增长了，所以，两条记录中，ID 都是 0。所以，在 Track 类定义时可以去掉 ID 属性。
<div class="cnblogs_code">
<pre>public class Track
{
/// <summary>
/// 编号
/// </summary>
public int TrackIndex {get; set; }
/// <summary>
/// 标题
/// </summary>
public string TrackName { get; set; } = string.Empty;
/// <summary>
/// 歌手
/// </summary>
public Performer Artist { get; set; } = new();
/// <summary>
/// 时长
/// </summary>
public long? Duration { get; set; }
/// <summary>
/// 注释
/// </summary>
public string? Comment {get; set; }
}</pre>
</div>
再运行一遍应用程序，生成的 JSON 中就没有 ID 字段了。
<div class="cnblogs_code">
<pre>[
{
"Comment": null,
"Duration": 5556329,
"TrackIndex": 1,
"TrackName": "\u6211\u662F\u521D\u97F3\u672A\u6765",
"Artist": {
 "Age": 15,
 "Alias": "\u30EB\u30AA\u30FB\u30C6\u30F3\u30A4",
 "Birthday": "2012-07-12",
 "Brief": "\u6211\u4E0D\u5438\u718A\u732B\u70E7\u9999",
 "Gender": "\u52A8\u6001\u6027\u522B",
 "Name": "\u6D1B\u5929\u4F9D",
 "StageName": "\u6D1B\u5929\u4F9D"
}
},
{
"Comment": null,
"Duration": 652224,
"TrackIndex": 2,
"TrackName": "\u6211\u662F\u6D1B\u5929\u4F9D",
"Artist": {
 "Age": 16,
 "Alias": "\u521D\u97F3\u30DF\u30AF",
 "Birthday": "2007-08-31",
 "Brief": "\u5C71\u4E1C\u7701\u6700\u5177\u4EE3\u8868\u6027\u519C\u4F5C\u7269",
 "Gender": "\u52A8\u6001\u6027\u522B",
 "Name": "\u521D\u97F3\u672A\u6765",
 "StageName": "\u5929\u4E0B\u7B2C\u4E00\u7684fufu\u6BBF\u4E0B"
}
}
]</pre>
</div>
JSON 列的字段名默认与属性名（Tracks）相同，你如果想用其他名字，可以在调用 ToJson 方法时指定。
<div class="cnblogs_code">
<pre>modelBuilder.Entity<Album>(eb =>
{
eb.OwnsMany(x => x.Tracks, ob =>
{
 ob.ToJson("track_list");
 ob.OwnsOne(d => d.Artist);
});
});</pre>
</div>
在创建数据表的时候，列名就会自动变更。
<div class="cnblogs_code">
<pre>CREATE TABLE [Albums] (
 [ID] int NOT NULL IDENTITY,
 [Title] nvarchar(max) NOT NULL,
 [Year] int NOT NULL,
 [Style] nvarchar(max) NULL,
 [TrackNum] int NOT NULL,
 [track_list] nvarchar(max) NULL,
 CONSTRAINT [PK_Albums] PRIMARY KEY ([ID])
 );</pre>
</div>
<img src="https://img2024.cnblogs.com/blog/367389/202508/367389-20250810212727273-1562563444.png" alt="image" width="706" height="38" loading="lazy">
 
===============================================================================================
好了，正题今天就水到这儿了，下面是老周讲故事时间。
曾在微博上收到一条私信说：老周，我感觉你很厉害，好像啥都研究得那么透彻。真佩服你！
这里要纠正一下，老周并不是啥都能研究得很透彻，比如人心，老周就无法研究。其实，老周只不过是这儿会一点，那儿会一点，啥都会，啥都不精。如此而已。
大伙伴们不用佩服老周的，只要你能确定：你的智商和脑子是正常的，那，你也能做到像老周这样的。老周从小就养成一个毛病，爱钻牛角尖。许多事情，仅仅知道是啥是不满足的，就很好奇想要弄清楚为什么。所以在学习一个东西，老周习惯性地把重点放在原理上，为什么会这样，为什么要这样做……老周一向比较自律，能静下心来做自己想做的事。也许，从小练书法确实是有好处的，人不会太急躁。尽管人的精力是有限的，不可能把世上的事情都弄明白。可是，能弄明白一件算一件，好歹对得起自己。如果自己花了心思去学习一个东西，连那是啥玩意儿都搞不懂，那岂不是浪费大好光阴吗？从小老师就教我们（不知道现在的老师还教不教），一寸光阴一寸金，下一句就不必说了吧。所以你看到老周写的文章，很喜欢告诉大伙原理性的东西，哪怕老周写的东西可能有错。至少这也是我的感悟，有错误的话你可以发个私信告诉我的。
现在有些人被别有用心的人误导，连放个P都追求快，快，快，赶着投胎似的。实际上，你可否想过，越是浮躁，你最终的损失越大。同样是花了时间和精力在某件事情上，你这搞搞那搞搞，最后连跟毛都搞不清楚，而别人是一件一件的梳理得一清二楚三通透。到最后，你觉得你比别人跑得更远了吗？
所以啊，有些事情是需要一个过程，该走的路就得走，再急也是徒增烦恼。小时候一直不明白一句话“烦恼即菩提”，这烦恼和菩提树是八竿子打不着的，毫无关系。长大后就懂了，就是毫无关系啊，烦恼就是你给自己找苦吃，把毫无关系的事情硬是往自己的情绪上塞。空想往往不会有收获，但抱着试一试的心态行动了，说不定就有所感悟了。
</div> 
来源：https://www.cnblogs.com/tcjiaan/p/19030612

頁: [1]

琼殿技术论坛's Archiver

【EF Core】聊聊“复合”属性