【从零开始搭建自己的.NET Core Api框架】（二）搭建项目的整体架构

本来打算将搭建项目架构和集成SqlSugar放在一起讲的，但是感觉东西有点多，还是分成两章吧~

这一章讲搭建项目的整体架构，这里先把搭建完成后的最终效果放出来，然后再逐个解释每层的作用。

 

可以看到这里一共有七层，源码在最下面，需要的可以参考源码进行对比（下面我按照自顶层向底层的顺序介绍，所以列出的顺序和图片有点区别）

（一）RayPI主项目层

我在控制器文件夹下添加了两个文件夹，Admin和Client，分别用来存放后台和前端的接口。

这么做主要有两个理由，一个是我觉得这样可以把后台和前台的功能、权限分的清楚些；第二个是，后面我们要试着让我们的框架可以自动生成一些必备的代码，以减少重复的工作量。这些代码主要就是增删改查的功能，我会将它们自动生成到admin里（毕竟对后台来说，每个实体都会涉及到增删改查，这是跑不了的）。

控制器层除了偶尔会做一些参数是否为空的验证外（有人连验证也不在控制器层做），其他不做任何操作，只是将参数传给业务逻辑层处理（下面一个讲）。

所以除了接口的注释信息、接口路径、方法和权限设置外，这一层就不应该有其他任何乱糟糟的代码了~

（二）RayPI.Bussiness业务逻辑层

 

我在业务逻辑层也就分成了Admin和Client两块，分别用来处理前后台的业务逻辑。该层只做业务逻辑的相关运算，不会对数据库进行任何直接的操作。

业务逻辑层接收到控制器层传递的参数后，将这些参数做相应的处理，然后将加工后的参数床给下一层：数据接口层。（按照比较的三层架构思想，其实应该传给数据层，但是这里利用数据接口层做了一个分隔，好处后面慢慢就会发现了）

（三）数据接口层

 

该层为数据接口层，里面只罗列了相应的接口函数，但是具体的函数功能实现则交给集成该数据接口的数据层来实现。

这样做的好处是可以将数据库操作与代码逻辑操作分离的更加清晰。不论是编写代码还是阅读代码，我们在操作业务逻辑层时只需要知道我们调用的数据接口的功能即可，但是这个功能的具体实现则暂时不需要考虑；当我们编写或阅读数据层时，只需要考虑是否实现了继承的接口的功能，而不需要再往上去看业务逻辑层。

（四）RayPI.Service数据层

 

该层负责直接或者间接对数据库数据进行操作，如果你是用原生的或者类似Dapper的数据库数据库中间件，那么在这一层就会看到相应的sql语句（当然，这里我们选择了集成SqlSugar作为数据库操作中间件）。

该层继承了相应的数据接口，所以必须实现接口内的所有函数。

图片上可以看到还继承了一个类，叫BaseDB，这个类是我自己添加的帮助类，在下面会讲的Model层里，里面只有一个函数GetClient，用来返回SqlSugarClient类（这个是SqlSugar集成的类，下一章具体讲）。

（五）RayPI.Entity实体层

该层为实体类层，存储了数据库对应的所有实体，实体一般和数据库表是一一对应的。

（六）RayPI.Model模型层

该层存放了一些系统帮助类，或是实体辅助类。

BaseDB用于返回返回SqlSugar的SqlSugarClient类，数据层可以直接继承该类。

BaseDBConfig用户存放数据的配置信息，比如书库连接字符串（这些配置信息还可以分离出来，存放到主项目的json文件中，以供读取，这个后面专门提出来一章讲）。

MessageModel是一个泛型的返回类，用于格式化的向接口返回数据。

TableModel也是一个返回类，用于格式化的向接口返回列表格式的数据。

（七）SqlSugar层

这一层并不是搭建出来的，而是从github引用的源码。SqlSugar是一个开源的ORM框架，可以实现度数据库灵活方便的操作。如果你是选择不引用源码，而是利用Nuget导包的方式向项目引入，那么项目里就没有这一层。

关于引入并配置SqlSugar下一章再讲~

 

具体的代码实现可以参考下面的源码

源码下载地址：

 

到目前为止，项目架构相比第一章已经有点模样了，但是还有很多需求没有涉及到。

比如后面我们会加入的用于存放我们自己常用静态函数的RayPI.Helper层、用于设置接口权限的RayPI.Token层、用于集成支付宝微信等第三方支付SDK的RayPI.Pay层等等。

还有比较重要的功能就是，我会尝试着让框架实现部分的自动化。比如从后台自动生成数据库表（或是在已经有表的情况下自动生成entity实体代码），按模块自动生成增删改查的基础代码，自动生成基础的页面等等。

今天先这样吧~