现在一共有两个实体

争对CompanyController创建Action

CompanyDto现在主要是用来做输出的，我们的post是做输入，输入参数和输出参数通常是不一样的。当然也偶尔有时候是一模一样的

添加CompanyAddDto信用做新增的实体。不同作用的dto还是都要单独建立的，以为随着业务需求的变化，它后续有可能还是不一样的。分成多个类dto比较有利于重构。查询、创建、更新这三类分别是三个不同的dto

这里的[FromBody]可写可不写。

争对低版本的.net core的版本，如果传进来的对象是空的 就抛出400错误。

博主记得最早的.net core版本里面好像是没有[ApiController]这个Attribute的，


在那个时候或者是你没有使用[ApiController]这个Attribtue的是时候，就需要检查下请求里面body里面的参数，是否正确的转化成了我们的CompanyAddDto这个类。
当请求的body里面什么都没有的时候，或者是里面的参数不正确的时候，那么我们的这个company参数就会变成null


现在我们就不需要手动的去检查传递的companyAddDto对象是否为空对象，因为我们的Controller使用了[ApiController]这个Attribute。
如果遇到了刚才说的那种情况传递说来的对象为空，那么框架会自动返回400 BadRequest

所以这里我们可以把这段代码去掉了。框架会自动的帮我们判断，并返回400BadRequest

Mapper映射

传递过来的对象，我们首先要转换为Company

AutoMapper的映射

在这句话执行之后呢，实际上这个entity并没有添加到数据库里面。

我们F12进来看具体的代码。最后一行代码，这个实体目前只是被添加到了DbContext里面。

想要保存到数据库内就要调用DbContext的SaveChangesAsync方法。我们在Repisitory里面已经封装了这个方法。

这里我们再调用一个saveAsync方法就可以了。这个Repository对象我们可以把他看做是一个黑盒，controller不需要知道里面的实现细节。
这个黑盒也可以说对于Controller来说他就是一个接口。所以我不知道他的实现细节，到底有没有包含记录日志 啊，或者是有没有处理异常 啊。
具体的实现细节对Controller来说都是未知的。
假如说controller在插入数据库的时候除了问题，抛出了异常，那么其实我也不用处理。因为抛出异常后，框架会保证返回500错误。所以这里我们就不处理异常了。

保存成功后，使用CreatedAtRoute()方法，





把dto改个名字，叫做returnDto

运行测试

最好再指定下Accept。就是返回接收的格式

注意是post请求。

加上判断，Employee不为空才去执行下面的操作。刚开始创建一个公司是没有员工。



请求的body设置。

相应的地址最后有个Location。通过这个地址我们可以获取到这个新创建的资源。



再次执行这个post请求。新生成的公司 id不一样了。说明这个资源又被创建了一个。

我们再执行以下get，获取所有的公司

测试空的body

返回的是400错误。这代表的是客户端引起的错误。

故意把name改成布尔类型的为false

发送请求，依然返回的是400 错误。这都因为我们的Controller使用了ApiController这个Attribute


 

结束