设为首页 加入收藏

TOP

中小型研发团队架构实践二:如何规范公司所有应用分层(一)
2019-09-17 19:05:31 】 浏览:63
Tags:中小型 研发 团队 架构 实践 如何 规范 公司 所有 应用 分层

一、写在前面

     应用分层这件事情看起来很简单,但每个程序员都有自己的一套,哪怕是初学者。如何让一家公司的几百个应用采用统一的分层结构,并得到大部分程序员的认同呢?这可不是件简单的事情,接下来以我们真实案例与大家一起探讨,先问大家两个技术问题:

     服务的调用代码你觉得放到哪一层好呢?

  • A 表现层
  • B 业务逻辑层
  • C 数据层
  • D 公共层

     如何组织好 VO(View Object 视图对象)、BO(Business Object 业务对象)、DO(Data Object 数据对象)、DTO(Data Transfer Object 数据传输对象) 呢?

     不同的人会有不同的答案,所以要统一公司应用分层,以减少开发维护学习成本。统一应用分层要可大可小、简单易用、支持多种场景,我们采用 IPO 方式:I 是 Input、O 是 Output、P 是 Process,一进一出一处理。应用系统的本质是机器,是处理设备,一进一出一处理。

                                                                      IPO 原理图

二、统一逻辑架构

                                                       统一应用分层的逻辑架构图

职责说明:

  • 文件夹分层法:应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范,可以包括 5 个项目,也可以包括 50 个项目,以满足所有业务应用的多种不同场景;
  • 调用规约:在开发过程中,需要遵循分层架构的约束,禁止跨层次的调用;
  • 下层为上层服务:以用户为中心,以目标为导向。上层(业务逻辑层)需要什么,下层(数据访问层)提供什么,而不是下层(数据访问层)有什么,就向上层(业务逻辑层)提供什么;
  • 实体层规约:DO 是数据表对象,不是数据访问层对象,不是只能给数据访问层使用;DTO 是网络传输对象,不是表现层对象,不是只能给表现层使用;BO 是内存计算逻辑对象,不是业务逻辑层对象,不是只能给业务逻辑层使用 。如果仅限定在本层访问,则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类,可以减少无价值重复对象和无用转换;
  • U 型访问:下行时表现层是 Input,业务逻辑层是 Process,数据访问层是 Output。上行时数据访问层是 Input,业务逻辑层是 Process,  表现层就 Output。

三、我们的具体规范

     此规范我们用了四年,牵涉几百个应用,200 多个研发人员,是一个成功的实践。接下来就借用本文提供下载的 TripOrderService、TripSellerMVCSite 这两个 Demo 来进行具体规范的说明,以下是截图:

3.1、项目命名规则

     项目命名规则:{产品线英文名全称}.{子系统英文名全称 + 应用名}.{项目职责英文名全称},如:Trip.Seller.DTO。

3.2、业务逻辑层的项目规范

规范说明:

  • 1、项目名的命名规则:{产品线英文名全称}.{子系统英文名全称 + 应用名}.xxxBusiness,如上图的 Trip.Order.Business。
  • 2、类名以 Logic 结尾,如上图的 OrderLogic.cs。

3.3、数据操作项目规范

规范说明:

  • 1、各数据操作项目名根据使用什么数据库进行分类,然后以 DB 为结尾,具体命名规则是:{产品线英文名全称}.{子系统英文名全称 + 应用名}.{使用什么数据库}DB,如上图的 Trip.Seller.MSSQLDB。
  • 2、如果涉及到多个数据库访问的,那么数据操作项目下的类文件需要按数据库名称(以 DB 为结尾)创建文件夹分开,如上图的 TripOrderDB 文件夹。
  • 3、建议在应用中使用 SQL 语句,不使用存储过程。在数据库中不新增存储过程,但旧的存储过程可以继续使用和修改。
  • 4、分页建议使用数据库(如 SQLServer)的最新特性进行分页,并将每个分页 SQL 直接写到应用中。

3.4、实体类项目规范

数据传输对象 DTO 规范

规范说明:

  • 1、DTO 项目命名规则:{产品线英文名全称}.{子系统英文名全称 + 应用名}.DTO,如上图的 Trip.Order.DTO。
  • 2、请求参数 DTO 实体类、响应 DTO 实体类存放规范以及其命名规则:
    • a、请求参数 DTO 实体类放在 Request 文件夹下,且命名规则为:以 Request 结尾,如上图的 SearchOrderRequest.cs。
    • b、响应 DTO 实体类放在 Response 文件夹下,且命名规则为:以 Response 结尾,如上图的 SearchOrderResponse.cs。
    • c、如果请求参数 DTO 实体类或响应 DTO 实体类的属性中有对象或枚举,那么这些对象所属的类、枚举放在 DTO 项目的 Common 文件夹下。
  • 3、如果请求参数 DTO 实体类、响应 DTO 实体类有基类要继承,那么建议为基类取名为 RequestBase.cs、ResponseBase.cs。且这些基类直接放在 DTO 项目的 Common 文件夹下。

视图对象 VO 规范

规范说明:

  • 1、VO 项目命名规则:{产品线英文名全称}.{子系统英文名全称 + 应用名}.ViewModel,如上图的 Trip.Seller.ViewModel。
  • 2、各 VO 实体类,我们用 Controller 名作为文件夹名进行分开,如上图的 Order 文件夹。
  • 3、VO 实体类名的命名建议:
    • a、请求参数 VO 实体类以 Input/Form/Query 结尾,如上图的 SearchOrderInput.cs。
    • b、响应 VO 实体类以 Output/List/Result 结尾,如上图的 SearchOrderOutput.cs。

业务对象 BO 规范(可选)

BO 实体类名以 Model 为结尾:

规范

首页 上一页 1 2 下一页 尾页 1/2/2
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇Windows平台网站图片服务器架构的.. 下一篇solr7.2安装实例,中文分词器

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目