ASP.NET MVC学习---（三）EF简单增删改查

那么现在我们已经大概从本质上了解了ef

巴拉巴拉说了一大堆之后

总算要进入ef的正题了

总在口头说也太不行了是吧~

没错，现在要用ef进行一些实际的操作
做什么呢？
就做一个入门级的增删改查操作吧
废话不说，开搞~

首先
操作的数据库还是之前建立的例子
关系图：

已经是我们的老朋友啦
简单又好用~

还是建立一个控制台应用程序
根据数据库生成ADO.NET实体数据模型


准备工作做完之后
现在可以放开那个鼠标
放手敲代码吧~

使用EF最最开始要做什么事情？
准备一个EF上下文对象
因为EF的所有操作都要通过这个上下文对象来完成
之前我们说过

这个Model.Context.cs文件就是EF的上下文
后缀名是cs的是什么文件
是不是有一种似曾相识的赶脚？
不就是C#中的类嘛！
双击点开它瞧瞧

是不是一个很标准的名字叫做Entities的类？
其中包含了两个类型为DbSet集合的属性，分别是T_Products和T_Users
是不是又很熟悉
没错
这就是上下文对象中保存的
对应数据库表的属性
我们可以直接通过这个Entities.属性的方式方便快速的操作数据库
爽吧？
具体怎么爽
马上你就知道~

实例化一个Entities上下文对象


那么现在我们来想一想
使用ADO.NET进行新增操作的时候需要做什么？
无非就是new一个实体类对象，为该对象的各个属性赋值
在根据这么属性的值来生成sql语句发送到数据库

这种思路也通用于EF
但是更加简便
不信？
上证据：

//首先new一个T_Users对象，并为其UserName属性赋值
            T_Users user = new T_Users() { UserName = "JChubby" };

然后使用之前实例化的EF上下文对象，找到T_Users属性，在点一下，是不是有一个很显眼的Add方法？

再看看这个Add方法的参数

是不是很明显的一个T_Users实体对象！
没错，不要怀疑了，就是它了
将之前new的实体对象传给Add方法
然后调用一下dbEntities的SaveChanges方法
注意，EF非查询操作只有在调用了这个方法之后才会向数据库发送请求！
这是一个很重要的方法，以后我们会详细的针对它展开讨论
现在暂时放过它吧~

整个新增方法如下：

private static void Create()
        {
            T_Users user = new T_Users() { UserName = "JChubby" };
            dbEntities.T_Users.Add(user);
            dbEntities.SaveChanges();
            Console.WriteLine("添加成功！");
        }

没了
没了？！
怎么就没了？
这才几行代码
放心吧~
不骗你
不行走一个试试~
在Main方法中调用Create方法，运行

你还不确定的话回头去看数据库
没有这个数据你来找我~

那么此时你就会觉得EF很简单
因为有新增的方法肯定会有删除啊，修改啊之类的方法，到时候直接调不就行了~
先别着急下定论~
一是一横，二是两个横，三是三个横，难道四就是四个横吗？
很明显不是

先来看看Delete删除方法
EF中实现删除有两种方式
版本一：

//实例化一个T_Users对象，并指定Id的值
            T_Users user = new T_Users() { Id = 1 };
            //将user附加到上下文对象中，并获得EF容器的管理对象
            var entry = dbEntities.Entry(user);
            //设置该对象的状态为删除
            entry.State = EntityState.Deleted;
            //保存修改
            dbEntities.SaveChanges();
            Console.WriteLine("删除成功！");

这个应该可以理解的吧，虽然思路有点奇葩

版本二：

private static void Delete()
        {
            //实例化一个T_Users对象，并指定Id的值
            T_Users user = new T_Users() { Id = 1 };
            //将user附加到上下文对象中
            dbEntities.T_Users.Attach(user);
            //删除user对象
            dbEntities.T_Users.Remove(user);
            //保存修改
            dbEntities.SaveChanges();
            Console.WriteLine("删除成功！");
        }

这不是有一个Remove吗，一看就知道是删除用的呀
但是这个Attach是什么鬼东西？
直接删除不就好了
干嘛还要附加，然后在删除
这不是闲着蛋疼吗？
Attach是真的附加方法
但是Remove就不是真的删除方法了
没证据我会乱说？
我们在Attach方法之后加一句代码

var entry = dbEntities.Entry(user);

作用是方便看清楚entry变量的State属性，也就是user实体的状态信息
在Remove和SaveChanges方法分别设上断点，运行进行调试
程序执行完Attach之后在Remove停下

注意看下面的监视区域
user实体的状态信息为Unchanged
从字面上的意思来理解就是没有改变的
那么接着运行，执行Remove方法，停在SaveChanges

看到那个大红的Deleted了吗？
这就证明了
Remove方法并不是将实体从数据库中删除
只是将实体的State属性设置成Deleted
在上下文对象调用SaveChanges方法的时候
它一看到这个实体的State是Deleted
那么它就会向数据库发送删除的请求
其实第二个版本本质上还是继续这第一个版本的操作
只是简便了一些

