65.9K
CodeProject 正在变化。 阅读更多。
Home

Asp.Net MVC 的“为什么”和“怎么做” 第 1 部分

2013 年 3 月 1 日

CPOL

10分钟阅读

viewsIcon

185459

Asp.net MVC 的基本理念、优点以及请求处理的细节。

背景

MVC 是开发界的新热点,每个人都在谈论并使用 mvc 进行开发。了解如何使用 Asp.Net MVC 很容易,谷歌可以为你提供数百个不错的资源,展示如何配置和编写代码。但从我的观点来看,在问“怎么做”之前先问“为什么”总是更好的。此外,MVC 并非孤立存在,它围绕着许多其他概念,如 db first、model first、code first、razor、TDD 等等。

每个概念本身都是一个庞大的主题,如果你谷歌一下,会找到很多关于它们的优秀资源。从这篇帖子开始,我计划发表一系列文章,解释以上每个概念或更多概念,然后慢慢转向实现,应用这些概念,并解释使用它们的优点/缺点。所以计划是采取小步骤到达终点。在这第一篇文章中,我们将讨论 MVC 的优点、适用性以及 Asp.Net MVC 的生命周期。

为什么选择 MVC

“将用户界面交互分为三个不同的角色。- Martin Fowler”是 MVC 的核心动机。最初,MVC 是应用程序逻辑与用户界面之战的产物。现在,显而易见的问题是这一切都是关于什么的?其思想是保持程序的可视化(即 UI)与其余功能之间的良好分离。这种分离使你能够单独处理每一层的各个方面——一次只处理一个复杂的问题。它还允许专业人士独立处理代码的不同部分。为了区分这两者,需要一种方法/模式,而这种方法是 Model View Controller (MVC) 中最突出的部分。将视图与应用程序的其余逻辑分离,为将来更改视图逻辑打开了大门。也许后来客户要求更具提取性的 UI 或更多的 UX 支持,或者更糟糕的是,进行彻底的改头换面。如果视图逻辑与业务逻辑紧密耦合,那么进行更改将会很困难。

MVC 模式最初是作为 Smalltalk 类库的一部分实现的。它最初被用作创建图形用户界面 (GUI) 的架构模式。后来,当它被应用到 Web 应用程序时,其含义和适用性发生了根本性变化。MVC 的动机是可重用性和关注点分离。所有其他好处都建立在这两个基石之上。

MVC 的适用场景

是否应该使用 MVC 一直是一个很大的困惑。但我认为没有一个直接的答案,这完全取决于应用程序的类型、你拥有的资源和时间,以及最重要的是我们对应用程序的控制程度。所以底线是我们必须仔细考虑是使用 Asp.Net MVC 框架还是 Asp.Net Web Forms 模型来开发 Web 应用程序。MVC 提供了很多东西,但在做出选择之前,我们需要考虑一些领域。

MVC 适用于由大型工程师和 UX 设计师团队支持的 Web 应用程序,这些团队需要对应用程序行为有高度的控制。如果你在小型工程师和 UX 设计师团队工作,并且希望利用大量组件快速开发应用程序,那么 MVC 可能不是一个好的选择。如果你依赖第三方厂商控件来处理 UI,那么你不应该使用 Asp.Net MVC。MVC 通过接口、类和其他 OOP 原理来利用面向对象编程的强大功能。如果某人对这些面向对象概念不太熟悉,那么该框架可能不适合该人员。但是,如果你想使用自动化测试、可插入式架构、对渲染 HTML 的完全控制以及丰富的 UI 支持,那么 MVC(在我们的例子中是 Asp.Net MVC)是最佳选择。

Asp.NET MVC

