第 2 章 创建正确的开发观念

第 2 章 创建正确的开发观

本章将介绍利用ASP.NET MVC 进行网站开发时应有的观念,强大的工具若没有正确的观念支持,就像是给你一台马力强又省油的手排车,而你却不知道离合器该如何使用,也许在试了一段时间之后,觉得车子还是开不快,就提前放弃了一部好车。拥有正确的开发观念可以带给你正确的学习方向,且在未来ASP.NET MVC撰写的过程中更顺利。

2.1 关注点分离

在MVC的世界里,有个非常重要的观念,那就是“关注点分离(Separation of Concerns,SoC)”。

关注点分离的意思就是,当你在进行软件开发时,可以只关注于当前的对象上,一次仅关注于一个较容易理解与解决的部分,不要受到相同系统中其他对象的干扰,也包括对对象所做出的修正不会影响到其他对象的运作,能够专注于完成手边的工作,不但容易提升软件质量,也可加快程序代码理解的速度。

ASP.NET MVC拥有非常清楚的关注点分离架构,不但让你的ASP.NET MVC项目更容易维护,更能够让你的ASP.NET MVC 项目应付各式各样的需求变更,进而加速项目开发与提高更好的客户满意度。

举个实际的案例来说:今天你接手到一个从未接触过的网站项目,该项目已经完成且在上线运作中。

当客户提到网站的“搜寻功能”必须改由AJAX 的方式查询,如果你已经熟悉ASP.NET MVC架构的话,应该会很直觉地想到,要去更改View部分。

如果客户提到在“更新会员信息”页面中有个字段必须从原本的非必填字段,改成必填字段,这时,由于关系到商业逻辑的字段验证,你也会很自然地想到,要去更改Model 里面的数据模型类别。

再者,如果客户希望当“联络我们”页面的窗体送出后,会“停留在原本窗体的页面”,现在想要更改成“重新导向到首页”,这时你应该也会很直觉地想到,只要更改Controller 即可。

也就是通过这种“关注点分离”的特性,将网站项目中的每个部分,都能够彼此独立运作,又能彼此分工,让我们在维护项目的过程中,更容易查找要更改的代码段。

关注点分离的特性与优点如下。

  • 简化复杂度

    若能将复杂的问题,拆解成数个容易解决的单元,并且让你一次仅关注于一个较容易理解的部分,如此,自然能够简化软件开发的复杂度。而简化复杂度意味着程序代码数量变少,相对的也降低了程序错误(Bugs)出现的机率。

  • 可维护性大幅提升

    在ASP.NET MVC里,不仅区分Model 、View、Controller 三种关注点,若项目越来越大,复杂度越来越高的话,你还可以再切割成更多层次,只要关注点能够清楚地分离,降低对象之间的耦合关系,相对的你也就越容易掌握项目的各个环节,这样便能让项目更易于维护。

  • 更容易测试

    由于单元测试是软件测试的最小单位,以往开发人员在ASP.NET Web Form 架构下并不容易撰写单元测试程序,不过采用ASP.NET MVC 框架进行开发时,却非常适合撰写单元测试程序,若项目能不断强化关注点分离的特性,将能够更有效率地实施单元测试。也因为这点,选择ASP.NET MVC架构的团队,更适合采用测试导向开发方法(TDD)来进行项目建置,提升程序代码质量。

2.2 以习惯替换配置

撰写程序时,必须规划各式各样的架构,例如命名规则定义、目录结构规划、三层式体系结构,等等。由于架构是由“人”打造的,每个人的经验、想法、喜好也都不太一样,因此,不同开发人员所规划出来的架构,也都会不太一样,所以每当程序代码换人接手维护时(例如,客户更换厂商、员工离职交接、网站重新改版等),将整个架构“打掉重练”变成软件业界的常态,因为通常没有人会想要接手另一位开发人员所规划的架构或程序代码。

以习惯替换配置(Convention over Configuration) 是一种软件设计模式,主要目的在于减少开发人员在架构时所决策的时间以及降低软件设计过于弹性,而导致太复杂的情况,通过约定俗成的“开发习惯”,让同一群开发人员得以共享同一套设计架构,减少思考时间,降低沟通成本,且不失软件开发的弹性。

