认识达内从这里开始

我们在进行app软件开发和服务器开发的过程中，为了能够有条理的梳理我们的服务流程，一般情况下，程序员会将软件进行分层处理，下面我们就一起来了解一下具体情况吧。

一、写在前面

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

服务的调用代码你觉得放到哪一层好呢?A表现层;B业务逻辑层;C数据层;D公共层。

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

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

二、统一逻辑架构

文件夹分层法：应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范，可以包括5个项目，也可以包括50个项目，以满足所有业务应用的多种不同场景;

调用规约：在开发过程中，需要遵循分层架构的约束，禁止跨层次的调用;

下层为上层服务：以用户为中心，以目标为导向。上层(业务逻辑层)需要什么，下层(数据访问层)提供什么，而不是下层(数据访问层)有什么，就向上层(业务逻辑层)提供什么;

实体层规约：DO是数据表对象，不是数据访问层对象，不是只能给数据访问层使用;DTO是网络传输对象，不是表现层对象，不是只能给表现层使用;BO是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用 。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换;

U型访问：下行时表现层是Input，业务逻辑层是Process，数据访问层是Output。上行时数据访问层是Input，业务逻辑层是Process, 表现层就Output。

写在最后

三、问题回答

问：服务的调用代码应该放到哪一层呢?

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

答：我们的规范是统一放到数据资源访问层即C。上层提供服务，下层调用服务，中间处理业务逻辑。

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

答：通常有两种做法，限定访问范围和不限定访问范围，实际项目中可根据需要选择、折中或裁剪。我们使用后者，将EntityLayer作为通用对象放到左侧，具体可参考实体层规约：“DO是数据表对象，不是数据访问层对象，不是只能给数据访问层使用;DTO是网络传输对象，不是表现层对象，不是只能给表现层使用;BO是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用 。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换。”

问：应用分层范例代码的编写需要注意些什么?

答：应用分层范例的代码要想写好，非常不容易，很容易引起争议，很难让所有人满意。我们在具体实践时遵循以下几点：

应用分层范例的主要价值是明确层的职责和交互，每个层的职责是什么，哪些要干，哪些不要干，以及层与层之间依赖和交互;

私人定制：减少通用帮助类的编写，如果每一个应用中有大量相同的帮助类，这在架构层面上是有问题。在我们的几百个线上应用中，尽管减少通用的代码，包括分页帮助类、数据库帮助类、缓存帮助类、MQ帮助类、日志帮助类、AOP帮助类、线程帮助类。业务应用的重点是为业务服务，每一个应用都是特别的，都需要私人定制，极少有通用的代码，如果有，那么应该由框架或组件专门解决;

少即是多：应用的场景多，参考人员多，每个人想法不同，牵涉的时间长，所以尽量只做大家都认同的规范、正确的事情，要自底向上、要减少有争议的代码范例，否则一个错误将会放大百倍、一个有争议的规范将会很难推行。

追求简单：代码编写可分为三个层次，简单、复杂、简单。第一简单是不知道的简单，第二个复杂是知道后的复杂，第三个简单是知道后有取舍的简单。范例代码要追求简单，既可轻松扩展支持复杂场景，又要简单到初级程序员也能操作。

内聚大于解耦：内聚是什么，内聚是部门内有共同的目标，然后大家紧密合作。解耦是什么，解耦是部门间各自职责明确，然后减少不必要的连接。一个应用如同一个部门，应有一个共同的目标和职责，然后大家紧密合作。换句话说，应用内部应减少不必要契约接口(如同公司间才签约合同)，减少不必要的依赖注入实现，减少不必要且代价过大的解耦。一切以简单实用为主，以应用价值输出、应用的目标(接口或界面)为导向。

作者：arch-system

来源：博客园

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。