ASP.NET MVC 框架是微软努力创建一个围绕 MVC 模式的 ASP.NET 编程环境。正如官方网站所说:“ASP.NET MVC 是一个使用成熟的设计模式以及 ASP.NET 和 .NET Framework 的强大功能来构建可扩展的、基于标准的 Web 应用程序的框架。” Asp.net MVC 构建在 .NET 框架之上,并利用了 asp.net 的核心功能。而且,这绝不意味着 Web Forms 已经过时或不能使用。在我看来,Asp.net MVC 是处理我们习惯用 Web Forms 做的那些事情的一种更好的方式。

现在的问题是,对于习惯了 RAD(快速应用程序开发)风格的开发人员来说,采用这个新框架有多难?答案是很容易。怎么做?尽管我们使用的是 MVC,但我们仍然在使用 Visual Studio,我们仍然在使用 asp.net 框架,这不是很棒吗?是的,服务器控件不可用,但如果你没有服务器控件,标记会多么干净,并且由于模型/视图是分开的,测试会容易得多。在我们自己的 ASP.NET Web 应用程序的上下文中,模型、视图和控制器参与者可以解释为:

  • 视图:这是 ASPX 页面中的 HTML 标记。它在表示层(浏览器)中渲染。
  • 控制器:这指的是一个简单的类控制器,它根据哪个视图来决定需要显示哪个模型。
  • 模型:这是一个处理数据的层,它可能由业务层处理。
Page Controller 模式,这是 ASP.NET Web Forms 中的默认架构,存在一些限制。应用程序中的每个页面都有一个单独的 Page Controller,因此代码隐藏文件可能包含大量代码,需要大量的维护工作。第二个问题是应用程序的测试,特别是 GUI 和代码隐藏类非常困难,而且我们无法使用自动化测试工具。与使用 Page Controller 模式的 Web Forms 不同,MVC 基于 Front Controller 设计,其中一个中心化的控制器决定渲染哪个视图。并且由于模型、视图和控制器都是分开的,因此与 Asp.Net MVC 相比,自动化测试从未如此简单。
 

优点

在我们得出是否使用 MVC 的结论之前,让我们先看看使用 MVC 的几个优点。

  1. 在一定程度上分散了开发工作,使得 Web 应用程序某一部分的实现更改不需要更改另一部分。负责业务逻辑的工程师、负责控制流程的工程师和 Web 页面设计者可以独立工作。
  2. 可以轻松进行原型开发。例如,你可以这样做:创建一个访问多个工作站程序的原型 Web 应用程序。根据用户反馈更改应用程序。在同一平台或其他平台上实现生产级别的程序。
  3. 你可以更容易地迁移遗留程序,因为视图与模型和控制器是分开的,并且可以根据平台和用户类别进行定制。
  4. 你可以在跨越不同位置的环境中维护一个包含不同技术的环境。
  5. MVC 设计具有更好的组织结构,更能支持可扩展性(构建更大的应用程序)以及易于修改和维护(由于任务划分更清晰)。
  6. 它不使用视图状态或服务器端表单。这使得 MVC 框架成为想要完全控制应用程序行为的开发人员的理想选择。
  7. 它为测试驱动开发 (TDD) 提供了更好的支持。
  8. 它使用 Front Controller 模式,通过单个控制器处理 Web 应用程序请求。因此可以设计自定义路由基础设施。
如果我们考虑 Web Forms 作为替代方案,让我们看看 Web Forms 有什么优势。
  1. 它支持一个事件模型,该模型在 HTTP 上保留状态,这有利于业务线 Web 应用程序的开发。基于 Web Forms 的应用程序提供了数十个事件,这些事件在数百个服务器控件中得到支持。
  2. 它使用 Page Controller 模式,为单个页面添加功能。有关更多信息,请参阅 Page Controller。
  3. 它在服务器端表单中使用视图状态,这可以使状态信息的管理更容易。
  4. 它适用于希望利用大量组件快速开发应用程序的小型 Web 开发人员和设计人员团队。
  5. 总的来说,对于应用程序开发来说,它的复杂性较低,因为组件是紧密集成的,而且如果考虑 LOC(代码行数),所需的代码比 MVC 少。

 

