mvc与三层结构终极区别,更是一门艺术

2019-11-26 16:35 来源:未知

1、前言

作为一个多年从事b/s开发的程序猿,曾先后使用过asp、asp.net做为主要服务端语言。不管是相对低级的asp也好,还是高级的asp.net也罢,都100%会遇到"数据绑定"问题。

 

2、什么是“绑定”?

广义来讲,如果服务端的数据需要在页面上呈现,并且这份数据需要与整个页面(或页面的某个部分)建立关联(不管是单向关联还是双向关联),这就是数据绑定。

注:本文章内所有内容都来自互联网,本人主要是起了一个收集的作用

3、“赋值”是个好办法

在asp年代,压根儿就没有控件这一说,所以服务端的数据呈现,基本上就是通过在页面中内嵌<%=xxx%>来实现的(xxx可理解为一个定义的变量),要改变显示的内容,最方便的方法就是给变量xxx赋不同的值。

到了asp.net年代,大量丰富的web form控件,让开发变得更轻松,cs代码也以CodeBehind的形式与页面分离开来。如果要让一个GridView或Repeater呈现出后台数据,只要简单的写上 gridView1.DataSource=xxx; gridView1.DataBind();  就行了。以此类推,要让一个TextBox控件在页面上有内容,也只要简单的写一句textBox1.Text = "Hello World"即可.

又看到有人在问三层架构和MVC的关系,感觉这种问题有点教条化了。因为它们都在逻辑上将应用程序划为三块,凑了一个数字3,就有人非要把它们联系到一起了。

4、有了“赋值”,我们就该满足了吗?

  这两个东西我接触有几年了,有一点体会,表达一下:

又看到有人在问三层架构和MVC的关系,感觉这种问题有点教条化了。因为它们都在逻辑上将应用程序划为三块,凑了一个数字3,就有人非要把它们联系到一起了。

4.1、界面与逻辑的纠缠

“赋值”几乎是解决数据绑定的万能之道,理解起来也很容易,但是人总是喜新厌旧的。相信无数web程序员都遇到过以下情况:网站上线不久,客户发现不好看,要求把界面重做,于是UI被推倒重来。但是大量的赋值语句,都是与控件命名紧密关联的。如果一个控件的ID或Name改变了(比如从TextBox1改名成TextBox2),这样原来的TextBox1.Text="Hello World"就无法再编译成功了。换言之:赋值的办法将界面逻辑与界面绑得太紧,是一种紧耦合的程序设计。在遇到UI频繁更新需求时,代码维护量极大,会让程序员们心率焦脆。

  三层是三层,MVC是MVC,它们毫无关系的。

  这两个东西我接触有几年了,有一点体会,表达一下:

4.2、后起之秀-MVC

为了将界面与行为分离,asp.net终于引入了mvc模式,即asp.net mvc(目前已经发展到3.0),MVC模式中,数据模型Model与页面View被分离成二个不相干的部分,在很大程序上实现了解耦,每个页面(即View)需要数据呈现时,Controller会从Model中拉出一份数据,然后扔给View,即:Controller充当了中介(或称为媒婆)的角色,负责在View与Model之间牵线搭桥。View在绑定数据时,只要关心媒婆介绍过来的Model即可,然后利用HtmlHelper将Model直接处理成最终所需要的html代码并渲染在页面上,不用再刻意关心每个控件的ID或Name是啥。MVC模式在遇到UI重构需求时,只要View对应的Model没有变化,Controller与Model这部分的代码基本上不用修改,只要改改View就行了,代码维护起来相对比较轻松。一切看上去很美,于是一时之间,MVC掀起了一阵高潮,甚至出现了asp.net mvp已死的论调。

三层是从整个应用程序架构的角度来分的三层(如果程序需要,还可以分多层)。

  三层是三层,MVC是MVC,它们毫无关系的。

4.3、MVC也有不给力的时候

asp.net mvc有二个明显的不足:

4.3.1、代码分离不彻底

aspx中仍然允许使用<%...%>来书写服务端代码,而且很多文章甚至推荐这样做(即使是微软大牛的官网博客也是如此),这在我看来是某种程度的倒退,又把逻辑与界面混在一起了,WebForm中的Code-Behind感觉都比这个要好。

4.3.2、绑定只是单向的

不管是asp.net webform,还是asp.net mvc,说到底都是传统的web技术,还算不上RIA,双向绑定还实现不了,Model在服务端绑定到View后,最终到达浏览器的只有html+css+js,如果能在“浏览器”客户端"自动"能感知UI的变化,并同步反应到Model本身,而不是每次都要提交表单,这该多好!

  三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题,为了使程序员更加专注的处理某阶段的业务逻辑。

