[NewLife.XCode]扩展属性（替代多表关联Join提升性能）

NewLife.XCode是一个有10多年历史的开源数据中间件，支持nfx/netstandard，由新生命团队(2002~2019)开发完成并维护至今，以下简称XCode。

整个系列教程会大量结合示例代码和运行日志来进行深入分析，蕴含多年开发经验于其中，代表作有百亿级大数据实时计算项目。

开源地址：https://github.com/NewLifeX/X （求star, 743+）

为何需要扩展属性

XCode不支持多表关联查询，单表查询利于优化以及分表分库，一切Join都可以借助扩展属性实现，配合缓存使用可以达到更好的效果！

（XCode前期支持多表关联，直到2008年才正式废除）

“扩展属性”是2007年起XCode特有叫法，不同于其它任何场景的意义（如Silverlight/WPF）

前文《实体类详解》中有提到一个学生班级的实体类模型，一个典型需求是查询学生列表时希望暂时班级名称或者其它信息。于是有：

select s.*, c.name where student s left join class c on s.classid=c.id

sql语法千变万化，如果要支持多表关联join，就很难做到统一查询风格，更是难以优化。

于是XCode放弃支持多表关联，宁可拆分为多次查询。令人惊讶的是，不仅性能没有下降，反而大大提升了，主要因为单表小查询有多级缓存的加持！

扩展属性用法

使用扩展属性来实现关联查询，本质上就是多次查询！

如上，这是一个经典的多表关联场景，学生表带有班级ID字段，同样还有产品和分类表等等。

这是XCode根据模型文件自动生成的代码，因为字段名ClassID刚好是Class表加上它的主键ID，并且都是整型。

对于实体对象来说，student.Name是学生名称，student.ClassName是班级名称。

看起来它们就像是一张表的属性字段，这就是扩展属性的由来，不仅仅是多表关联属性，还可以是其它属性，为区别于数据字段属性，统称为扩展属性！

扩展属性先准备一个Class属性，再加一个ClassName，主要是为了方便某些场合使用 student.Class。

当然，执行一次查询得到student后，不论是访问student.Class还是访问student.ClassName，都会触发一次Class.FindByID，可以理解为执行一次查询（不一定是数据库）。

在Web页面上，如果每页显示20个学生，那么先要执行 select * from student limit 20，然后展示学生列表时，因为需要班级名称，触发扩展属性查询。

可以认为，理论上这个页面需要查询1+20次。

扩展属性为什么不写成 public Class Class => Class.FindByID(ClassID) 呢？

其实虽然看起来简单，但是还得考虑一个可能，同一个student对象可能多次访问student.ClassName，这么写岂不是每次访问都会执行Class.FindByID？

因此，XCode设计了扩展集合Extends，可以认为是一个字典，每个扩展属性都经过它走一遭，如果查询过一次就缓存起来，避免反复查询。

Extends.Get第一个属性是扩展属性名，决定是否有缓存，第二个是没有缓存时要执行的委托。

这就是扩展属性缓存，默认缓存时间10秒，足够抗住短期内成千上万次重复调用。

扩展属性优化

尽管有Extends扩展属性缓存支持，但每个对象还是要执行一次Class.FindByID查询，损耗还是不小的。

在XCode里面，根据主键而设计的查询（如FindByID）往往带有很好的缓存优化。

如上，这是XCode默认生成的代码，当Class表数据不足1000行时，走实体缓存。

也就是说，Meta.Cache时执行一次 select * from student 返回所有行，并缓存起来。后面的Find实际上是在缓存中查找。实体缓存有效期默认10秒。

只有数据表达到1000行，才走 Find(_.ID==id) 数据库查询 select * from class where id=? 。然而XCode下层还有一个数据层缓存，相同select查询默认缓存10秒

此外，也可以根据业务特点采用单对象缓存，例如跨境电商的产品种类特别多（10万+），可以采用字典式的单对象缓存。

因此，在学生类那边看起来访问属性会触发多次Class.FindByID，殊不知它内部别有洞天，三级缓存（实体缓存、对象缓存、数据缓存）等着伺候！（后续专文介绍缓存）

回到开头的例子，一个列表页显示20个学生，理论查询次数1+20次，在多级缓存加持的扩展属性下，99.99%的时候只会查询1次，而班级表的关联，完全在内存缓存中进行。

一次简单的单表查询，显然要比join班级表的查询要快得多！

魔方的特别支持

在上述扩展属性中，注意到ClassName属性上有一个Map特性。

它表示映射，本对象的ClassID字段，映射到Class类的ID字段。

在魔方列表页中，本来显示冷冰冰ClassID的地方，就会变为显示友好的ClassName。

在魔方表单页中，本来显示数字框ClassID的地方，也会变成显示下拉列表框。

如果下拉列表库内容很多，可以精简Map特性，只要第一个参数指明本地字段，而不需要第二第三字段表示的目标字段。此时在魔方表单页会显示数字框，但是后面显示ClassName

到此，你还认为多次查询一定比单次Join慢吗？

​