Linq to Sql：N层应用中的查询(上) : 返回自定义实体

时间：2022-03-13 22:54

原文:

如果允许在UI层直接访问Linq to Sql的DataContext，可以省去很多问题，譬如在处理多表join的时候，我们使用var来定义L2S查询，让IDE自动推断变量的具体类型(IQueryable<匿名类型>)，并提供友好的智能提示；而且可以充分应用L2S的延迟加载特性，来进行动态查询。但如果我们希望将业务逻辑放在一个独立的层中(譬如封装在远程的WCF应用中)，又希望在逻辑层应用Linq to sql，则情况就比较复杂了；由于我们只能使用var(IQueryable<匿名类型>)，而var只能定义方法(Method)范围中声明的变量，出了方法(Method)之后IDE就不认得它了；在这种对IQueryable<匿名类型>一无所知的情况下，又希望能在开发时也能应用上IDE的智能感应，我们该怎么定义层之间交互的数据传输载体呢？又如何对它进行动态查询呢？

内容比较多，分上下两篇，上篇介绍查询返回自定义实体，下篇介绍动态查询。

下面来看一个示例（以NorthWind数据库为示例），现在我们要在界面上展示某个用户什么时间订购了哪些产品。

如果允许在UI层直接访问DataContext，我们可以这样来写：

1. 使查询结果中的列与对象中的字段和属性相匹配的算法如下所示：
- 1.1 如果字段或属性映射到特定列名称，则结果集中应包含该列名称。
- 1.2 如果未映射字段或属性，则结果集中应包含其名称与该字段或属性相同的列。
- 1.3 通过先查找区分大小写的匹配来执行比较。如果未找到匹配项，则会继续搜索不区分大小写的匹配项。
2. 如果同时满足下列所有条件，则该查询应当返回（除延迟加载的对象外的）对象的所有跟踪的字段和属性：
- 2.1 T 是由显式跟踪的实体。
- 2.2 为 true。
- 2.3 实体具有主键。

否则会引发异常。

我愣是看了好多遍，还是没有搞明白，为啥将结果集转换到对象集合时L2S把我增加的字段给抛弃了……

4. 继承默认实体定义

既然不让我在L2S生成的默认实体上直接进行扩展，那我可以派生一个实体并添加我们需要的字段吗？

可行性 缺点扩展默认实体定义否 -- 使用Translate来返回自定义实体否 -- 执行TSQL返回自定义实体否 -- 继承默认实体定义否 -- 显式自定义实体是麻烦，要自己Code，定义新的实体类型使用视图/存储过程/自定义函数是不够灵活，无法为每个应用场景都去订制视图自定义对象转换器是继承关系可能会被滥用；返回的实体集合是个黑盒子，上层可能不知道实体的哪些属性可用，哪些不可用 Entity Framework 貌似可行 --

Linq to Sql：N层应用中的查询(上) : 返回自定义实体,布布扣,bubuko.com