三层是从整个应用程序架构的角度来分的三层(如果程序需要,还可以分多层)。

5、“双向绑定”—神来之笔

Silverlight/WPF的出现,一举解决了上面提到的二个不足。全新的xaml格式代替了aspx/ascx格式,在xaml的世界里,根本不允许任何服务端代码,这是彻底的cs代码/UI界面分离!而且全新的双向(TwoWay)绑定方式,能自动在UI与Model之间维持数据状态同步(即:用户在界面的控件上做了操作,与之绑定的Model能自动变化;反过来也一样,Model的数据变化了,UI上的控件呈现也会自动更新)

  比如将数据库操作代码封装到一层中,提供一些方法根据参数直接返回用户需要的相应数据,这样在处理具体的业务逻辑的时候,就不用关心数据的存储问题了。

  三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题,为了使程序员更加专注的处理某阶段的业务逻辑。

5.1、You jump,I jump!

《铁达尼号》中“解渴”与“肉丝”有一句经典台词:You jump,I jump ! 这句话的言外之意:你死了,我也不活了。用程序员的话说:就是"状态同步",你从生(的状态)到死(的状态),我也一样要保持相同的状态。这与双向绑定是多么的贴切!数据源的Model属性值变化了,界面会自动变出反应(更新某些控件的呈现);同样用户在界面上修改了控件值,Model的相应属性也随之同步变化。严重怀疑双向绑定的灵感源自这部经典电影:)双向绑定同时也道出了SL/WPF世界的一个真谛:数据驱动UI。(按佛家的说法可以理解为:UI只是一副空皮囊,内在的[血肉]元神完全由数据驱动)

MVC是在应用程序(BS结构)的视图层划分出来的不同功能的几个模块。

  比如将数据库操作代码封装到一层中,提供一些方法根据参数直接返回用户需要的相应数据,这样在处理具体的业务逻辑的时候,就不用关心数据的存储问题了。

5.2、M-V-VM ? or M-VM-V ?

此去略去N字节(N>=1024)...

  MVC主要是为了解决应用程序用户界面的样式替换问题,把展示数据的 HTML 页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑(用户界面)独立到一些文件中(Views),把一些和用户交互的程序逻辑(Controller)单独放在一些文件中,在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象,这些对象,统称为Models。

MVC是在应用程序(BS结构)的视图层划分出来的不同功能的几个模块。

5.2、砖家辟谣:Just in Client,No in Server!

此去略去N字节(N>=1024)...

  只所以说MVC和三层毫无关系,是因为它们二者使用范围不同:三层可以应用于任何语言、任何技术的应用程序;而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突,可以同时存在,也可根据情况使用其中一种。

  MVC主要是为了解决应用程序用户界面的样式替换问题,把展示数据的 HTML 页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑(用户界面)独立到一些文件中(Views),把一些和用户交互的程序逻辑(Controller)单独放在一些文件中,在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象,这些对象,统称为Models。

5.3、内部实现机制胡侃

此去略去N字节(N>=1024)...

 

  只所以说MVC和三层毫无关系,是因为它们二者使用范围不同:三层可以应用于任何语言、任何技术的应用程序;而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突,可以同时存在,也可根据情况使用其中一种。

5.4、转换器—让双向绑定如虎添翼

此去略去N字节(N>=1024)...

 

 

5.5、屁股决定脑袋,思路决定出路

此去略去N字节(N>=1024)...

注:先理一个提纲,有空再回来完成填空。

 

 

 

三层架构就是MVC!

起初老师总说三层MVC,MVC三层架构……

三层架构就是MVC!

所以开始的时候脑子就一个概念:三层就是MVC,MVC就是三层架构。而且想想也合理啊,都是“三”。MVC是三个字母,三层架构也是“三”,理所应当的就对应上了。然后就这么一直“错”了很长时间。

起初老师总说三层MVC,MVC三层架构……

三层架构绝不是MVC!!

所以开始的时候脑子就一个概念:三层就是MVC,MVC就是三层架构。而且想想也合理啊,都是“三”。MVC是三个字母,三层架构也是“三”,理所应当的就对应上了。然后就这么一直“错”了很长时间。

后来学习了J2EE之后发现老师说的好像不对,MVC和三层架构不是一个东西。三层架构是界面层(UI)业务逻辑层(BLL)和数据访问层(DAL)构成的,而MVC是模型层(M)界面层(View)和控制层(Controller)构成的,而且他们之间也不对应。

三层架构绝不是MVC!!

