一个系统的复杂度，往往因为表的繁多页变的越来越复杂，维护、开发等维度都会变的越来越广，越来越难以理解。这其中就包括数据处理方面，同一个业务场景的数据保存在不同的表中，就会出现多表联查这种不可避免的情况，当然本身所有数据库系统都是支持联查的，无论是左联查(left join)还是右联查(right join)，亦或是模糊查寻。但是我们使用的是EF技术，是尽量避免去过多在数据库中进行操作，EF本身就是让我们注重精力在业务层面！所以，EF的联查也是一种技能，我们本节就重点实战EF的联查，看看看怎么写。在实战联查之前，我们有必要先实现api的POST实现 ，向学生成绩表中添加数据，将数据准备就续，我们再进行EF的多表查询功能实战。所以本节的重点是API的POST方法实现，为下一节的EF多表联查做好准备。
首先我们打开我们的SSMS，新建一个学生成绩表，包括各个学科的成绩。如下字段，保存为userAchievement表，为了学习演示方便，建议你所有的列名、数据类型都与我完全一致！别忘了设置主键！
打开我们的项目，选择DataProvider项目中的Model.edmx，双击打开:
在空白处右键：选择"从数据库更新模型(U)"：
依次选择我们刚才新那家的学生成绩表：点击右下角的完成，等待生成完毕。
生成完毕后，我们便可以看到新的模型显示：
右键选中DataProvider 项目,选择重新生成！如果不重新生成，你是无法使用对应的EF模型的！生成后，再去展开Model.tt文件，可以看到，已经有了对应的模型！
至此，数据模型已经准备就续，现在我们实现一个POST方法，并且通过Postman工具调用此方法，向学生成绩表中写入数据！
关于postMan,我也给你准备好了第三方的教程 ，你照着学习了解安装即可，它只是一个接口测试工具。点击此处学习了解安装
打开我们Webapplication项目，在ApiModel控制器中定义成绩数据模型如下：此数据模型的目的就是在POST方法中作为接收前端传过来的实体参数。
实现如下方法，同时添加事务处理，将们的业务逻辑写在try语句里面，如果出现问题则事务回滚还原：
这里有必要讲解一下：csdnStudyEntities，这是什么东西呢？我们按住键盘的Ctrl键同时鼠标单击类名称，进入这个类的定义：
csdnStudyEntities其实就是我们建立的数据库！与库存在对应关系。下面红枉所示就是对应我们库里面的表！明白了吧！
你也许好奇的已经看到了我们每个方法里面都用到了using(){}语句，
using(){}语句方法，是为了能够及时的释放资源而设计的！当我们做一些比较占用资源的操作，而且该类或者它的父类继承了IDisposable接口，这样就可以使用using语句，在此范围的末尾自动将对象释放，常见的using使用在对数据库的操作的时候。
继续我们的接口实现！我们在try语句的内部实现以下逻辑：
至此，我们的POST方法已经写完，下来，我们需要进行测试，因为这个是POST方法，区别于GET方法将所有的参数以Key=value的形式直接拼写在URL后面。POST方法的所有的参数是在HTTP里面的BODY里面放着，是隐藏的，URL里面不会出现参数，所以，此时就必须使用POSTMAN这个测试工具进行测试了。先把我们的API运行起来。
在postman中进行配置：分别选择请求方法为POST，URL为https://localhost:44309/api/user/saveUserAchievement
Headers中添加我们此接口要正常响应的协议：Content-Type=application/json。你输入时会有自动提示，正确填写即可。
然后我们切换到body选项卡上：
配置接口参数：
{
"uid":"99D0ACDFE5C24936996F31D6A7C2EF63",
"literature":"98",
"math":"97",
"enlish":"94",
"bios":"96",
"physical":"99",
"history":"99",
"createDate":""
}
这里的uid从哪里来的呢？打开我们的数据库SSMS，在我们的库上右键新建查询：
给哪个用户写入数据，就必须是哪个用户的id，明白了吧，你需要正确填写你查出来的id，否则，根据我们的逻辑，你是无法正常将数据写入数据库的！
在我们的方法中打一个断点，当接口调用的时候，我们方便查看请求参数值：
上面准备就续后，在postman中点击右边的send按钮，调用接口：
不出意外，我们的接口断点会被命中，你可以看看实体的值！将鼠标移动到参数名t上，依次展开，你便看到了传输过来的值！如下：
你可以按键盘上的F10一步一步执行，直到return.或者你点击上方的"继续"按钮，直接运行完成跳出断点。看看postman的返回！
是不是非常完美，现在我们去查一下我们的成绩表，看看数据！
OK，非常完美，我们已经成功的通过POST方式将数据保存到我们的表中，这是何等的顺利！顺利之余，我们还是需要冷静的来想想这些流程有存在的问题：
第一个问题：数据模型涉嫌重复，新定义的数据模型毫无意义：
难不成我们要向不同表里面插入数据，需要定义那么多的数据模型吗？这个Achievement模型与EF生成的userAchievement何等的相似！！我们能不能直接使用EF生成的userAchievement呢？答案是可以的！没有任何问题！这里提出这个问题的目的是，我在实际项目开发中遇到了太多这样重复定义数据model的案例，真的是让人啼笑皆非！哭笑不得！所以，同学们，你们自己改造一下这个方法，使用EF生成的userAchievement，进行测试，中途出现的问题，自我排查解决，好好掌握一下基本的技能。
第二个问题：我们可不可以使用一种动态模型做为输入参数？为什么呢？可以将接口业务逻辑与EF生成的模型隔离开！新增加 如下方法：
在新接口处打个断点，将saveUserAchievement([FromBody] Achievement t) 方法注释掉，如果你不注释，你将会得到新的报错！原因是不能同时出现两个POST方法！保存运行代码：
打开postMan，替换接口API，其它所有数据不要动，点击Send按钮：看到依然运行保存成功
查一下数据库表，看一下数据：成功插入两条数据。
至此，POST方法教程实战完毕。同学们如往常一样，多进行总结归纳学习。话锋一转，但是！我们发现，我们的两个POST方法不能共存！不放，你把两个POST方法放开，然后通过postman调用接口，看看结果：
它的意思是说，找到两个匹配的接口，不知道执行哪个了！我们实际开发中，一个控制器包括多个POST方法是非常可能的！那么如何支持多POST方法呢？这个时候，我们就得调整路由规则了！
方案一、修改路由模板，如下
将其修改为：
运行postman,看看结果：
方案二、将方案一的方案还原为原来的格式，即删除掉/{action}。在控制器中实现动态路由配置。更灵活。
运行，看看结果：
至此结束。
