程序猿应当应用正确的MVC架构设计模式

with 1 comment

对于程序猿而言MVC架构设计模式一定不陌生,但在实际应用中并没有正确使用到MVC模式,没有达到MVC设计模式其解耦的作用

MVC(Model-View-Controller)

Model(模型)

简单来说:实际的后端业务逻辑都可以认为是模型

View(视图)

Controller(控制器)

java_mvc_lc.jpg

三层架构模式

很多程序猿倾向于将软件的业务逻辑放在Controller里
将数据库访问操作的代码放在Model里
最终代码结构是

这种代码结构实际上就三层架构开发模式,只是单纯的进行了分层
三层架构毕竟也是与MVC齐名的架构模式,曾经红极一时,MVC大行其道之后就销声匿迹了
用三成架构的思路写MVC,那么写出来的东西既不是三成架构也不是MVC
三层架构的核心思想是面向接口编程和各层之间的解耦和可替换性
MVC框架中没有这种概念,因为MVC要面对的问题本就不是三成架构要面对的问题
以MVC为基础写出来的三成架构是不会具备三层架构的核心要义
换言之,这种代码是放弃了三层架构和MVC的精华,获得了它们的糟粕

MVC正确方式

MVC要实现的目标是将用户界面和业务逻辑分离以使代码加强可扩展性、可复用性、可维护性、灵活性

Controller层将用户界面和业务逻辑合理的组织在一起,起粘合剂的效果
因此Controller层中的内容能少则少,这样才能提供最大的灵活性
比如:
View通常不会直接提交数据给Model,它会先把数据提交给Controller
然后Controller再将数据转发给Model
如果业务逻辑有变化,只需要在Controller中将Model换成新的Model
控制器的作用就是这么简单,用来将不同的View和不同的Model组织在一起,顺便替双方传递消息

因此我们不应该将业务逻辑写在Controller层

Model之间是可以相互调用的
Controller也可以无障碍的调用Model
将业务逻辑放在Model中可以灵活的使用组合的方式复用代码

Controller之间是不可以相互调用的
想要在Controller间复用代码只能将代码提升至父类,通过继承实现
这种做法既不正确,也不灵活

单从代码复用这一点,足以表明业务逻辑不应该放在Controller层中

Responses
  1. 还不错

    Reply