MVC架构中M是指数据模型,V是指用户界面,C则是控制器;MVC的思想是模块化分离,为了代码的重用和增强代码的维护性和扩展性出发的,其中MVC的实现有一定的思想和原则,下面简单分析MVC的最佳实现:
Model
:
模型用于表示底层数据模型结构,可能会被不同的应用程序共享,一个模型应该遵循以下的原则:
- 包含属性用于描述特定的数据
- 应该包含业务逻辑,以确保数据能够满足表现的需要
- 应该包含数据操作的逻辑,如数据的增删改等
- 不应使用$_GET $POST这样的数据,是基于model的功能和重用的考虑
- 不应出现Html代码,不属于model层的范畴
View
:
View层(视图)主要用于前端的表现:
- 包含Html,以及所有负责表现的代码,可以出现php,但只是用于遍历数据
- 不应该包含Db请求,数据库的操作
- 不应该出现引用$_GET $_POST这类数组的代码,View只专注于表现
- 如果必要,可以访问Model和Controller的属性,不过仅为了满足表现的需要
Controller
:
控制器直接负责用户的请求,对Model的调用即对View表现的控制:
- 可以访问$_GET $_POST 这样的用户请求数组
- 创建模型,并决定一个模型对象的生命周期
- 不应该出现SQL语句,数据库请求应该放到Model中
- 不应该出现Html代码,应该将其放入View中
在一个良好的MVC应用程序中,控制器是轻量级的,而Model是非常复杂和庞大,包含了所有的数据模型和数据的业务逻辑方法,来满足应用的需求;控制器的逻辑有一定的套路,被框架的底层代码极大的简化,这样可以实现快速的开发;
MVC
实现的灵活性理解
MVC的三层从大体看是很独立的,而且每个模块负责的工作也和明确,控制器负责处理用户的请求,逻辑处理包括数据模型的调用以及对表现层的输出控制;模型主要负责数据关系,处理和业务逻辑操作;表现层主要负责前端页面的内容表示,可适当包含一些控制表现的逻辑;
MVC的实现必须遵循各层的原则,以保持代码的良好的结构和开发及维护的效率,然在开发过程中我们会遇到这种情况,有些逻辑方法的实现似乎放在C层或M层都合适,个人觉得这个只要遵循MVC的实现原则和代码的规范前提下,可适当的处理,通常放在M层概率大些;
转载于:https://blog.51cto.com/golang/810781