ASP.NET MVC就是一个合理使用以习惯替换配置的开发框架,它将通过MVC设计模式常见的规则,切割成Model 、View、Controller 三个部分,而且明确定义开发人员必须按照特定的“习惯”来开发程序。

2.2.1 Controller

  • 所有Controller 类别习惯置于项目的Controllers 目录下,如图2-1 所示。

    {%}

    图 2-1 Controllers 目录

  • Controller 类别名称必须以Controller 结尾,且类别中所有的公开方法(public method) 默认都是Action 方法,如图2-2 所示。

    图 2-2 Controller 类别名称必须以Controller 结尾

2.2.2 View

所有View页面习惯配置的目录位置是在项目的Views目录的子目录里。Views目录下的第一层子目录名称必须是相对应的Controller 名称,且View页面的文档名,必须以Controller 里的Action 名称来命名,而扩展名可以是aspx、ascx 或cshtml, 如图2-3所示。

{%}

图 2-3 Views 目录

2.2.3 Model

所有Model 相关类别习惯配置的目录都位于项目的Models 目录下,如图2-4所示。

{%}

图 2-4 Models 目录

以上这些被规范的“习惯”是ASP.NET MVC 架构的默认值,如果想要变更这个开发配置,还是可以通过各种方式进行调整或扩充的,在ASP.NET MVC 架构下几乎没有不能变更的配置。

重点提示 在一个开发团队里,项目开始架构之前,定义出一套大家都能认同的习惯,是非常重要的。

2.3 开发ASP.NET MVC 项目时的建议

初学者刚开始接触ASP.NET MVC 时,很容易对ASP.NET MVC 项目类型生成疑问,虽然ASP.NET MVC 已经定义出许多默认的项目架构配置,但除了这些习惯必须养成以外,其实还有许多需要注意的开发观念,拥有正确的开发观念,将能有效降低开发过程带来的难度。

1. 不要重复你自己