至于查询方法
那就更爽了
怎么爽？
听说过Lambda吗？
没有？
那你就out了！
真的，赶紧去冲一下电，不骗你
因为在EF中使用Lambda真的是太爽了（当然也可以用Linq，这也很爽！）
怎么爽？
看看下面的代码你就知道了

private static void Query()
        {
            //取出数据库T_Users表中所有的数据，并转成集合
            List<T_Users> users = dbEntities.T_Users.Where(u => true).ToList();
            //循环遍历输出所有的user实体的UserName属性
            users.ForEach(u => Console.WriteLine(u.UserName));
        }

好了，批量查询搞定
就两行代码~
这里需要注意的是
Where方法的参数是一个Lambda表达式，并且返回的是IQueryable的泛型接口
所以如果只是查询一条数据，记得用FirstOrDefault方法，只返回一条数据
但是在这里又牵扯到了前面我们所说过的EF的延迟加载功能
详细介绍实在太长~
想了解的同志们小手一抖，轻轻带走EF延迟加载的本质原因

除了牵扯到延迟加载
还涉及到一个小问题
现在我们将代码改为只查询单个数据

var user = dbEntities.T_Users.Where(u => u.Id == 3).FirstOrDefault();
            Console.WriteLine(user.UserName);

在Console.WriteLine设置断点，运行
将user对象添加监视
注意看监视栏

是不是很惊悚？！
user的类型怎么变成System.Data.Entity.DynamicProxies.T_Users_185D30475F9AA2490A...
什么乱七八糟的东西
不是T_Users类型的对象吗？
终于找到为什么使用返回来的实体对象序列化成json格式
返回前台老是报错的原因了
因为人家根本就不是T_Users类啊！
完全两个不同的类型！

其实这是一个EF的动态代理类
那么这个动态代理类是什么飞机？
因为这里又涉及到了后面的修改等操作
所以这个动态代理类放在后面修改方法的地方在详细说明



最后我们来看看修改的方法
微软官方推荐的做法是先查询，后修改
就是先把要修改的数据查出来，然后修改完成之后再保存到数据库
具体操作如下：

private static void Modify()
        {
            //将Id为2的T_Users数据取出
            var user = dbEntities.T_Users.Where(u => u.Id == 2).FirstOrDefault();
            Console.WriteLine("修改之前：" + user.UserName);
            //修改UserName属性
            user.UserName = "222222222222222";
            //保存修改
            dbEntities.SaveChanges();
            Console.WriteLine("修改之后：" + user.UserName);
        }

这么做虽然也是挺方便的吧
但是总是觉得怪怪的
因为我们一般做修改的时候直接实例化对象穿进去，然后在根据Id修改对应数据的值
没用过先查询后修改的法子呀
接下来看看按照我们平常思路的修改方法

//实例化user对象
            T_Users user = new T_Users() {Id = 1, UserName = "2222"};
            //将user加入EF容器中，并获得EF容器的管理对象
            var entry = dbEntities.Entry(user);
            //设置对象的状态为Unchanged
            entry.State = EntityState.Unchanged;
            //设置要修改的属性的IsModified=true，表示这个属性是要修改的
            entry.Property("UserName").IsModified = true;
            //保存
            dbEntities.SaveChanges();

但是现在又觉得奇怪了
为什么要先设置对象的状态为Unchanged
然后在设置要修改的属性的IsModified=true
这好像又多此一举了？
EF修改数据的时候有一个特点
它会根据要修改的属性生成update语句
而不是将每个属性都加入到update语句中
譬如版本一的修改
我们只对UserName属性做了修改
那么最后生成的update语句也只会有UserName
想想看当一个表中字段有n多个时
但是我们只需要修改一个字段的值
那么update语句是写上全部的属性好
还是只写要修改的字段好？
答案不是很明显嘛！
使用版本一方法进行修改时
EF只生成有赋值过的属性
而在版本二中
我们同样希望能够使用EF的这个特性进行sql语句的优化
但是如果直接这么做的话

var entry = dbEntities.Entry(user);
            entry.State = EntityState.Modified;

想都不用想肯定是生成所有的属性
所以我们需要先把实体的State设置为Unchanged
然后为要修改的属性
一一将它们的IsModified设置为true
什么意思很明显了吧？
两个修改版本最后的效果是一样的
怎么选择看个人爱好了~
那么是不是觉得EF的这个优化挺不错的？
但是我们修改user对象的哪个属性EF上下文是怎么知道的？
难道它时时刻刻都在监控user对象的信息吗？
这显然是不太可能的
它完成这个工作是靠着一个动态代理类来实现的
没错
就是前面查询操作提到的那货
下面给出一张图来解释

额...画的很难看
意思也表达的不是很全面
如果看不懂的同志
老方法
google之~


好了，简单的增删改查
get it！
期待明天的行程
一路走过来
总是需要记录一些风景
待人老了花谢了
我们还有记忆可以回忆~
那么今天记录就到此结束~