如果硬要给他们对应的话,那么三层架构中的UI对应MVC中的view(jsp),都是用于显示以及获取界面的数据;三层架构中的BLL层和DAL层对应MVC中的Model(javabean)层都是用于处理上层传递来的数据以及从数据库获取的数据的;MVC中的Controller(Servlet)最多算是三层架构中的UI的一部分,也就我们常说的是Servlet。

后来学习了J2EE之后发现老师说的好像不对,MVC和三层架构不是一个东西。三层架构是界面层(UI)业务逻辑层(BLL)和数据访问层(DAL)构成的,而MVC是模型层(M)界面层(View)和控制层(Controller)构成的,而且他们之间也不对应。

如下图所示:

如果硬要给他们对应的话,那么三层架构中的UI对应MVC中的view(jsp),都是用于显示以及获取界面的数据;三层架构中的BLL层和DAL层对应MVC中的Model(javabean)层都是用于处理上层传递来的数据以及从数据库获取的数据的;MVC中的Controller(Servlet)最多算是三层架构中的UI的一部分,也就我们常说的是Servlet。

图片 1

如下图所示:

顿时感到世界明朗了,对分层又深入了解了一步。

图片 2

其实三层架构和MVC还是一个东西!!!

顿时感到世界明朗了,对分层又深入了解了一步。

这几天一直在思考三层架构和MVC到底是个什么关系,老师为什么起初会放在一起说嘞?然后恍然大悟:其实三层架构和MVC是一样的!!!我们所看到的不一样只是表面上的不一样。核心的东西是一致的,那么什么是核心?

其实三层架构和MVC还是一个东西!!!

答曰:分层,解耦!

这几天一直在思考三层架构和MVC到底是个什么关系,老师为什么起初会放在一起说嘞?然后恍然大悟:其实三层架构和MVC是一样的!!!我们所看到的不一样只是表面上的不一样。核心的东西是一致的,那么什么是核心?

如果从解耦的角度来看三层架构和MVC其实他们是一致的,只不过划分的方法不一样罢了,就像上面的图所示。从这一点说他们可以说是一个东西。这就相当于我们看到馒头和面条一样,表面上看他们不一样(注意仅仅是表面)但是他们核心是一致的,都是面……

答曰:分层,解耦!

知识的学习过程就要像老牛反刍一样,需要不断的加深认识,最终才能真正领悟

如果从解耦的角度来看三层架构和MVC其实他们是一致的,只不过划分的方法不一样罢了,就像上面的图所示。从这一点说他们可以说是一个东西。这就相当于我们看到馒头和面条一样,表面上看他们不一样(注意仅仅是表面)但是他们核心是一致的,都是面……

对事物的认识是从感性到理性的,是一步一步的加深的,每一步的加深也许会推翻以前的自己,也许会更加赞同以前的自己。如果是推翻以前的自己那么代表对这个事物的认识发生了翻天地覆的变化,但是如果赞许以前的自己也并不代表自己的观点没有变化,往往表面上看起来一致的东西其实内核并一定是相同的。就像刚开始的时候认为三层架构和MVC是一个东西到最后同样是认为这两是一个东西,但是理解的层次绝对是不一样的。

知识的学习过程就要像老牛反刍一样,需要不断的加深认识,最终才能真正领悟

至于以后会不会再次推翻自己的观点我不晓得,只能说每次推翻都代表着进步,代表着理解的更深一层,所以我期望着下次的否定自己

对事物的认识是从感性到理性的,是一步一步的加深的,每一步的加深也许会推翻以前的自己,也许会更加赞同以前的自己。如果是推翻以前的自己那么代表对这个事物的认识发生了翻天地覆的变化,但是如果赞许以前的自己也并不代表自己的观点没有变化,往往表面上看起来一致的东西其实内核并一定是相同的。就像刚开始的时候认为三层架构和MVC是一个东西到最后同样是认为这两是一个东西,但是理解的层次绝对是不一样的。

 

至于以后会不会再次推翻自己的观点我不晓得,只能说每次推翻都代表着进步,代表着理解的更深一层,所以我期望着下次的否定自己

 

 

 

与MVC的区别  MVC(模型Model-视图View-控制器Controller)是一种设计模式,我们可以用它来创建在域对象和UI表示层对象之间的区分。

 

与MVC的区别  MVC(模型Model-视图View-控制器Controller)是一种设计模式,我们可以用它来创建在域对象和UI表示层对象之间的区分。

  同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。

 

 

  同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。

  在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

 

 

  在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

 

 

TAG标签:
版权声明:本文由金沙澳门官网4166发布于世界史,转载请注明出处:mvc与三层结构终极区别,更是一门艺术