百度云网站建设视频,高端大气网站模板,合肥建公司网站,团购网站app制作分层思想#xff0c;是应用系统最常见的一种架构模式#xff0c;我们会将系统横向切割#xff0c;根据业务职责划分。MVC 三层架构就是非常典型架构模式#xff0c;划分的目的是规划软件系统的逻辑结构便于开发维护。MVC#xff1a;英文即 Model-View-Controller#xff…分层思想是应用系统最常见的一种架构模式我们会将系统横向切割根据业务职责划分。MVC 三层架构就是非常典型架构模式划分的目的是规划软件系统的逻辑结构便于开发维护。MVC英文即 Model-View-Controller分成模型层、视图层、控制层。将页面和业务逻辑分离提高应用的可扩展性及可维护性。如图所示。 事实上MVC 三层架构只是概念层面的指导思想我们会将层次结构划分的更加细致。例如传统后端的 MVC 模式对于前后端的划分界限比较模糊。一般情况下前端开发人员负责编写项目的静态页面包括 HTML 页面、CSS 样式与 JavaScript 交互部分并提供给服务端开发人员编写视图层业务甚至有的项目直接让前端开发人员完成视图层的业务开发任务。这样的开发模式造成的问题在于前后端在开发过程中分工不明确并且存在相互强依赖前端开发人员需要关心服务端的业务服务端开发人员也需要依赖前端的进度。并且随着 Android、 IOS、 PC 以及 U3D 等多个客户端加入程序的开发成本与维护成本会指数级上升。为了提高开发效率细化职责前后端分离的需求越来越被重视。前后端分离在于服务端提供 API 接口前端调用 AJAX 实现数据交互。如图所示。
此外随着数据存储能力的不断扩展MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等以及随着微服务的流行与普及我们经常通过 RPCDubbo、HSF、Thrift 等依赖很多外部接口或 HTTP 调用第三方平台。因此我们需要一套细致划分的代码结构。此外很多时候我们在开发过程中也并没有把它们职责划分开。例如在代码结构中我们将非常多的逻辑业务放在了 Controller 层而只把 Service 作为数据透传的途径了。事实上这个是不对的。无独有偶我们还会发现有的项目中在 Dao 层调用远程服务也有的会在 Service 层或者 Controller 层进行这样的操作由于不同研发同学的习惯不同或者偷工取巧导致开发代码风格完全不同代码层次结构混乱。
总结一下MVC 三层架构只是概念层面的指导思想我们会将层次结构划分的更加细致。现在我们来深入探讨“如何合理的设计代码分层论代码分层的设计之道”。在笔者看来合理的代码分层应该是这样的。如图所示。
其中数据持久层 承载了数据存储和访问的能力它既与底层数据进行交换包括 MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等又通过 Pxoxy 的代理和包装与远程服务数据进行联动。因此在业务逻辑层调用时它对底层的数据实现方式是无感知的无论是哪种数据存储方式以及它是远程数据还是本地数据都可以非常容易的调用。换句话说我们需要将数据的查询和更改操作限制在数据持久层并只能被业务逻辑层访问。
那么业务逻辑层 的职责是与数据持久层交互对多个数据源的操作进行聚合并且提供组合复用的能力。此外它也是业务通用能力的处理层其中还包括缓存方案、消息监听MQ、定时任务等等。此外我们要将尽可能多的业务处理放在业务逻辑层包括了参数校验、数据转换、异常处理等而不是在 Controller 再去处理。
笔者认为请求处理层具有三块能力一个是通过模板引擎渲染例如 FreeMarket、Velocity 的页面渲染以及通过 Controller 层封装的 RESTful API 的 HTTP 接口。如果项目中用到了 Dubbo、HSF、Thrift 等 RPC 服务我们还需要提供对于的服务给上游的业务方使用它通过 Service 来实现并暴露成 RPC 接口。这里Service 的命名是相对的一般通过 Client 提供接口通过 Service 实现具体的业务逻辑。
我们了解了逻辑结构那么笔者认为比较清晰的物理代码结构应该是这样的。
那么我们可以跨层级调用吗笔者认为我们需要禁止跨层级调用因为每个层级都自己的职责并且对上层而言是透明的就像 OSI 七层协议模型和 TCP/IP 四层协议模型一样只有将职责限制在自己的边界内整体层次结构才清晰明了。那么对于同级调用笔者认为在业务逻辑层是允许的但是要特别注意循环调用的产生。
现在我们再横向理解几个领域模型VO、BO、DO、DTO。这个概念是由阿里编码规约提到的由于其业务非常复杂因此为了更好地进行领域建模和模型隔离提出了这几个概念。其中DOData Object与数据库表结构一一对应通过 DAO 层向上传输数据源对象。 而 DTOData Transfer Object是远程调用对象它是 RPC 服务提供的领域模型。注意的是对于 DTO 一定要保证其序列化实现 Serializable 接口并显示提供 serialVersionUID否则在反序列化时如果 serialVersionUID 被修改那么反序列化会失败。事实上DO 和 DTO 唯一的区别在于一个是本地数据源的领域模型一个是远程服务的序列化领域模型。对于 BOBusiness Object它是业务逻辑层封装业务逻辑的对象一般情况下它是聚合了多个数据源的复合对象。那么VOView Object 通常是请求处理层传输的对象它通过 Spring 框架的转换后往往是一个 JSON 对象。例如你需要解决 Long 类型的数据精度丢失的问题如果直接传给 Web 端的话在 Long 长度大于 17 位时会出现精度丢失你就可以在 Controller 层通过 ResponseBody 将返回数据自动转换成 JSON 时统一封装成字符串。
总结一下分层思想将系统横向切割根据业务职责划分。划分的目的是规划软件系统的逻辑结构便于开发维护。但是随着微服务的演变和不同研发的编码习惯往往导致了代码分层不彻底导致引入了“坏味道”。
