ASP.NET MVC模式 温习(一)排除MVC模式误区

(1)三层架构和MVC模式。

    不知道大家有没有和我的类似经历。记得大学一次看见班长在学习JAVA中的MVC。就很好奇的问:班长,MVC到底是啥子嘛?)班长回答了半天总结出一句话:MVC就是“控制器,视图,模型”,和三层架构差不多。难道MVC就是分别对应了三层架构中的“DAL,BLL和UI”?下面分别分析下三层架构和MVC模式。

    三层架构,在长期的软件开发过程中,人们经历了"UI"--->“UI+BLL”---> “UI+BLL+DAL”三种时代--->.....。

    UI层时代:人们通常把所有的表现、业务逻辑和数据库访问的代码都放在一起。这样做的结果是维护起来是相当困难的,因为一旦遇见需求变更,维护起来将是一件相当麻烦的事情。也许你只想更改数据访问的一段代码,但是可能造成的结果却是你不得不修改大片业务逻辑和变现代码。因此,人们提出了“单一职责”和“职责分离”的原则,决定将表现和业务逻辑分开,这样就形成了“UI层”和“BLL”,他们之间由“服务接口”相连(依赖倒置原则),彼此活动互不影响。于是,聪明的人们就进入下一时代。

    UI+BLL层时代:表现和业务逻辑的分离让我们更好的完成开发,但是为了降低数据访问和业务逻辑间的冗余,人们开始进入三层架构甚至多层架构的时代。

    有了三层架构,人们可以很轻松的面对需求变更(也有可能出现各层级联修改的情况,这就要考软件设计师的功夫了,做到“开放关闭”),但是回到最开始的WEB层时代,现在的“表现层”就相当于当时的"WEB层",只是外面将业务逻辑和数据访问等代码分离。但是,表示层依然会出现后台代码和展示混在一起的情况,但是至少不会或很少出现维护繁琐的情况。为了更好的实现“职责分离”,MVC模式诞生了。 Model层实现系统中的业务逻辑,View层用于与用户的交互, Controller层用于接收VIew提交的用户数据并转发给相应的Model,同时接收Model的数据处理结果转发给View。这样表现层的代码彻底做到“职责分离”了。

    下面我们做三种假设:第一、项目中,仅仅运用MVC模式。第二、项目中,仅仅运用三层架构。第三、项目中,同时运用MVC模式和三层架构。

    假设一,在项目中,所有的业务逻辑和数据库访问均由Model承担。这样的Model是不是略显臃肿呢?如果我仅仅改动数据访问会不会影响大片的业务逻辑代码呢?个人认为,不可取。

    假设二,在项目中,仅运用三层架构,如上所说,至少逻辑上的变化不大,有问题也是表示层内部的事情。个人认为可取。

    假设三,在项目中,运用三层架构可以减少逻辑和表现等方面的冗余,运用MVC又可以减少变现层内部的冗余。个人认为可取。

    特别注意:以上三种假设和三种时代的划分,均是在项目足够大和足够复杂的前提下进行的。个人认为,技术架构的选择应该由项目环境决定,而不是越好的技术结构就能开发出越好的项目。比如说用C#开发一个小心的计算器,个人认为没有必要用什么架构和模式了(排除项目需求扩展等情况),如果用什么三层架构、MVC,开发成本就太大了,而且架构在一定程度上也会影响项目的性能 。

    总结:1、三层架构和MVC模式并没有必然的关联,只不过是不同重心和程度上的解耦。三层注重解耦表现、业务逻辑和数据访问。MVC模式注重表现和逻辑(包括业务逻辑和数据访问等等)上的解耦,在一定程度上,三层架构的解耦更深,MVC的解耦更细。

       2、如果三层架构和MVC模式同时运用,MVC则侧重于解耦表现和业务逻辑接口, 和MVP,MVVM等模式一样构成表现层上的解耦。和BLL中的领域模型模式、DAL中的ORM模式等等一样

  (2)ASP.NET MVC == MVC???

    

    仔细看出其实MVC其实由两条路组成:第一、Model和View直接通信。第二、Model和View通过Controller进行通信。而ASP.NET MVC就是第二条路的一个实现(策略模式)。第一条路就是外面常用的ASP.NET Form的实现,通过事件驱动模型(观察者模式)和回发机制(postback)实现Model和View之间的通信,到底微软为啥子不直接叫MVC,这个还真不晓得。 至于两条路同时走,这个我真不知道。

    总结: ASP.NET MVC不过是MVC的一种实现,ASP.NET MVC 不等于MVC。

  (3)、MVC是属于JAVA的嘛?

    一开始MVC在Java中的运用非常广泛,所以像我这样苦逼的程序员在上学的时候都以为MVC是JAVA的固有特性,其实不然。MVC是一种思想,是无数个苦逼程序员经验和分析的积累。而Java中的MVC仅仅是仅仅是MVC的一种和Castle mvc,ASP.NETMVC一样。

    总结 :MVC是对前人无数经验的思考和总结而得出的一种架构思想。

      (4)、ASP.NET MVC是否将取代ASP.NET ?

    ASP.NET MVC是否将取代ASP.NET?在项目开发的过程中,外面是否应该放弃ASP.NET,而用ASP.NET MVC?这是我刚看到MVC遇见过的问题。ASP.NET MVC 没有在继续ASP.NET的道路---事件驱动+回发,而是回到最原始的时期,给我们提供了一条新的道路。正如上面第二点所说。两者各有千秋。

    ASP.NET MVC的优势:

      ASP.NET MVC由前端控制器模式的思想实现。这使的他具有非常完美的地址映射。

      ASP.NET MVC通过控制器、视图、模型的结构,可以更好的组织逻辑,解决复杂问题。

      ASP.NET MVC更容易进行单元测试,有利于“测试驱动开发”--OOT;

     ASP.NET MVC的掠势:

      在开发过程中无法使用设计--代码的切换,不能做到所见即所得。无法使用控件等进行快速开发。无法使用视图状态(ViewState)等。。。。等等等等。

    总结,从上面的陈诉可以看到,ASP.NET MVC面对开发,出现了很多不能,这些不能可以为我们的开发提供很多的便利,比如开发成本、周期、效益等等方面。可以看出,ASP.NET MVC并不能动摇ASP.NET的地位。个人认为,如果你是一个期望用短期的时间收获比较高的效益,而且你的项目复杂度较低,ASP.NET是最佳的选择。如果面临比较复杂的业务逻辑,ASP.NET MVC可以更好的帮助我们组织并实现它。


   貌似,当初的疑惑就只有这些,后面开始慢慢的总结下ASP.NET MVC的东东。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值