在面向对象编程的领域,好的软件设计不应该有太多重复的程序代码,所以不要重复你自己(Don't Repeat Yourself,DRY)是每一个开发人员都应该遵守的原则。

重点提示 由于Don't Repeat Yourself 这三个英文单字的缩写刚好是DRY(干燥),所以,有时候会有人说:“让你的项目『干』一点”,就是指不要让项目有太多重复的程序代码。

在ASP.NET MVC之中也隐含地包括了DRY特性,通过Model 、View、Controller 明确地切割,让应用程序明确切割成三块,各自分工合作,并让MVC之间得以各司其职以避免重工,进而写出架构更清楚、程序代码更易于维护的软件。

除了通过Model 、View、Controller 明确地切割之外,事实上,ASP.NET MVC还能切割更多的层次,也都应该谨守DRY的原则,项目才会更易于维护。

2. 没有完美的架构,只有适合的架构

学习设计模式与软件架构最困难的地方就在于“抉择”,因为在架构设计时往往会因为不同的需求、环境、限制、人力资源,而必须做出取舍(Trade-off),因此,可以大胆地假设这个世界“没有最完美的架构,只有最合适的架构”。

ASP.NET MVC是个非常强大且弹性的开发框架,它提供一个基础框架给你,只要妥善利用这个框架的特性,即便在完全不自定义的情况下,也可开发出非常具有弹性且易于维护的网站。

3. 发挥“想像力”才能让开发更顺利

对不太熟悉ASP.NET MVC的人来说,很有可能会让ASP.NET MVC开发出来的网站难以维护,所以在架构时,必须经常思考还有没有改进的空间、对于之前写好的程序是否有重构(Refactoring) 的机会等问题,有时必须发挥一些想像力,才能让开发过程更加顺利,如果团队中有人可以一起讨论,将有利于激发出更好的开发架构。

4. 适合的设计模式有助于提升架构质量

在ASP.NET领域的开发人员大多非常依赖开发工具,以致于大部分又对“设计模式”着墨不深,但这对软件架构设计来说,很容易被局限住。而市面上提到“设计模式”的书籍多数以Java为主,似乎也很难得到.NET阵营开发人员的青睐,还好C#与Java两者程序语言非常相近(至少语法相似),即使阅读Java相关程序时,也不会太吃力。重点仍在于必须了解设计模式的概念,而非程序代码!

每一个设计模式都是为了解决某种问题而设计的,所以,并非所有设计模式都用上就是好设计,而是当你了解这些设计模式后,在遇到特定的问题时,可以通过这些既有的设计模式来解决架构上的困难,进而提升架构质量。

5. 切割你的脑袋,而且至少切成三份

采用ASP.NET MVC 架构一个网站时,最好随时随地在脑袋中切割成三份(M、V、C),这是一个最基本的切割单位,而且也是最容易切割的三个部分,如图2-5所示。

{%}

图 2-5 MVC 切割示意图

但是在实务上,通常不会这么简单,有时候我们会再多切割成好几块,例如,服务层(Service Level) 、数据访问层(Data Access Layer) 、数据仓储层(Repository Level) 、辅助工具层(Helper Level)等,依据实际开发的需求,可以设计出最适合你们团队的开发架构。

TIPS 虽然切割多层次可以提高关注点分离的特性,但若项目架构不会太复杂的情况下,建议不用切割太多层次,否则因为切割了过多层次,而导致复杂度变高或影响开发速度的话,那就本末倒置了。

6. 写程序、想架构,一定要有“感受”

谁说写程序、想架构是个“理性”的工作。身为架构师必须经常“感情用事”,要能融合过往的开发经验、不断吸收新知,以及收集各方需求与意见后,再发展出适合自己团队的架构,并统合出一个“较好”或“较坏”的感受。

当我带领一个团队时,经常会要求团队成员写程序一定要有自己的想法,而不要“照抄”或“复制粘贴”,为的就是培养写程序的感受。每一行程序代码、每一层架构都应该让自己有感受,如果能多与他人讨论自己的想法或架构,相信不用多少时间就能培养出自己的感受,对自己的程序与架构也会越来越有信心。

7. 创建有责任感的物件

使用ASP.NET MVC 开发网站不得不考虑“责任”这件事。因为通过基本的M、V、C三层切割已经定义出Model 负责商业逻辑、View负责前端呈现、Controller 负责流程控制等不同的权责,意即这三者之间必须彼此分工合作,并严守纪律不得逾越。

创建有责任感的对象可以有如下作用。

  • 降低程序复杂度:当网站需求变更时,你可以依据清楚的权责分工很容易查找对的地方进行修正。

  • 增加分工能力:通过架构规划,将一个大型网站切割成多个组件来开发,彼此之间通过界面(Interface) 定义沟通,这样一来就能够让项目加速完工。

  • 让各组件得以抽象化,进而降低组件之间的耦合程度,也可以减少对象之间彼此的影响程度,对于规划大型架构都有非常好的帮助。

8. 对象合作要有所规范

我们在开发较为复杂的Web应用程序时,实务上经常利用界面(Interface) 降低类别与类别之间的耦合性,主要是先设计界面(Interface)再实作类别(Class),而在Controller 中撰写程序时,几乎都是以界面作为跟Model 沟通的桥梁,通过这种开发方法主要有以下好处。

  • 更容易进行测试。

  • 有效取得M、V、C 之间的关联,专注于界面而非实作细节。

  • 更容易搭配IoC(Inversion of Control) 或DI(Dependency Injection) 容器,让对象的配置策略与生命周期的管理更加弹性。

9. 相信永远有更好的解决方法

虽然ASP.NET MVC 有绝佳的弹性,但在开发时还是要能权衡得失,不要太随性地开发。不过,需求总是不断地变化,面对变化时就应该思考当前的架构、程序、对象分工是否合适,以及思考是否有更好的架构、更好的设计模式,并不定时进行重构,确保网站的架构处于最佳状态。

10. 没有人可以将软件一次写对

没有人可以将软件一次就写对,如同没有人可以将需求一次讲清楚一样,因为需求不断在变。所以,别想一次把程序写对!唯一能做的是保持架构的弹性与可维护性,保持软件的可测试性,让ASP.NET MVC项目能够应付各种改变,以确保软件的质量在一定的范围内。

好的软件是从多个高质量的代码段组成的,对于每次的需求变更都应该好好审视,本次变更到底对整个项目冲击有多大?如果你能够将每个程序都写好相对应的测试程序,那么也不用担心项目每次的变更所带来的冲击了,因为测试程序就是你最佳的后盾。

11. 不要为了改变而改变,改变是为了适应未来

想想十多年前ASP.NET刚上市的那段时间,许多ASP开发人员开始犹豫要不要转向到ASP.NET,过了几年,越来越多的人用ASP.NET开发技术了,我想,很多人应该都很清楚如果这时再不改变,很可能会被市场淘汰,因此被迫转向到ASP.NET 开发领域。

对于热情的开发人员来说,他们经常拥抱改变。“改变”对他们来说只需要一个理由,而不需要人云亦云地随波逐流,或被时势所逼的自怨自艾,但毋庸置疑的,这段转换的过程必定辛苦。请想想你从ASP转向到ASP.NET 的理由是什么?好用的开发工具?酷炫的高速开发展示?不用再写出意大利面式(指ASP的程序代码与HTML绑在一起)的程序代码?

我之前从PHP转到ASP.NET 的过程很辛苦,但我很清楚并非只是为了改变而改变,目标支持我走过了改变的过程,当努力学会ASP.NET 之后,才又重新查找之前写PHP 时的自信,这过程大约花了一年左右的时间,之后便不断钻研博大精深的ASP.NET 与.NET技术,并研究开发工具如何提升开发效率。

对于ASP与PHP 两种语言的好与坏我都很了解,转换到ASP.NET Web Forms 之后,其实在心中一直有些疑虑,那就是对ASP.NET Web Forms 有种“易学难精”的感受,相信有很多初学者通过工具一下子就上手了,然后花好几年的时间不断地尝试错误,整体来说,软件质量很难进步,而且网站缺乏可测试性,也不容易多人协同开发。

我会投入ASP.NET MVC 的开发领域,就是看见了许多在日常开发工作中遇到的困难,例如无法有效进行单元测试、网页版面不容易套版、缺乏关注点分离的开发架构等,这些都是ASP.NET MVC 比以往ASP.NET Web Form 的优越之处,当你有观念支持自己改变的时候,你就不会为了改变而苦了。

2.4 ASP.NET MVC 常见问题

这几年来,笔者除了自己写ASP.NET MVC 项目外,也带过不少开发人员一起写ASP.NET MVC项目,除此之外,也从网络上得知不少初学者的问题,因此做个总的整理,希望能解决初学者学习ASP.NET MVC 的种种疑惑。

1. 仿佛又回到了ASP年代

ASP.NET MVC与ASP表面上感觉虽然很像,但是骨子里却截然不同,若深入了解ASP、ASP.NET Web Forms 与ASP.NET MVC ,就能感受到哪里不一样了。在ASP 的世界里,并没有适当的模板引擎(Template Engine) 可用,所以,所有的程序逻辑与视觉呈现都会混在一起,我们又称这种程序为“意大利面式”的写法。过多的程序代码反而难以维护,笔者曾经接手过一个由8 000 个ASP程序开发而成的网站,维护起来真是累人。

到了ASP.NET Web Forms 年代,开始有了Code Behind 的概念,能有效分离程序代码与HTML,但是微软为了仿照Windows Form 的开发方式,导入了ViewState与事件驱动模型(Event Model) ,让网页开发如同Windows Form 一般容易,而且可以通过Visual Studio视觉化开发工具与服务器控件等组件化技术,将HTML包装得非常简便实用,这是个伟大的改变,至少实现了许多开发人员能够快速开发网站的梦想。

但面临越来越复杂的Web需求,ASP.NET Web Forms 也跟着变得异常复杂且难以维护,尤其是面临HTML微调时,更是ASP.NET Web Forms 开发人员的梦魇,如果还拿不到控件的源代码,那才真是痛苦万分。再换句话说,新人要上手ASP.NET Web Forms 非常容易,但写出来的程序代码无比恐怖,能写出一个页面的ViewState 超过1MB 的大有人在,由此可知,对ASP.NET页面生命周期不了解而衍生的Bug不知道有多少。

进入ASP.NET MVC 纪元,很多人认为View的写法与ASP如出一辙,但View的角色已经被重新定义,在ASP.NET MVC 的View里,不应该再有复杂的程序或商业逻辑,仅留下“视觉呈现”的部分而已,例如,HTML、JavaScript 、数据呈现、窗体等,其余的全都交由Controller 负责控制,由Model 负责访问数据与验证数据格式,厘清彼此的责任后才能写出好的关注点分离架构,进而提升项目的可维护性。

2. 与常规ASP.NET Web Forms 开发有何不同

ASP.NET Web Forms 历经了十年的演进,其组件化技术已经非常成熟,但利用Web Forms 开发Web应用程序还是会遇到许多瓶颈与限制,几乎所有ASP.NET 开发人员都会遇到这些恼人的问题,例如:

  • 邪恶的ViewState ( 用了像GridView 这种超大控件就非常容易失控)。

  • 控件组件对HTML 的控制不够直观或太过复杂(也有人说:控件很难控制)。

  • 不容易采用TDD(Test-driven Development) 测试导向开发模式开发,也不容易撰写单元测试

许多ASP.NET 开发人员对MVC设计模式非常陌生,而且ASP.NET MVC 是近几年才正式推出的技术,一个又新又陌生的技术相信会让许多人望之却步,不过,还是希望各位能以理性的态度看待。以下是ASP.NET MVC 的优缺点。

优点

  • 清楚的关注点分离(Separation of Concerns,SoC)强迫你写出比Web Forms 更易维护的程序。

  • 开放特性(完全开放源代码)。

  • 社群支持(当前国外社群非常活跃)。

  • 可轻易地控制HTTP 的输出属性(这点比Web Forms 好太多太多了)。

  • 优秀的开发效率(这也是一般人的疑虑,以下会有帮助)。

  • 易于测试的架构。

  • 易于分工的架构。

缺点:

  • 相较于Web Forms 来说,ASP.NET MVC 较缺乏工具支持。

  • 开发人员必须面对HTML、CSS 与JavaScript 在View 页面上的配置,不像使用Web Forms 开发网站时,即使不懂HTML、CSS、JavaScript 也能开发网站。

  • 缺乏成熟的组件化技术支持(Server Control、HTML Helper) 。

3. 与ASP.NET Web Forms 有何相同之处

有很多人并不了解原来ASP.NET Web Forms 与ASP.NET MVC 其实是共享同一套ASP.NET基础框架,这也意味着这两套开发框架的底层技术是一样的,两者之间的共同特性是这两个技术都实作IHttpHandler 来处理网页,像ASP.NET Web Forms 的所有页面就是继承Page类别实作出来的(Page类别有实作IHttpHandler 界面),而ASP.NET MVC 用的是MvcHandler 类别(MvcHandler 类别有实作IHttpHandler 界面)。

如果我们从程序代码来看,默认ASP.NET Web Forms 的Code Behind 都会继承System.Web.UI.Page 类别,如图2-6所示。

{%}

图 2-6 继承System.Web.UI.Page 类别

如果我们用知名的Reflector 工具来看Page 类别的源代码,就会知道Page的确操作了IHttpHandler 界面,所以ASP.NET Web Forms 的每一页都是一个HttpHandler,如图2-7所示。

{%}

图 2-7 Page 操作IHttpHandler 界面

在ASP.NET MVC里,所有HTTP的要求,最后都会导向到MvcHandler 类别来处理,我们通过Reflector 看一下 Page 类别的定义,的确也有实作IHttpHandler 界面,如图2-8 所示。

{%}

图 2-8 MvcHandler 操作IHttpHandler 界面

虽然ASP.NET MVC 也都是通过MvcHandler 类别来运行,但这并不像ASP.NET Web Forms 每一页都有Page类别,所以不容易得知其实是使用MvcHandler 来运作的,假若先在ASP.NET MVC项目的Controller 程序代码里设置断点,如图2-9所示。

{%}

图 2-9 先在HomeController.cs 类别的Index() 方法设置一个断点

进入调试模式并发生中断时,可以通过“调用堆栈”窗格,就能得知整个ASP.NET MVC完整的运行过程,如图2-10所示。

{%}

图 2-10 ASP.NET MVC 的运行过程会经过MvcHandler 这一段

4. 微软现在有许多各式Web开发技术,也都来自于ASP.NET 基础架构吗

是的,以微软当前最新的Web开发技术(Microsoft Web Stack) 来说,你可以发现图2-11中,所有最上层的各式开发技术,如ASP.NET Web Form 、ASP.NET MVC 、ASP.NET Web Pages 、ASP.NET Web API 等,全都来自最底层的ASP.NET基础架构,图中的Sites(网站类)与Services(服务类)只是一个逻辑上的分类而已。

{%}

图 2-11 微软当前最新的Web 开发技术(Microsoft Web Stack)

5. 必须舍弃常规ASP.NET Web Forms 的哪些东西

通过以上所述,得知ASP.NET Web Forms 与ASP.NET MVC一样,都依赖ASP.NET 基础架构所提供的功能,虽然ASP.NET MVC 也用到部分ASP.NET 页面框架的技术,但并不多,在ASP.NET MVC不能使用的技术如下。

  • ViewState 。

  • ASP.NET 页面追踪机制(Page Trace) 。

  • ASP.NET 事件驱动模型(Event Model) 。

  • 服务器控件(Server Control)。大部分不能用,但没用到ViewState 的还是能用来作为显示用途。

  • Default SiteMap Provider 。

除此之外,ASP.NET开发人员当前学会的ASP.NET 技术都可以继续使用,无论是开发观念与撰写方法都完全没改变!例如,ASP.NET 应用程序生命周期(Application Life Cycle),ASP.NET提供者模型(Provider Model) 如Membership 、Profile 、SiteMap、Web Caching、Session、Authentication 等,简易的功能对照如表2-1所示。

表 2-1 ASP.NET MVC 与ASP.NET Web Forms 简易的功能对照

支持功能

ASP.NET Web Forms

ASP.NET MVC 1.0~4.0

ViewState

×

ASP.NET 页面追踪机制(Page Trace)

 

ASP.NET 事件驱动模型(Event Model)

 

×

服务器控件(Server Control)

 

部分支持

System.Web.SiteMapProvider 类别

 

×

ASP.NET Provider Model

 

 

System.Web.Caching 命名空间

 

 

System.Web.SessionState 命名空间

 

 

System.Web.Security 命名空间

 

 

Profile, Membership, SiteMap

 

 

其他 System.Web.* 功能

 

 

6. 是否可以与ASP.NET Web Forms 混合在同一个项目里使用

可以。由于这两个开发框架都是实作IHttpHandler 界面所开发出来的,差别仅在于ASP.NET Web Forms 的每个页面都会对应到网站主机的实体路径,而ASP.NET MVC 则是通过网址路由(Routing) 决定要运行哪个Controller 与Action,所以只要网址不冲突,基本上这两种开发框架的类别与文档是可以放置在同一个项目中,而且是完全不会互相打架的。

重点提示 若是以ASP.NET MVC 项目模板开发出的网站,要和ASP.NET Web Form 混合在同一个项目下通常不会有问题,但在实务上,如果ASP.NET MVC 开发人员将网址路由(Routing) 的规则设置错误,确实也会导致一些奇怪的状况,例如,特定ASP.NET Web Form 无法开启,或是无法读取网站特定目录下的静态文档等。

7. ASP.NET MVC 速度是否比ASP.NET Web Forms 慢

关于“速度”可以从以下几个层面来详述。

  • 开发速度/ 开发效率:由于ASP.NET MVC 是新技术,刚开始使用的开发速度一定比你熟悉的Web Forms 慢,但在学习一段时间后,则会发现在Visual Studio 2012 工具的辅助之下,其开发速度绝对不亚于ASP.NET Web Forms 开发网站的速度,而且整体来说,ASP.NET MVC 的可维护性会更好。

  • 运行速度:ASP.NET Web Forms 的庞大页面框架所耗用的CPU 指令集绝对比ASP.NET MVC 要多出很多,如果单就这点来看,ASP.NET MVC 绝对胜出!不过,事事无绝对,优秀的ASP.NET Web Forms 开发人员写出来的程序,仍有可能比资历浅的ASP.NET MVC 开发人员写的程序来得快!

8. M、V、C真的可以各自独立开发吗?是否会有所限制

可以,但没那么绝对!完全独立开发虽然可行,但你如果真的这么做就会束手束脚的,而且会失去工具的支持。这里的“完全独立开发”是指项目一开始就让M、V、C 独立开发,其实没什么必要性,但是可行。M、V、C的关系是既分工又合作,彼此之间必须在有点黏又不能太黏的情况下才能发挥其优势。

以笔者的实务开发经验来说,觉得M(Model) 是MVC架构的中心,有了Model 之后,就可以让Controller 与View参考这些Model (模型),先定义出所有计划开发的Controller 与Action ,然后再创建所有Action 对应的View (无属性的View),之后就可以将不同单元的Controller 与View分工开发,最后再进行集成即可,这是我认为最有效率的开发方法。

9. 现有的ASP.NET Web Forms 项目是否可以逐步转移至ASP.NET MVC 专案

严格一点来说:没办法,必须重新来过、打掉重练!

宽松一点来说是可以的。如果你的ASP.NET Web Forms 项目已经区分两层或三层式体系结构,可以将现有项目信息访问层(Data Access Layer,DAL) 当成ASP.NET MVC 的Model 来使用,再依据现有网站架构重新规划Controller 、Action与网址结构,最后将现有网站的功能改写至Controller或View 。但请记得MVC 的几个基本原则,例如,关注点分离、以习惯替换配置、不要重复你自己(DRY),以及其他本章前面提及的一些观念。

10. ASP.NET MVC 是否能让开发人员和网页设计师完美分工

对于负责处理View的开发人员来说,HTML、CSS、JavaScript算是开发ASP.NET MVC时的必备技能,使用ASP.NET MVC已经不能再像ASP.NET Web Form 的时候,可以完全不懂HTML、CSS也能开发出Web应用程序,除此之外,如果开发人员也能熟悉JavaScript 或jQuery 的话,对于开发出一些交互网页将会有很大的帮助。

对于基本的网页版型设计、版面配置、HTML撰写、CSS规划等工作,我还是建议让专业的网页设计师来负责,让开发人员调整网页版面其实是很没效率的,如果网页设计师的逻辑不错的话,倒是可以参与View的开发,这并非不可能,因为ASP.NET MVC 的View 在开发时,有个基本原则就是要“够笨”,不要将复杂的商业逻辑与程序控制写在View里面,对于View 的详细开发技术请参见“第7章 View 数据呈现相关技术”帮助。

请记得本章稍早提到的“没有完美的架构、只有适合的架构”原则,笔者有很多网页设计师朋友,不但会自行设计网页、规划CSS样式、规划HTML信息结构,有些还会自行撰写一些简单的jQuery交互程序,更厉害的还有设计师知道如何规划MasterPage 、Page与UserControl 等,真的想要完美一点,还可以教会他使用Visual Studio 开发工具,以及直接撰写ASP.NET MVC的View页面与基本的C#程序控制逻辑(if、for 、foreach、while等),这些如果都学会的话,你是不是觉得很完美了呢?但再学下去,他可能会忘记如何做网页设计,转行做开发人员了!当然,这也不是件坏事啦。

11. 从其他程序语言/开发平台转向接触ASP.NET ,何种情况需要导入ASP.NET MVC

如果是ASP.NET 的新手,建议你还是可以学习Web Forms ,因为市面上谈论Web Forms 的书籍非常多,只是ViewState、页面事件模型与控件这些主题在ASP.NET MVC 里不会用到,但此外的技术在ASP.NET MVC 都用得上,所以不失为一种学习路径。

对一个从其他语言,如Ruby、PHP、ASP、Python ,转移接触ASP.NET 的开发人员来说,ASP.NET MVC 是最好的选择,因为不需要像笔者一样忍受PHP转ASP.NET Web Forms 残酷的阵痛期,因为开发模式真的差很多。

如果你学过其他语言的MVC架构(例如PHP 的CakePHP),在学习ASP.NET MVC 时更能得心应手,只要将一些基本的.NET 开发技能学得扎实一点,比如C# ( 或VB.NET)、.NET基础、Visual Studio 开发工具、IIS等。其他必备的技能还有HTML、CSS、JavaScript 、jQuery 、HTTP 、JSON等,虽然看起来很多,但是学习Web技术就必须要懂这些东西才能走得长久,即便是学习ASP.NET Web Forms 也是如此。

12. MVC架构真的适用网页开发吗

笔者自己的经验是“非常适合”,MVC是一种设计模式(Design Pattern) ,不仅仅可用在Web领域,还有很多其他领域都适合用MVC来开发。ASP.NET MVC是为了Web应用程序开发所设计的MVC框架,至于是否适合,就必须要等你实际动手写、动脑想、跌几次跤就会有深刻的体会了。

13. ASP.NET Web Forms 会被ASP.NET MVC 替换吗

综观来看,先回头想想之前ASP转ASP.NET 的时代,至今已经十余年,你觉得ASP 被替换了吗?并没有!还是有许多网站依然是用ASP开发而成,而且还运作得不错,所以讲“替换”是不切实际的。

由于ASP.NET Web Forms 与ASP.NET MVC虽然在开发架构上有很大的不同,但彼此共享的技术非常多,例如,ASP.NET应用程序生命周期(Application Life Cycle) 、ASP.NET提供者模型(Provider Model) ,如Membership 、Profile、SiteMap 、Web Caching、Session、Authentication 等。因此,两者平行存在的时间可能会比ASP与ASP.NET 平行存在的时间还更久,不过这只是“综观来看”。

微观来看,一家公司如果决心转向ASP.NET ,应该也会陆续摆脱ASP 的牵连吧?长久来看,同时维持多项不兼容的技术成本很高,所以,一开始也许会两者并行,最后还是会彻底摆脱旧技术。相对来说,如果你的公司决心将技术领域从ASP.NET Web Forms 转向ASP.NET MVC ,但你不愿意转型的话,那么你在这家公司的价值也会不断降低,因为两者开发模式差别甚大,在同一家公司或同一个开发团队中,长时间维持两种完全不同的开发模式不太明智,也许短时间内必须维护旧有系统一段时间,但时日一久,必定集成为全新的开发模式,但此前提是“如果一家公司决心将技术领域转向ASP.NET MVC开发框架”。

如果已经将现有ASP.NET Web Forms 程序悉数转移至ASP.NET MVC ,也真没有将这两个开发框架并存的必要性,况且将开发框架从ASP.NET Web Forms 转到ASP.NET MVC的过程是不可逆的,也就是当你爱上了ASP.NET MVC ,就不会再想着用ASP.NET Web Forms 来开发Web应用程序,那种魅力与实际获得的效益是不言而喻的。

如果要用一句话简单响应这个问题,那就是:“老兵不死,只是逐渐凋零”。

14. ASP.NET MVC 的除错方式是否与ASP.NET Web Forms 有所不同

在Visual Studio 开发工具里,你原本就熟悉的断点设置、查看监视器、查看调用堆栈等,基本的开发技巧都没有改变。

但如果你的网站部署到正式主机时,需要获得一些追踪信息的话,就有些许不同了。由于ASP.NET MVC 不使用ASP.NET Web Forms 的ASP.NET Page Handler处理网页,所以内建的ASP.NET追踪(ASP.NET Tracing)机制无法使用,必须采用NET标准的追踪机制,请参考Trace类别与Debug 类别等相关信息。

2.5 总结

本章讲解的是一些开发观念,对于.NET初学者来说可能会有点艰深难懂,不过当你越来越资深的时候,不妨回头看看本章的内容,相信会有不同的感悟。

{%}

目录