Asp.net MVC 生命周期

要理解 MVC 请求执行过程,我们必须从头开始,也就是 IIS。现在让我们从 IIS 的角度来看。由于 Asp.NET MVC 构建在 asp.net 框架之上,因此从用户请求被 HTTP.sys 拦截到工作进程处理请求,与 asp.net Web 应用程序保持一致。尽管 ASP.NET 在不同版本的 IIS 中以不同的方式执行,但现在讨论这些超出了范围。我们将重点关注 HTTP 请求进入 MVC 框架的部分。

Asp.Net 请求处理可以分为 4 个简单步骤:

  1. 步骤 1 – 路由:这是 ASP.NET 应用程序首次启动时的第一个步骤。UrlRoutingModule 会拦截每个请求。为了让 MVC 路由处理程序处理请求,需要在应用程序启动时配置路由表。在配置带有默认模板的 MVC 时,在 global.asax 文件中提供了默认的路由配置。
  2. 步骤 2 – MvcHandler:MvcHandler 创建一个控制器,将 ControllerContext 传递给控制器,并执行该控制器。
  3. 步骤 3 – 控制器:MVC 控制器工厂在 CreateController 中定位并创建控制器。控制器确定要执行哪个控制器方法,构建参数列表,然后执行该方法。ControllerContext 被传递到控制器类的 Execute() 方法。
  4. 步骤 4 – Action:控制器方法以调用 RenderView() 或 RedirectToAction() 方法结束。RenderView() 方法负责将视图(页面)渲染到浏览器。Controller.RenderView() 方法将其工作委托给特定的 ViewEngine。
简而言之,步骤是:
请求 --> 路由 --> MvcHandler --> 控制器 --> Action
上述过程是默认行为,但 asp.net MVC 允许根据需要进行微调,您甚至可以使用异步控制器等专用控制器来提高性能。现在我们已经涵盖了 MVC asp.net 的基础知识,希望我没有遗漏任何基本概念。在下一篇文章中,我们将深入探讨 Asp.Net MVC,描述如何利用 mvc 内置功能并与 web forms 进行比较。
一个重要的提示是,当 ASP.NET MVC Web 应用程序在 IIS 7.0 中运行时,不需要文件扩展名,但在 IIS 6.0 中,您应该将 .mvc 文件扩展名映射到 ASP.NET ISAPI DLL。

MVC 中的设计模式

尽管 MVC 本身就是一种设计模式,但整个 MVC 框架本身包含了一些设计模式。下面是 MVC(或 Asp.Net MVC)中使用的设计模式列表,无论平台如何。这些模式在 MVC 中的详细描述超出了本文的范围,我相信你可以谷歌搜索并了解更多关于它们的信息。

Front Controller 通过将请求引导至中央控制器来整合所有请求处理。
策略 视图-控制器关系,控制器在运行时将视图连接起来的方式。
Factory Method 为视图指定默认控制器类。
装饰器 (Decorator) 在 MVC 的上下文中,装饰器可以应用于你的视图。
观察者 一个模型,多个视图(观察者/订阅者),发布者管理通信。
中介器 (Mediator) 几个不同的模型,几个视图,中介者管理它们之间的通信。

参考和好读

系列计划

  1. Asp.Net MVC 的“为什么”和“怎么做” 第 1 部分 - MVC 基础
  2. Asp.Net MVC 的“为什么”和“怎么做” 第 2 部分 - 玩转 Asp.Net MVC
  3. Asp.Net MVC 的“为什么”和“怎么做” 第 3 部分 - DB First
  4. Asp.Net MVC 的“为什么”和“怎么做” 第 4 部分 - Model First
  5. Asp.Net MVC 的“为什么”和“怎么做” 第 5 部分 - Code First

历史

版本 1.0

© . All rights reserved.