为什么要谈代码层级与接口设计

在目前的工作中，代码如果按照MVC逻辑划分，那么只有MC两层。作为后端，只对其他各端提供接口，V层是不用实现。在MC的大前提下仍然和各端的工作有着不少的冲突。现行的问题存在以下几点：

1、根据前端流行的一种观念：后端提供什么数据，前端就消费什么数据。在一端的情况下，这样无可厚非，但是当面临几个端的时候，这样就相当于将各端格式化的数据工作全部叠加在后端身上。导致后端的工作可能是9倍xN端的叠加。

2、接口设计需要具备单一职责原则。但是在高并发的情况下，为了减少网络请求，需要将几个接口进行融合产生新的接口作为提供。随着这样的接口不断增多，同样会导致后端的工作也可能是9倍xN的叠加。

3、由于目前工作的问题，接口文档都是后端编写的，这样后端维护文档也占用了后端大部分的时间。曾经有人向我吐槽过，后端让各端都共用一份接口，让他的工作很难做，因为他对接口做很多逻辑操作来兼容产品提出的设计。我当时给出的观点是，为各端的不同逻辑给出不一样的接口和提供不同的接口文档。现在想想，我当时的做法也是导致后端工作繁重叠加的根源。因为维护接口文档也是一件很重要而又不想做的工作。

这几个问题的叠加，特别遇上产品经理要改需求的时候，后端的工作简直不可想象。为了解决这几个问题，还是要回归到后端的代码层级和接口设计。

代码层级的诞生

代码层级就像公司里面的部门一样产生的。如一家小公司，一个人可能身兼多职，随着公司的壮大，会因为职责划分明确而产生不同的职能部门。MVC是我们熟悉的层级，我们只是知道了大体方向，至于里面如果将代码层划分出更细化的功能，没有那些资料可以给出明确的答案，因为根据业务的不同和架构师（程序员）的“信仰”不一样，具象化的层级也会不一样的。而我现在面对的是需要灵活扩展的需求，所以我的代码层级划分上，以牺牲一定性能来获取更高的可扩展性。所以我的代码目前细致分为：模块化的纯Model层、Model组合字段层、逻辑业务层、逻辑格式化层、逻辑条件过滤层。

模块化的纯Model层

为什么要“纯”？这一层只负责从数据库中取出原生的数据，数据库中的字段名称是什么就是什么，不作任何的加工。要实现这样的要求，那么我们的设计首先就要符合模块化的设计，有把重名的字段在查询的阶段就作了冲突处理，所有在查询的时候不会因为数据库字段名相同而产生冲突。故此，这一层得到的数据可以看作是原子数据。

Model组合字段层

根据不同的业务逻辑，往往需要对原生的字段进行组合，如：A+B=C这样的形式，或者会是更加复杂的字段组合。这一层是纯Model层的额外附加，不会产生跟数据库原生字段的有命名冲突。所以查询是会从数据库中查询出原生字段，然后再根据业务逻辑的需要进行相应的组合。

逻辑业务层

这一层就是我们熟悉的Controller层。根据业务需求将Model层数据组合处理进行返回。故此，不过多阐述。

逻辑格式化层

由于模块化的纯Model层不做格式化的工作，故此诞生这一层的代码。如对时间的转换，即数据库中设计的字段是整形（int）类型，需要转换为2017-01-08。这一层的诞生，可以让model层的工作更加专注化，也让业务更加灵活。因为这一层可以根据不同端的需求和业务的不同，切换不同的格式化工具，但是一般不建议这样做。

逻辑参数过滤层

该层将接口传递的参数进行筛选过滤后，经过格式化层后，再传入Model层。其实这一层的诞生，是因为每次写代码时，获取几个参数是，都要写一次循环是很麻烦。经过对相同操作进行不断的整合而诞生的这一层。

这些层级是是我目前的代码层级。这是经过一年多对代码的不断重构后的成果。逻辑业务层通过对其他几层的不同的组合，可以满足因为业务的扩展而快速提供接口。

接口设计

在完成代码层级的设计后，便开始遇到了以上几点工作上的难题。尽管那些问题我的代码层级都可以完全实现。但是这些不得不做的繁重的工作，致使工作量的堆积，会导致我很难进行新的优化，这样会使工作困难重重。（Don’t repeat yourself！是我的代码信仰）。为了解决以上问题，构思了几点接口上设计的建议，这些建议建立在接口设计的六大原则之上。

后端提供模块化的所有字段

即模块的字典表，后端应该维护好这份字典表。因为接口的所有参数（增删查改），都必须是字典表里面的字段。即使是而我上面提出的组合字段层的字段，也会全部出现在字段表中。一旦在字典表中声明，特别是在有对应的端接上的时候，是不可以更改的。这份字典表几乎是只可以增量。

参数带上模块的标识

因为不同的模块，会有相同的字段。如：产品模块的name和客户模块的name。当特别遇到组合接口的时候，需要用product[name]和customer[name]进行区分。而后端可以利用逻辑参数过滤层后，再将参数传入Model层。从Model层出来的数据，可以经过逻辑格式化层再返回给各端。

尽量提供统一性接口

在提供接口时，尽量要考虑多端利益，不可单端返回接口，尽量做到做统一的格式化工作。各端需要自己进行格式化后端提供的数据。如：created_at: 1293971786，产品在为不同端设计时，或者在不同场景，会有不同格式如显示2011/1/2 20:36:26或者显示2011/1/2。即是，没有特定的情况下，尽量少针对性提供接口。

后端不编写针对性接口文档

每端会因为自身语言的特性，或者特定的插件，需要提供针对性的接口。同时为了加快开发速度，需要后端做一些特定的逻辑，来满足他端的需要。站在目前的角度，我不希望出现这个接口，因为出现不统一，直接导致更多的coding，自然会导致更多的错误，造成后期更难的扩展，甚至会导致项目的失败。故此，这些文档不应该由后端提供。

其实写到最后，感觉说服力有点不足。首先，因为我没有见过一些完整的规范（缺陷长存），而目前我也没有见到接口相关的规范和编写代码要如何分层。一切都靠自己的经验去摸索和验证！正如，我今天很不满意我几个月前很自豪的代码一样，但是我相信一点，程序员是一群努力走在“完美”道路上的艺术家。