关于MVC架构的深入思考-发现自己错误
2017-03-05 21:34
260 查看
最近课比较少,读了基本PHP大作,也在github上阅读了几个优秀作品的源码,发现了自己在以往的代码结构中的可笑之处。
php,做的最多的应该就是网站,其中进来通用的架构就是mvc架构,将视图、模型、控制器分开,以方便不同角色开发人员工作,前端和后端可以彻底分开。其中,将v分隔开,是非常容易理解的,只要数据和逻辑完全不出现在视图部分就可以了。但是MV这两部分如何区分,在初学这种架构时是一个大难题,最开始,新手经常做的就是,忽略模型层,将这种架构完全当作前后端分离架构使用,在控制器里完成所有的数据和业务逻辑操作,没错,我以前经常这么干。
模型层的定义—-业务模型,不光是要处理数据,而且业务逻辑也应该放在这里,何况业务主要就是用来处理数据。模型层用来进行业务流程/状态的处理以及业务规则的制定,业务流程的处理过程对于其他层来说是黑箱操作,模型接受视图请求的数据,返回处理结果。
业务模型的设计,是这种设计模式的核心部分,如何将一个应用的模型按照一定规则提取出来,需要很强的分析和建模能力,抽象和具体实现之间不能太远也不能太近。模型抽取的好坏,直接决定模型的重构和重用性。一个模型可以对应很多视图,一个视图也可以对应多个模型。
至于控制器,它只作为一个模型和视图匹配的的分发器,它在层次上距离视图比较近一点。控制器完全不做任何数据处理。这样,就解决了我很久的困惑,真正掌握了mvc模式。
其中重中之重的是模型的抽象能力,这个还是要多看优秀源码,积累经验。
php,做的最多的应该就是网站,其中进来通用的架构就是mvc架构,将视图、模型、控制器分开,以方便不同角色开发人员工作,前端和后端可以彻底分开。其中,将v分隔开,是非常容易理解的,只要数据和逻辑完全不出现在视图部分就可以了。但是MV这两部分如何区分,在初学这种架构时是一个大难题,最开始,新手经常做的就是,忽略模型层,将这种架构完全当作前后端分离架构使用,在控制器里完成所有的数据和业务逻辑操作,没错,我以前经常这么干。
模型层的定义—-业务模型,不光是要处理数据,而且业务逻辑也应该放在这里,何况业务主要就是用来处理数据。模型层用来进行业务流程/状态的处理以及业务规则的制定,业务流程的处理过程对于其他层来说是黑箱操作,模型接受视图请求的数据,返回处理结果。
业务模型的设计,是这种设计模式的核心部分,如何将一个应用的模型按照一定规则提取出来,需要很强的分析和建模能力,抽象和具体实现之间不能太远也不能太近。模型抽取的好坏,直接决定模型的重构和重用性。一个模型可以对应很多视图,一个视图也可以对应多个模型。
至于控制器,它只作为一个模型和视图匹配的的分发器,它在层次上距离视图比较近一点。控制器完全不做任何数据处理。这样,就解决了我很久的困惑,真正掌握了mvc模式。
其中重中之重的是模型的抽象能力,这个还是要多看优秀源码,积累经验。
相关文章推荐
- 关于构建自己的知识体系架构的一点个人思考(转载)
- 关于MVC架构中错误处理的问题
- (转)看了一些ASP.NET MVC开源项目后的一些想法,关于ASP.NET MVC+Repository+Service架构的一些思考
- 『飞秋』关于ASP.NET MVC+Repository+Service架构的一些思考
- 关于三种主流WEB架构的思考
- 关于三种主流WEB架构的思考
- 关于两个MVC示例的思考(MVCStore和Oxite)
- 关于ValidationSummary,也就是mvc的客户端错误验证的理解
- 关于项目启动报ibatis.BindingExcetion错误的一点思考(持续更新中)
- springMvc+Mybatis关于 Invalid bound statement (not found):的错误
- 自己对Z-stack的架构一些理解(仅作学习笔记,有错误希望大家能指出来,初学Z-Stack菜鸟一只)
- 在经营景城网过程中,发现了很多自身存在的问题,五十四句关于人性的些许总结,惊醒自己,也警示别人。
- 关于三种主流WEB架构的思考
- Spring技术内幕——深入解析Spring架构与设计原理(四)Web MVC的实现
- Java入门:关于Java栈与堆的深入思考
- 关于Gson-2.4(自己犯得错误)
- 关于错误 libstdc++.so.6:cannot open shared object file 和 libstdc++.so.6: wrong ELF class 的解决和思考
- 关于c/c++中的类型重定义错误的自己的理解
- 从“关于Java堆与栈的思考”一帖看错误信息的传播
- 基于MVC三层架构结合自己理念生成的四层架构