为什么不能在controller层里写业务处理，而是在model层？
一般来说，controller 负责路由。
如果在 controller 里写了业务，会有什么问题呢？
例如，获取 blog 的详情是一个接口，而写在了 controller 层，然后 blogList 列表会调用详情，或其他地方也用了详情，会导致多个地方调用了 blog 的controller。一看好像没问题，但是假设有一个需求，每次访问 blog 详情时，要记录浏览记录（文章id，时间），此时服务器就不能知道用户是否访问了详情了。
为什么？因为 blog 详情会访问 controller，而 blogList 获取列表时，也调用了 blog 详情的 controller ，你不能在 blog 详情 controller 里直接断定它一定访问了 blog 详情页，也就是说blog详情被调用了，但是不能确定真的就是访问blog的详情（只是在列表时、或其他地方，也用到了这个函数）。
这样一来，就很尴尬了，路由控制和业务模型混合在一块了。
访问了这个接口、或页面，它应该是和数据处理应该没有关系的，但是现在访问了资源，就一定会有复杂的数据处理代码，而且这里的代码处理无法再分离出来实现重用。
如果 controller 仅仅负责路由，并调用model层处理，至于怎么具体处理和它无关，这样一来耦合性更低了，更利于维护，比如上面的例子，我们可以在 blog 的 controller 层给予不同的参数给 model 处理浏览记录即可，而 model 怎么处理和它无关，详情、列表都可以调用该model处理数据。
文章作者: 朱丰华
文章链接: https://smart.52dixiaowo.com/blog/post-261.html
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。
发表评论
文章被阅读 18,197