前后端分离

• 为什么要分离？

前后端分离

• 为什么要分离？
• 罗贯中说：天下大势，合久必分，分久必合

前后端分离

• 为什么要分离？
• 罗贯中说：天下大势，合久必分，分久必合
• 设计原则：SoC —— Seperation of Concerns

前后端分离

• 为什么要分离？
• 罗贯中说：天下大势，合久必分，分久必合
• 设计原则：SoC —— Seperation of Concerns
• 其实：分是为了更好的合

现状

• 应用工程师要改一些展现内容，花了很长时间才找到修改的地方
• 前端工程师要改进一些结构和样式，不敢动手，因为View的可测试性不足
• 重复或相似的代码相当多，特别是表现层，由于缺乏称手的工具而难以重构
• 稍复杂的需求变化，应用工程师荡漾在一堆标签和php逻辑交织的代码里
• 由于一些小的非本质性的变动，要改变许多原有的代码

这些问题背后的原因？

• 表现层代码散布各处 —— /lib下的类和方法输出html甚至style
• Controller大包大揽 —— routing、页面布局、组装、应用逻辑……
• View同时承担两个职责 —— 页面单元和复用单元，导致view变得太零碎
• 前端代码缺乏抽象层 —— 虽有抽象层尝试，但是不够好，很容易产生“抽象泄露”

已经尝试过的方法

• include
• view组装
• page layout（Decorator/Wrapper模式）
• Pueur + BootStrap based plugins
• HTML类

尚未尝试过的可能方案

• Partial
• View Helper
• Template
• Builder

新技术

• Haml / Jade
• Coffeecup / HTMLBuilder(Ruby/Groovy)
• Client-side MVC Framework (Backbone ...)
• Full-stack Framework (Meteor, Derby ...)

我们传统的协作方式

• PM
• App Dev
• Others

许多大公司的协作方式

• PM
• 交互设计师
• 视觉设计师
• 前端工程师
• 架构师
• 后端工程师
• Others

我认为理想的协作方式

• PM
• 设计师
• 后端App Dev
• 前端App Dev
• 前端Infrastructure
• 后端Infrastructure

路线图

• 使用Partial等方式逐步改进现有代码，将view model理出来（准备阶段）
• 基于Jedi重构表现层（改造阶段）
• 并行的改进（改善阶段）
• 引入Full-stack Framework，支持UI Binding、No-refresh Update、Bigpipe……（未来的方向）

FAQ

• 请拍砖！