ef使用sql语句查询单个数据，比如我要查询某表里面的某一个值，该怎么用。谢谢大神

varchar temp（10）

select @temp=z from DB:A where ...

if(@temp==1)

select * from DB:B where...

else if(@temp==2)

select * from DB:C where...

else if(@temp==3)

select * from DB:D where...

这个思路应该是这样的，你自己把代码补充完整，数据类型定好，希望能帮到你

(一) 数据查询应该在哪做

在EF中，面向对象的数据查询主要提供了两种方式：

TEntity DbSet<TEntity>.Find(params object[] keyValues)：针对主键设计的通过主键查找单个实体，会先在EF的本地数据集Local中进行查询，如果没有，再去数据库中查询。

IQueryable<T>、IEnumerable<T>类型的所有数据查询的扩展方法（由于DbSet<T>继承于IQueryable<T>与IEnumerable<T>），如SingleOrDefault，FirstOrDefault，Where等。其中IQueryable<T>的扩展方法会先收集需求，到最后一步再生成相应的SQL语句进行数据查询；而IEnumerable<T>的扩展方法则是在查询的第一步就生成相应的SQL语句获取数据到内存中，后面的 *** 作都是以内存中的数据为基础进行 *** 作的。

以上两种方式为EF的数据查询提供了极大的自由度，这个自由度是我们在封装的时候需要保持的。但是，在阅读不少人（其中不乏工作了几年的）对EF的封装，设计统一的数据 *** 作接口Repository中关于数据查询的 *** 作中，通常会犯如下几种失误：

设计了很多GetByName，GetByXX，GetByXXX的 *** 作，这些 *** 作通常并不是所有实体都会用到，只是部分实体的部分业务用到，或者是“估计会用到”。

定义了按条件查询的SingleOrDefault，FirstOrDefault，Count，GetByPredicate(predicate)等方法，但是对于条件predicate的类型是使用Expression<Func<TEntity, boo>>还是Func<TEntity, bool>很纠结，最后干脆两个都设计，相当于把IQueryable<T>，IEnumerable<T>的方法再过一遍。

定义了获取全部数据的GetAll()方法，但却使用了IEnumerable<TEntity>类型的返回值，明白的同学都知道，这相当于把整个表的数据都加载到内存中，问题很严重，设计者却不知道。

诸如此类，各种奇葩的查询 *** 作层出不穷，这些 *** 作或者破坏了EF数据查询原有的灵活性，或者画蛇添足。

其实，这么多失误的原因只有一个，设计者忘记了EF是ORM，把EF当作ado.net来使用了。只要记着EF是ORM，以上这些功能已经实现了，就不要去重复实现了。那么以上的问题就非常好解决了，只要：

在数据 *** 作Repository接口中把EF的DbSet<TEntity>开放成一个只读的IQueryable<TEntity>类型的属性提供给业务层作为数据查询的数据源

就可以了。这个数据源是只读的，并且类型是IQueryable<T>，就保证了它只能作为数据查询的数据源，而不像开放了DbSet<T>类型那样可以在业务层中调用EF的内部方法进行增、删、改等 *** 作。另外IQueryable<T>类型保持了EF原有的查询自由性与灵活性，简单明了。这个数据集还可以传递到业务层的各个层次，以实现在哪需要数据就在哪查的灵活性。

(二) 循环中的查询陷阱

EF的导航属性是延迟加载的，延迟加载的优点就是不用到不加载，一次只加载必要的数据，这减少了每次加载的数据量，但缺点也不言自明：极大的增加了数据库连接的次数，比如如下这么个简单的需求：

输出每个用户拥有的角色数量

根据这个需求，很容易就写出了如下的代码：

遍历所有用户信息，输出每个用户信息中角色（导航属性）的数量。

上面这段代码逻辑很清晰，看似没有什么问题。我们来分析一下代码的执行过程：

132行，从IOC容器中获取用户仓储接口的实例，这没什么问题。

133行，取出所有用户信息（memberRepository.Entities），执行SQL如下：

SELECT [Extent1].[Id] AS [Id], [Extent1].[UserName] AS [UserName], [Extent1].[Password] AS [Password], [Extent1].[NickName] AS [NickName], [Extent1].[Email] AS [Email], [Extent1].[IsDeleted] AS [IsDeleted], [Extent1].[AddDate] AS [AddDate], [Extent1].1679946990 AS 1679946990, [Extent2].[Id] AS [Id1] FROM [dbo].[Members] AS [Extent1] LEFT OUTER JOIN [dbo].[MemberExtends] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Member_Id]

虽然EF生成的SQL有些复杂，但还是没什么问题

3. 136行，就开始有问题了，每次循环都会连接一次数据库，执行一次如下查询（最后一个1是用户编号）：

