分层架构设计

1、前言

都说”不想作架构师的开发不是好前端“，”一千个读者心中有一千个哈姆雷特“。我相信每一个开发者心中，都有一个属于本身的框架，因此今天我就给你们探讨一下我心中的简单分层架构设计。

在说分层架构设计以前，先说下我对架构设计的理解，不足之处还但愿大神指点。《.NET应用架构设计》这本书里面写到：架构设计其实为“架构”和”设计”的两个概念，架构是对业务需求的高层抽象，而设计是将高层抽象的需求与具体的技术实现联系起来，在此过程当中，会根据实际状况考虑到系统的稳定性、安全性、扩展性兼容性等各类因素。因此在项目业务需求提出以后，通过架构分析，获得系统的机构方案，而后根据架构方案作不一样的设计方案，选择适合的设计方案进行开发。架构设计和代码重构同样，他不是一蹴而就的，他也是在迭代中变得完善和稳定。

说到这里，我想说一下框架和模式，日常中或多或少都会看到xx框架、xx模式，架构设计主要体如今设计上面，他们输出多是文档或者伪代码等，而框架就是对架构设计的累计实现。好比工做中的项目框架，都是在咱们通过屡次设计、重构事后，获得公共模块（也就是咱们说的轮子），在这个基础上，开发就会很便利。模式这是根据开发经验，提出某些问题比较好的解决方案。好比说单例模式、工厂模式等。

固然架构设计确定没有说得这么简单，他还有不少设计原则和理论，感兴趣的朋友能够本身去了解一下。

下面就是蜗牛根据本身的理解，结合到一个例子对多层架构设计和实现，若是有不合理的地方，但愿你们都多指点。

2、分层架构设计实现

一说到分层（这里咱们说的是逻辑分层），相信不少人都会想到经典的三层架构。其实分层的目的是把功能按照不一样的角色分隔开，便于后期系统扩展、维护，因此三层只是一个最少的层次划分，具体的层次须要根据项目实际的业务状况以及系统的部署状况进行划分。下面我就以一个项目进行说明。

如今须要实现一个论坛的项目，并发量等非业务因素如今都不作考虑，因为经费缘由，只能提供一台服务器做为部署环境，能够支持PC端和手机端访问。

我相信不少园友在作项目的时候，都遇到过这个状况，客户只知道他想要这个东西，可是其余的，他一律没考虑。因为这个是例子，就直接按照上面的需求作了，细节方面就后面再修改。

2.一、分层约束

2.二、分层描述

界面层：用户界面或表现层，即MCV中的view层；

界面控制层和API接口层：界面控制层即MCV中的Control层（使用.net的mvc），API接口层主要以Webapi提供接口，主要用于实现轻业务、参数校验、异常封装以及权限验证；

业务逻辑层（Service层）：实现业务处理逻辑；

业务Manager层：可复用逻辑层，完成：1. 对第三方平台封装的层，预处理返回结果及转化异常信息；2. 对Service层通用能力的下沉，如cache,mq等通用处理；

数据持久层（Dao层）：数据库访问层。

Common层：里面主要包含业务方法库和公共方法库，业务方法库：主要是协助业务逻辑层处理逻辑，即含业务的公共方法，只被业务逻辑层调用；公共方法库：包含公共方法，能够被全部层调用。公共方法库还有一个原则，就是他不依赖Model，他对于任何层次均可以单独调用，之后做为框架的一个公共库模块。这也就是为何还会存在一个业务方法库。

分层说明：由于界面层使用的MVC，因此对应的就有界面控制层，若是先后端分离，就只须要API接口层便可。

2.三、分层模型描述

Entity：主要是对数据库表结构一一对应；

DTO：数据传输类型总称，这里将他做为一个象征名词，具体分为：Request（请求对象），Response（响应对象）和DTO（数据传输对象）。

模型运用场景：

界面层发送Request参数请求，界面控制层将请求分发到对应的Service层，Service层根据业务拆分红不一样的DTO参数请求或者不作拆分，再发送到Dao层，Dao层访问数据库。若是是数据库表查询，返回Entity对象，若是是多表业务查询，返回DTO对象，Service层通过业务处理返回Response对象到界面控制层，界面层直接返回Response对象。因为项目较小，返回过程当中的Entity对象和DTO对象也能够直接返回。

2.四、实现技术

前端技术：html5,css3,javascript,jquery,layui以及它的fly论坛界面;

后端技术：采用.net MVC、WabAPI以及.net Framework为目标框架；类库采用standard做为目标框架；ORM使用Dapper；依赖注入采用Unity；日志框架使用Log4Net;

技术选型说明：界面层和界面控制层选用的是.net Framework为目标框架的.net MVC，而.net Core是之后的大势，因此剩下的类库都选用standard做为目标框架，后面若是使用.Net Core进行跨平台，直接替换界面层和界面控制层便可。在研发过程当中还会添加其余的技术，因此架构设计也要不断的迭代。

2.五、编码规范

这里的规范只对架构方面的规范，至于代码书写的规范（命名，注释等）就不作描述了。

一、命名规范

业务逻辑层（Service层）全部文件必须以Service结尾；

业务Manager层全部文件必须以Manage结尾；

数据持久层（Dao层）全部文件必须以Repository结尾；

Entity对象全部文件必须以Entity结尾；

界面层发送的请求必须以Request结尾；

返回给界面层的数据必须以Response结尾；

其他的传输的数据对象必须以DTO结尾。

二、依赖注入

业务逻辑层（Service层），业务Manager层，数据持久层（Dao层）必须有对应的接口层，采用依赖注入的方式实例化对象。

三、方法库

业务方法库和公共方法库都必须是静态方法，而且业务方法库只能被业务逻辑层（Service层）调用。

四、参数规范

全部的方法，请求和返回对象都必须一一对应。（主要是防止一个对象多用，致使后期混乱不堪）

五、文档归类

同一功能或者同一类型方法或者对象，须要用文件夹同一依赖。

备注：开发过程当中还有其余的约定规范，后面不断的迭代。

2.五、分层架构实现

先建立一个命名为“PFTSnailSystem”的空白解决方案，而后根据分层约束，咱们将他们概括为：CommonLayer、ModelLayer、BusinessLayer、DataLayer和PresentationLayer。为了给他们指定顺序，因此在他们前边加上编号。

如图：

如今咱们就将各层分别建立到指定的文件中。如图：，

注意：建立类库必定选择standard框架。

其中，PFT.Snail.Core为业务方法库，PFT.Snail.Utility为公共方法库。其余的项目跟前面分层描述一一对应，而且都有单独的对应的接口类库。

3、总结

到目前为止，咱们整理好了架构，架构方案的样子也在项目中有个轮廓了，虽然也存在着设计，但设计还没作完。其实对于设计是否完成，也是仁者见仁智者见智，设计能够详细到具体的UML类图。前面，咱们虽然对每层作了规范限制，也说明了项目的使用的相关技术，可是都说得很抽象。由于设计的结果，就是项目的“规格说明”，而咱们如今的都没有设计到项目需求，这个架构也能够适用到其余项目。因此后面咱们将针对不一样的功能模块，先作设计方案，而后编写实现设计方案，同时将逐步实现架构里面的基础功能。