标签：
原文网址：http://segmentfault.com/a/1190000004213733
1.Controller绑定到某个路由上，接着处理请求参数，然后创建在整个请求中可见的对象，并进行一些业务逻辑上的工作。期间会从数据库中构造Model，也有可能新建/修改Model后将它们保存入数据库。最后，Controller会通过View响应用户的请求，或者返回重定向的报文。基本上业务逻辑都是实现在Controller里面的。（下文为了阐述方便，都以“业务逻辑”特指Controller中的业务逻辑）
2.每个Model往往对应数据库的一个实体。Model类除了装数据之外，还提供了跟自己身份相关的一些方法，比如User类提供authenticate方法以用于验证密码。Model对象通常还会负责检验构造自己的参数是否正确。
3.View负责使用给定的参数渲染模板，并作为响应返回给用户。View一般是由该框架提供的模板语言写成。
4.虽然后端程序也是做了MVC的拆分，但是它跟客户端的MVC其实是不同的。
在客户端里，Controller把View和Model分离开来，实现View和Model的解耦合。View上的变化，通过Controller传递给Model，然后再将Model最新的数据通过Controller传递回View。View：Controller：Model的比例通常是N：1：N，其中每个View基本对应一个Model。然而，在后端程序里面，View和Model通常没有很强的对应关系。一般意义上的CRUD，基本上是Controller（业务逻辑）围绕着Model（数据层）在转。View扮演的往往是跑龙套的角色。
5.在客户端MVC中，View扮演的是跟其他二者三足鼎立的角色。用户的输入经过View，底层数据的变更通过View反馈给用户。然而后端MVC中，View的地位摇摇欲坠、可有可无。前文提到，Controller绑定在路由上，接收请求；Controller渲染模板，发送响应。跟客户端不同的是，Controller只有在渲染模板时才用上View。View的戏份一下子被砍掉了一半。祸不单行，Controller并不一定需要渲染模板来发送响应，它可能直接就重定向了；或者更常见的是，Controller直接把一个对象JSON化，并把它响应给用户。这么一来，View的戏份还剩多少？
6.M负责数据实体还是负责数据的访问。后端程序中的Model其实做了两件事。一件事是表示了数据实体，另一件则是负责数据的访问。按照单一职责原则，Model这样一身饰两角是不对的。数据实体是一回事，对应的数据实体的访问是另一件事，两者不能混起来。
7.也许Controller本来就可以拆成两部分，一部分负责绑定路由，另一部分负责业务逻辑。
绑定路由的部分，负责解决请求数据的完整性和正确性，及限流、鉴权等操作。在它的眼里，看到的是HTTP报文。
业务逻辑的部分，负责具体业务处理。在它的眼里，看到的是用户的操作。
8.新的划分方式
View消亡了
Model分离成两层，一层负责数据实体，另一层负责数据的访问。
Controller分离成两层，一层负责绑定路由，另一层负责业务逻辑。
标签：
原文地址：http://www.cnblogs.com/hqt2050/p/5097764.html
