.NET WebApi 实战第四讲之EF进行数据库的写操作
休息了两天，停止了笔耕，人老了，上了年龄了，就变懒了。今天勉强强迫自己继续实战的演练，本节我们就接着上一节，继续进行接口的实战及数据库方面的技能点。
上一节，我们主要是从数据库进行读数据，但是实际的业务场景中，需要前端(或管理后台)调用接口，向数据库先产生数据，即插入数据，后面的业务根据这些数据产生更多的业务。所以，本节，我们就来讲讲向数据库插入数据操作。
插入数据前，我们的csdnUser表中有一个字段:id varchar(20),数据库中每一条数据都有自己的id，并且必须是唯一的。注意这个唯一，指的是本表唯一。不同表中的ID有可能会出现重复，这完全是合理的，只要保证同一个表的主键id唯一即可。
那么向数据库插入数据，就免不了给对应的EF实体ID赋值，我们如何保证ID的唯一呢？C#中本身就提供一个类：Guid:
我们可以通过调用Guid.NewGuid().ToString();方法来生成唯一的ID。回头来看看我的数据库设计时，设计的ID的长度仅仅为20位，但是些方法生成的是32位，是保存不进去的，长度超出了。那么怎么办？
1、要么截短
2、要么把数据库的设计长度调整为32位
这里我们选择第2条，保证生成的数据的唯一性，截断，并不能保证数据的唯一性了，失去了本类实现存在的价值了。如下修改为32位长度，保存表。
下面我们来编写新的方法，通过接口调用，向数据库中写入数据。向UserController类里面实现以下方法：
然后我们运行项目：
这是什么鬼？为什么返回了上面Get方法接口的内容？可是你明明请求的是addNewUser方法！这是什么原因呢？
这里是因为，一个API 控制器中只能有一个GET、POST、PUT、DELETE方法！如果明显标注，则都默认是GET方法！这里的标注指的是：[HttpGet]、[HttpPost]指令！
即：https://localhost:44309/api/user/xxx，后面无论写的是什么方法，都会最终执行的是GET方法，根本不会执行你写的方法。当然如果你可去重新写GET方法，因为另写方法，会让代码更优雅，更有逼格！现在我们调整我们的代码如下，以进一步理解这些[HttpGet]、[HttpPost]指令究竟是什么东西，我们将再加一个方法名为getAllUsers，然后运行代码：
我们看到了如下错误：
{"Message":"出现错误。","ExceptionMessage":"找到了与该请求匹配的多个操作: \r\n类型 WebApplication.Controllers.UserController 的 Get\r\n类型 WebApplication.Controllers.UserController 的 getAllUsers","ExceptionType":"System.InvalidOperationException","StackTrace":" 在 System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext)\r\n 在 System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext)\r\n 在 System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)\r\n 在 System.Web.Http.Dispatcher.HttpControllerDispatcher.d__15.MoveNext()"}
它的意思就是说，在你这个控制中存在两个Get方法，不知道执行哪一个了，那就异常了！注意这里所谓的两个GET方法，是指方法的HTTP指令一样[HttpGet]、输入参数一样！而不是说方法名一样！[HttpGet]默认是省略的！所以，我们这里确实存在两个GET方法，默认模板生成的Get方法及我们自己实现的一个GET方法！在实际开发中，我们更倾向于使用后面这个GET方法，从语义上更好理解及阅读，所以，我们删除掉第一个GET方法即可：以下两种调用方式均正确的返回了我们期待的数据。但是实际开发中，我们不建议你使用第一种方法调用，这样的方法调用太隐晦！懂的人知道，这是在调用UserController的get方法或者是在调用UserController被标记为[HttpGet]的方法！不懂的人，根本不知道这是个什么鬼！
故而，强烈建议我们通过第二种方式来调用，显而易见！后期维护也很方便。
我们顺便调用一下我们的另一个方法看看：
你看，它还是走了上面的GET方法。因为你这样调用，既没有变量的输入，.NET API仍然是去找此类里面的GET方法去执行！
在进行复杂的HTTP参数实战之前，我建议我们还是将addNewUser改造的简单点，让你看的懂，更容易理解。我们将其改造为如下格式：输入 一个用户名、一个手机号，然后生成一个用户，保存到数据库中。如下所示：
修改我们的URL为：
https://localhost:44309/api/user/addNewUser?name=xx&mobile=13288889999
可以看到，有对应的参数及值！我们看看执行的结果是什么：
咦？又异常了！这个学习起来何等艰难。。各种异常。。头疼不？没事，正是因为有这些异常，才会让你提升技能，才会让你于实战中补强自己！
我们如上，依次展开异常信息，仔细分析问题，不要脑仁轰轰的傻掉就行。我们看到，我们定义的ID长度是32位的，但你数数你的长度是多少？所以，问题就一目了然了，我们只需要调整我的数据即可，长度必须小于等于设计的长度，超出就不行了。如下，我们调整生成ID的格式，这个格式，同学们可以自己搜索，记住即可。
然后再运行起来，还是在报错！。。。。这。。。。。到底。。。。是怎么了。。。。
不慌，莫慌。。。莫慌。。我们想想是哪里出了问题。我们修改了数据库字段的长度，怎么没有重新生成EF呢？敲脑袋，这是知识点，记住！！
同时对DataProvider再生成一次！任何数据库的修改，对应的数据EF数据模式都必须重新生成！同学们，重点记住。
我们现在再来运行起来，看看数据的插入：
经过我们不懈的努力，代码终于运行正常!来来，我们去查一下数据库，看看数据。
现在回过头来看看，体验一下：
你有没有发现，你全部并没有在代码中书写什么insert into数据库语句！这就是EF的便利之处！它就是你的数据模型与数据为之间的桥梁，只需要开发者将重心关注在逻辑层，一心一意的去写逻辑。数据库的操作尽量交给EF去做。
好了，本节教程就到这里，教程过程中所出现的错及重点信息，希望同学们牢记！
