web开发之代码组织探讨

web后端开发的同学对MVC模型应该都不陌生，但随着项目复杂度的增加，MVC模型的不合理使用会让项目逐渐失控。接下来我们来探讨一下如何把项目的复杂度维持在可控范围。

首先，MVC模型本身没什么问题，它所提供的只是一种思路而已。通常情况下我们会把ORM的代码写到Model里面，处理HTTP请求的逻辑写到Controller里面，而返回的数据如HTML/JOSN逻辑则会写到View里面。看起来没啥问题，那么我们的代码是怎么一步步变得臃肿混乱的呢？

起初，业务还很单纯，一个HTTP请求打过来，通过路由找到对应的 Controller 方法，顺带解析出了请求参数，接着把参数直接交给Model进行CURD，然后从Model构建View所需要的参数，最后把View的输出作为Controller的响应数据。后来，业务没那么单纯了，Controller拿到数据后，不只要进行简单验证，还要去数据库查数据，检查，然后再决定是不是要进行下一步处理，慢慢地Controller里面开始堆积大量数据库操作即Model层的调用代码，与此同时，View层开始有更多的展示需求，往往一个页面需要好几个Model的数据，而且彼此间往往存在逻辑关系，渐渐地View里面也有了很多直接对Model的操作代码。同样的，在Model层，一个业务的流程通常是要涉及到多个表单的处理，所以往往有些Model有很多其他Model的操作代码和数据格式转换方法。而且随着项目的演进，这种情况会越来越严重。边界不清晰导致了代码组织的换乱。

在面相对象的编码模式中，重要的是模块与模块之间的沟通而不是类本身。

对于Model层的理解偏差导致我们忽略了定义边界：

1. Controller 作为HTTP的直接服务者，它的任务就是解析HTTP参数，调用合适业务逻辑服务，根据该服务的响应，选择合适View服务以构建HTTP响应数据。Controller的边界是对HTTP协议而言，所以其 ControllerModel 应该按照HTTP标准制定。

2. Model 层应该改名叫数据存储层，与数据库交互的层应该叫做 StoreModel，他所要关心的只是如何与数据库进行交互。在此之上应该有更高层次的业务层，以业务线为单位的数据库操作组合。业务对外的边界要形成自己的一套标准，即将请求参数和返回信息的规范化，尤其要注意的是定义好业务层的错误与异常的分类，以便服务使用者做相应的处理。

3. View 层也是同样的道理，需要一个ViewModel层来处理请求参数并构建模板文件需要的结构体，模板文件只是View层的最后环节，不应该直接与Model层进行交互。

以上。