前后端分离的一些理解

前后端分离

前后端分离，本质是关注点的分离。软件越来越复杂，需要有人来专注于表现和交互，有人专注于领域逻辑。于是前后端分离出现了。前端关注交互体验，这些看得到摸的着的部分。后端关注于表达正确的业务。有争议的地方就在于controller这一层应该放到前端还是后端。并且随着前后端分离，前后端的协作问题就暴露出来。

Controller在前

这样的项目可以从职能上分为两个部分。

• 服务
  提供各种服务，比如领域服务，消息服务，权限服务等。是一个可以独立的对内对外的纯服务，更加重领域建模，重设计。
• 产品
  组合服务，提供视图，控制产品的整个生命周期。是一个独立的客户端，通过消费后端服务，提供服务，更重产品。
• 协作
  • 独立性：各自可以独立开发，独立部署。
  • 依赖：前端需要依赖后端暴漏的服务接口（领域，资源接口，具有一定的通用性，接近数据库）。后端在完成设计的时候，提供服务并且返回mock的数据。在后端调整服务URL，请求方式，请求参数，返回数据时需要通知前端变更。
  • 环境：需要一个拥有完整服务的测试环境，前端开发需要调用各种服务，因此需要各个服务都在运行状态。
• 打个比方
  这种开发方式，后端就像支付宝公司，前端就像我们的服务。我们按照支付宝的接口约定，调用支付宝的支付服务。
  
  

  Controller在后

  这样的项目一般从文件上进行分拆

• 静态页面部分
  前端写js，css，模板；
• 非静态页面部分
  后端写服务;组合服务，提供视图，控制产品的整个生命周期。
• 协作
  • 独立性：各自独立开发，部署在一起。
  • 依赖：后端需要配置前端maven依赖(通过maven方式分发前端项目)。前端依赖后端容器（servlet，velocity Context等）提供的数据来填充模板，需要后端提供的业务接口。后端调整服务URL，请求方式，请求参数，返回数据时需要通知前端变更。
  • 环境：需要一个拥有完整服务的测试环境，后端需要调用各种服务，因此需要各个服务都在运行状态。
• 打个比方：
  这种开发方式，类似后端好比包工头，前端好比搬砖头。前端技术会受限于后端，而后端也会因为需要考虑前端而分散精力，并没有达到关注点分离的效果。
  

tips:服务接口和业务接口只是为了区分做的事情不同而已。可以简单的理解为离数据库的远和近。离数据库越近，粒度越粗，通用性越好，离数据库越远，越靠近变现层，会更具体，粒度更细，通用性越差。这里服务接口是更靠近数据库。考虑如下的过程：

db(net ram file mq)  ->  po(持久化) -> do(领域建模) -> bo(业务模型) -> dto(传输对象)

实现和选择

和公司的情况有关系，如果公司没有专业前端，那么选择controller前置的策略。进行项目的拆分，分出服务和应用。技术实现上前端可以选择基于spring mvc（ruby python或其他）的全栈或者基于NodeJS的新的全栈方式。
如果公司有专业前端。那么初期选择controller后置的方式，会是一个自然的选择。以后的进化可以选择NodeJs的全栈开发方式。实现服务和应用的分离。

未来遐想

对于后端人员的JS之路，需要了解浏览器排版规则，浏览器诡异bug，以及各种黑暗魔法，其挑战不可谓不大。而对于前端开发人员的NodeJs之路，需要学习应用开发中的复杂性和各种坑点。这和单单做页面完全是不一样的东西，其挑战性甚至比后端人员学习JS更大。
然而技术归技术，好的交互并非只有技术就够了。预想会有三个只能规划：

• 交互
• 应用
• 服务