spring mvc用于从数据库一个表里获取一列数据处理后存入另一个表里方法

代码是连在一起的么？建议你把变量定义成全局的，不要放在while循环里面，如下：

String bookid = “”；

while(resnext()){

bookid=resgetString(1);

｝

而且Connection 第一次已经取了，也可以这样定义了之后直接在下面进行使用，没必要再写一遍

从控制器到视图的几种传参都可以实现

1ViewData["data"]

2TempData["data"]

3ViewBagdata

4ViewDataModel

前面几种用法类似于session，在控制器中设置，在试图中使用。

Model类似于activeReport的数据绑定，试图中设定后，试图中自动显示，当然试图事前也要绑定Model的子项。

二、查询问题分析

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

在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当作adonet来使用了。只要记着EF是ORM，以上这些功能已经实现了，就不要去重复实现了。那么以上的问题就非常好解决了，只要：

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

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

(二) 循环中的查询陷阱

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

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

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

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

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

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

133行，取出所有用户信息（memberRepositoryEntities），执行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]1683320865 AS 1683320865, [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]1683320865 AS 1683320865 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]1683320865 AS 1683320865, [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]1683320865 AS 1683320865, [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]1683320865 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]1683320865 AS 1683320865 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是把这个集合加载到内存中（上面的语句，是把当前用户的所有角色信息查询出来），再在内存中进行计数，这无形中是一个很大的资源浪费。比如在一个商城系统中，我们想了解一种商品的销量（productOrdersCount），那就可能把几万条订单信息都加载到内存中，再进行计数，这将是灾难性的资源消耗。

以上就是关于spring mvc用于从数据库一个表里获取一列数据处理后存入另一个表里方法全部的内容，包括:spring mvc用于从数据库一个表里获取一列数据处理后存入另一个表里方法、mvc怎么在试图里显示数据库的数据、MVC4+EFcodefirst中如何处理数据库历史记录的保存和查询等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！