exec sp_executesql N'SELECT [Extent2].[Id] AS [Id], [Extent2].[Name] AS [Name], [Extent2].[Description] AS [Description], [Extent2].[RoleTypeNum] AS [RoleTypeNum], [Extent2].[IsDeleted] AS [IsDeleted], [Extent2].[AddDate] AS [AddDate], [Extent2].1679946990 AS 1679946990 FROM [dbo].[RoleMembers] AS [Extent1] INNER JOIN [dbo].[Roles] AS [Extent2] ON [Extent1].[Role_Id] = [Extent2].[Id] WHERE [Extent1].[Member_Id] = @EntityKeyValue1',N'@EntityKeyValue1 int',@EntityKeyValue1=1

试想，如果有100个用户，就要连接100次数据库，这么一个简单的需求，连接了101次数据库，还不得让数据库疯掉了。

当然，有同学可以要说，这里用了延迟加载才会多了很多连接数据库的次数，你可以立即加载啊，把Role角色一次性加载进来。好吧，我们来看看立即加载：

143行，在取所有用户信息的时候使用Include方法把与用户关联的所有角色信息也一并查询出来了，这样在循环遍历的时候就不会再连接数据库去查询角色信息了。但是如果看到执行的SQL语句，估计你想死的心情都有了。执行的查询如下：

SELECT [Project1].[Id] AS [Id], [Project1].[UserName] AS [UserName], [Project1].[Password] AS [Password], [Project1].[NickName] AS [NickName], [Project1].[Email] AS [Email], [Project1].[IsDeleted] AS [IsDeleted], [Project1].[AddDate] AS [AddDate], [Project1].1679946990 AS 1679946990, [Project1].[Id1] AS [Id1], [Project1].[C1] AS [C1], [Project1].[Id2] AS [Id2], [Project1].[Name] AS [Name], [Project1].[Description] AS [Description], [Project1].[RoleTypeNum] AS [RoleTypeNum], [Project1].[IsDeleted1] AS [IsDeleted1], [Project1].[AddDate1] AS [AddDate1], [Project1].[Timestamp1] AS [Timestamp1] FROM ( SELECT [Extent1].[Id] AS [Id], [Extent1].[UserName] AS [UserName], [Extent1].[Password] AS [Password], [Extent1].[NickName] AS [NickName], [Extent1].[Email] AS [Email], [Extent1].[IsDeleted] AS [IsDeleted], [Extent1].[AddDate] AS [AddDate], [Extent1].1679946990 AS 1679946990, [Extent2].[Id] AS [Id1], [Join2].[Id] AS [Id2], [Join2].[Name] AS [Name], [Join2].[Description] AS [Description], [Join2].[RoleTypeNum] AS [RoleTypeNum], [Join2].[IsDeleted] AS [IsDeleted1], [Join2].[AddDate] AS [AddDate1], [Join2].1679946990 AS [Timestamp1], CASE WHEN ([Join2].[Member_Id] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C1] FROM [dbo].[Members] AS [Extent1] LEFT OUTER JOIN [dbo].[MemberExtends] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Member_Id] LEFT OUTER JOIN (SELECT [Extent3].[Member_Id] AS [Member_Id], [Extent4].[Id] AS [Id], [Extent4].[Name] AS [Name], [Extent4].[Description] AS [Description], [Extent4].[RoleTypeNum] AS [RoleTypeNum], [Extent4].[IsDeleted] AS [IsDeleted], [Extent4].[AddDate] AS [AddDate], [Extent4].1679946990 AS 1679946990 FROM [dbo].[RoleMembers] AS [Extent3] INNER JOIN [dbo].[Roles] AS [Extent4] ON [Extent4].[Id] = [Extent3].[Role_Id] ) AS [Join2] ON [Extent1].[Id] = [Join2].[Member_Id] ) AS [Project1] ORDER BY [Project1].[Id] ASC, [Project1].[Id1] ASC, [Project1].[C1] ASC

(三) 导航属性的查询陷阱

我们再来回顾一下导航属性的长相（以用户信息中的角色信息为例）：

可以看到，集合类的导航属性是一个ICollection<T>类型的集合，其实现类可以是通常使用List<T>或者HashSet<T>。用了ICollection<T>，就限定了集合类的导航属性是一个内存集合，只要用到这个导航属性，就必须把集合中的所有数据都加载到内存中，才能进行后续 *** 作。比如上面的例子中，我们的需求只是想知道用户拥有角色的数量，原意只是要执行一下SQL的Count语句即可，却想不到EF是把这个集合加载到内存中（上面的语句，是把当前用户的所有角色信息查询出来），再在内存中进行计数，这无形中是一个很大的资源浪费。比如在一个商城系统中，我们想了解一种商品的销量（product.Orders.Count），那就可能把几万条订单信息都加载到内存中，再进行计数，这将是灾难性的资源消耗。