将ASP.NET MVC放入文中外文翻译资料

Putting ASP.NET MVC in Context

ASP.NET MVC is a Web development framework from Microsoft that combines the effectiveness and tidiness of model-view-controller (MVC) architecture, the most up-to-date ideas and techniques from agile development, and the best parts of the existing ASP.NET platform. It is a complete alternative to traditional ASP.NET Web Forms, delivering advantages for all but the most trivial of Web development projects. In this chapter, yoursquo;ll learn why Microsoft created ASP.NET MVC, how it compares to its predecessors and alternatives, and, finally, whatrsquo;s new in ASP.NET MVC 5 and whatrsquo;s covered in this book.

Understanding the History of ASP.NET

ASP.NET was a huge shift when it first arrived in 2002. Figure 1-1 illustrates Microsoftrsquo;s technology stack as it appeared then.

Figure 1-1. The ASP.NET Web Forms technology stack

With Web Forms, Microsoft attempted to hide both HTTP (with its intrinsic statelessness) and HTML (which at the time was unfamiliar to many developers) by modeling the user interface (UI) as a hierarchy of server-side control objects. Each control kept track of its own state across requests (using the View State facility), rendering itself as HTML when needed and automatically connecting client-side events (for example, a button click) with the corresponding server-side event handler code. In effect, Web Forms is a giant abstraction layer designed to deliver a classic eventdriven graphical user interface (GUI) over the Web.

The idea was to make Web development feel just the same as Windows Forms development. Developers didnrsquo;t need to work with a series of independent HTTP requests and responses. They could think in terms of a stateful UI, and Microsoft could seamlessly transition the army of Windows desktop developers into the new world of web applications.

What Is Wrong with ASP.NET Web Forms?

Traditional ASP.NET Web Forms development was great in principle, but reality proved more complicated:

bull; View State weight: The actual mechanism for maintaining state across requests (known as View State) results in large blocks of data being transferred between the client and server. This data can reach hundreds of kilobytes in even modest Web applications, and it goes back and forth with every request, leading to slower response times and increasing the bandwidth demands of the server.

bull; Page life cycle: The mechanism for connecting client-side events with server-side event handler code, part of the page life cycle, can be extraordinarily complicated and delicate. Few developers have success manipulating the control hierarchy at runtime without getting View State errors or finding that some event handlers mysteriously fail to execute.

bull; False sense of separation of concerns: ASP.NET Web Formsrsquo; code-behind model provides a means to take application code out of its HTML markup and into a separate code-behind class. This has been widely applauded for separating logic and presentation, but, in reality, developers are encouraged to mix presentation code (for example, manipulating the server-side control tree) with their application logic (for example, manipulating database data) in these same monstrous code-behind classes. The end result can be fragile and unintelligible.

bull; Limited control over HTML: Server controls render themselves as HTML, but not necessarily the HTML you want. In early versions of ASP.NET, the HTML output failed to meet with Web standards or make good use of Cascading Style Sheets (CSS), and server controls generated unpredictable and complex ID attribute values that are hard to access using JavaScript. These problems are much improved in recent Web Forms releases, but it can still be tricky to get the HTML you expect.

bull; Leaky abstraction: Web Forms tries to hide HTML and HTTP wherever possible. As you try to implement custom behaviors, you frequently fall out of the abstraction, which forces you to reverse-engineer the postback event mechanism or perform obtuse acts to make it generate the desired HTML. Plus, all this abstraction can act as a frustrating barrier for competent Web developers.

bull; Low testability: The designers of Web Forms could not have anticipated that automated testing would become an essential component of software development. Not surprisingly, the tightly coupled architecture they designed is unsuitable for unit testing. Integration testing can be a challenge, too.

Web Forms isnrsquo;t all bad and Microsoft has put a lot of effort into improving standards compliance, simplifying the development process, and even taking some features from ASP.NET MVC. Web Forms excels when you need quick results, and you can have a reasonably complex web app up and running within a day. But unless you are careful during development, you will find that the application you create is hard to test and hard to maintain.

■Note For complete details of ASP.NET Web Forms, see my Pro ASP.NET 4.5 in C# book, also published by Apress. I cover the complete framework and provide best-practice guidance for avoiding the most serious pitfalls.

Web Development Today

Outside Microsoft, Web development technology has been progressing rapidly and in several different directions since Web Forms was first released.

Web Standards and REST

The drive for Web standards compliance has increased in recent years. Web sites are consumed on a greater variety of devices and browsers than ever before, and Web standards (HTML, CSS, JavaScript, and so forth) remain the great hope for enjoying a consistent browsing experience. Modern web platforms canrsquo;t afford to ignore the business case and the weight of developer enthusiasm for Web standards compliance.

HTML5 has begun to enter mainstream use and provides the Web developer with rich capabilities that allow the client to perform work that was p

剩余内容已隐藏，支付完成后下载完整资料

将ASP.NET MVC放入文中

ASP.NET MVC是一个来自微软的Web开发框架，它结合了模型-视图-控制器（MVC）体系结构的有效性和整洁性，来自敏捷开发的最新思想和技术，以及现有ASP的最佳部分。网络平台。它是传统ASP.NET Web Forms的完全替代品，为所有Web开发项目提供了优势，但最微不足道的Web开发项目除外。在本章中，您将了解微软为什么创建ASP.NET MVC，它与它的前辈和替代品的比较，最后，ASP.NET MVC 5的新特性，以及这本书的内容。

了解ASP.NET的历史

ASP.NET在2002年首次出现时是一个巨大的转变。ASP.NET Web表单技术如图1-1所示。

图1 – 1 ASP.NET Web表单技术

使用Web表单，Microsoft试图通过将用户界面（UI）建模为服务器端控件对象的层次结构来隐藏HTTP（其固有的无状态性）和HTML（当时许多开发人员并不熟悉HTML）。每个控件跨请求跟踪自己的状态（使用Viewstate工具），在需要时将自己呈现为HTML，并自动将客户端事件(例如，单击按钮)与相应的服务器端事件处理程序代码连接起来。实际上，Web Forms是一个巨大的抽象层，旨在通过Web交付一个经典的事件驱动的图形用户界面（GUI）。

这个想法是为了让Web开发和Windows窗体开发感觉一样。开发人员不需要处理一系列独立的HTTP请求和响应。他们可以从有状态UI的角度来考虑问题，微软可以无缝地将Windows桌面开发人员大军转移到web应用程序的新世界。

ASP.NET Web Forms的问题

传统的ASP.NET Web Forms的开发在原则上是很棒的，但事实证明要复杂得多:

（1）视图状态权重：跨请求维护状态的实际机制（称为视图状态）导致在客户机和服务器之间传输大量数据。即使是在普通的Web应用程序中，这些数据也可以达到数百kb，并且它会随着每个请求来回移动，导致响应时间变慢，并增加服务器的带宽需求。

（2）页面生命周期：连接客户端事件和服务器端事件处理程序代码（页面生命周期的一部分）的机制可能非常复杂和微妙。很少有开发人员能够在运行时成功地操作控件层次结构，而不会获得视图状态错误或发现某些事件处理程序神秘地无法执行。

（3）错误的关注点分离意识：NET Web Forms的代码隐藏模型提供了一种方法，可以将应用程序代码从其HTML标记中提取出来，放到一个单独的代码隐藏类中。这在分离逻辑和表示方面广受好评，但实际上，鼓励开发人员将表示代码（例如，操作服务器端控制树）与应用程序逻辑（例如，操作数据库数据）混合在这些可怕的代码隐藏类中。最终的结果可能是脆弱和难以理解的。

（4）对HTML的有限控制：服务器控件将自己呈现为HTML，但不一定是您想要的HTML。在早期的ASP版本，HTML输出未能满足Web标准或充分利用层叠样式表（CSS），服务器控件生成了不可预测的复杂ID属性值，这些属性值很难使用JavaScript访问。在最近的Web表单发行版中，这些问题得到了很大的改进，但是要获得您期望的HTML仍然很棘手。

（5）漏洞抽象：Web表单尽可能地隐藏HTML和HTTP。当您试图实现自定义行为时，常常会脱离抽象，这迫使您对回发事件机制进行反向工程，或者执行obtuse操作，以使其生成所需的HTML。此外，所有这些抽象对于有能力的Web开发人员来说都是一个令人沮丧的障碍。

（6）可测试性低：Web表单的设计者没有预料到自动化测试将成为软件开发的一个重要组成部分。毫不奇怪，他们设计的紧密耦合架构不适合进行单元测试。集成测试也可能是一个挑战。

Web表单并不都是坏的，微软已经投入了大量的精力来改进标准遵从性，简化开发过程，甚至从ASP.NET MVC中获得新的特性。当需要快速的结果时，Web表单非常出色，并且可以在一天之内启动并运行一个相当复杂的Web应用程序。但是除非在开发过程中非常小心，否则会发现您创建的应用程序很难测试和维护。

■注：ASP.NET Web Forms，请参阅我的Pro ASP.NET 4.5在c#书中，也由Apress出版。我将介绍完整的框架并提供最佳实践指导，以避免最严重的陷阱。

今天的Web开发

自从Web Forms首次发布以来，在微软之外，Web开发技术已经在几个不同的方向快速发展。

Web标准和REST

近年来，对Web标准遵从性的要求有所增加。Web站点使用的设备和浏览器比以往任何时候都要多，Web标准（HTML、CSS、JavaScript等等）仍然是享受一致浏览体验的最大希望。现代web平台不能忽视业务案例和开发人员对web标准遵从性的热情。

HTML5已经开始进入主流应用，并为Web开发人员提供了丰富的功能，允许客户端执行以前由服务器独家负责的工作。这些新功能以及诸如AngularJS、JQUERY、JQUERY UI和JQUERY Mobile等JavaScript库的日益成熟意味着标准变得越来越重要，并为越来越丰富的Web应用程序奠定了关键基础。

■注：我在本书中提到了HTML5、JQUERY及其近亲，但我没有深入讨论，因为这些主题本身就是主题。如果你想要更全面的报道，那么Apress出版了我关于这些主题的书籍：Pro AngularJS, Pro JQUERY 2.0, Pro JavaScript for Web Apps，以及HTML5的权威指南。

与此同时，具象状态传输（REST已经成为HTTP上应用程序互操作性的主导架构，完全盖过了SOAP (ASP。NET对Web服务的原始方法）。REST根据表示真实实体的资源（URL）和表示这些资源上可用操作的标准操作(HTTP方法)来描述应用程序。例如，您可以放置一个新的http://www.example.com/Products/Lawnmower或删除http://www.example.com/Customers/Arnold-Smith。

今天的Web应用程序不仅仅提供HTML。通常，它们还必须向客户端技术（如AJAX和本地智能手机应用程序）提供JSON或XML数据。这在REST中很自然地发生，它消除了Web服务和Web应用程序之间的区别，但是需要一种HTTP和URL处理方法，而ASP.NET FORMS不容易支持这种方法。

敏捷和测试驱动开发

成熟的不仅仅是Web开发。软件开发作为一个整体已经转向敏捷方法。这可能意味着许多不同的事情，但主要是关于将软件项目作为可适应的发现过程来运行，并抵制过度的提前规划。对敏捷方法的热情往往与促进和帮助这些实践的一组开发实践和工具（通常是开放源码的）密切相关。

测试驱动开发（TDD）及其近亲行为驱动开发（BDD）就是两个例子。其思想是通过首先描述所需行为的示例(称为测试或规范)来设计软件，以便在任何时候都可以通过针对实现执行测试套件来验证应用程序的稳定性和正确性。支持TDD/BDD的.NET工具并不缺乏，但这些工具往往不能很好地用于Web表单：

（1）单元测试工具允许您单独指定单个类或其他小代码单元的行为。这些只能有效地应用于作为一组独立模块设计的软件，以便每个测试可以独立运行。不幸的是，很少有Web表单应用程序可以通过这种方式进行测试。

（2）UI自动化工具允许针对应用程序的完整运行实例模拟一系列用户交互。这些可以与Web表单一起使用，但是只要对页面布局稍加更改，它们就会失效。如果没有特别注意，Web表单会更改HTML结构和元素ID，从而破坏测试套件。

（3）.NET开源和独立软件供应商(ISV社区产生了没有尽头的优质单元测试框架（NUnit和xUnit）、模拟框架（Moq和犀牛模拟）、控制反转容器（Ninject和AutoFac）、持续集成服务器（巡航控制和TeamCity）、对象关系映射器（NHibernate和亚音速）等等。传统的ASP.NET Web Forms不适合这些工具和技术，因为它的设计是单一的，所以Web表单很少受到这些项目的尊重。

Ruby on Rails

2004年，Ruby on Rails是一个默默无闻的开源贡献者。一夜成名，改变了Web开发的规则。这并不是说Ruby on Rails包含革命性的技术，而是这个概念采用了现有的元素，并以一种引人注目和吸引人的方式将它们混合在一起，使现有平台相形见绌。

Ruby on Rails（或者通常称为Rails）采用了MVC架构，我将在第3章中对此进行描述。通过应用MVC并与HTTP协议保持一致，通过促进约定而不是配置需求，以及通过将对象关系映射（ORM工具）集成到其核心，Rails应用程序或多或少地就就位了。好像这就是Web开发应该一直遵循的方式。Rails表明，Web标准的遵从性和rest性并不需要很困难。它还表明，当框架被设计为支持敏捷开发和TDD时，它们工作得最好。此后，Web开发领域的其他领域一直在迎头赶上。

Node.JS

另一个重要趋势是将JavaScript作为主要编程语言的趋势。AJAX首先表明JavaScript很重要;JQUERY向我们展示了它的强大和优雅;谷歌的开源V8 JavaScript引擎向我们展示了它可以很快。今天，JavaScript正在成为一种严肃的服务器端编程语言。它作为几个非关系数据库（包括CouchDB和Mongo）的数据存储和查询语言，并在服务器端平台（如Node.js）中作为从2009年开始出现通用语言Node.JS，并很快得到了人们的认可。其主要创新点如下:

（1）使用JavaScript：开发人员只需要使用一种语言工作，从客户端代码到服务器端逻辑，甚至通过CouchDB或类似的方式进行数据查询逻辑。

（2）完全异步：Node.JS的核心API没有公开在等待输入/输出(I/O)或任何其他操作时阻塞线程的任何方法。所有I/O都是通过开始操作，然后在I/O完成后接收回调来实现的。这意味着Node.js可以高效地使用系统资源，每个CPU可以处理数万个并发请求。（可选平台往往被限制在每个CPU大约100个并发请求。）

JS仍然是一种利基技术。奇怪的是，它对WEB应用程序开发的最大贡献是提供了一个一致的JavaScript引擎，可以在这个引擎上编写开发工具。许多新兴的客户端JavaScript框架（如AngularJS）都基于Node.js的使用提供了良好的工具支持。

用于部署web应用程序的Node.js采用得比较慢。大多数在有限时间内构建实际应用程序的企业通常需要使用Ruby on Rails和ASP.NET MVC等全堆栈框架。这里提到Node.JS只是为了放一些ASP.NET MVC的设计与行业趋势背道而驰。例如,ASP.NET MVC包含异步控制器（我将在第19章中描述）。这是一种使用非阻塞I/O处理HTTP请求的方法，并且可以扩展到每个CPU处理更多的请求。

ASP.NET MVC主要优点

2007年10月，微软宣布了一个新的MVC Web开发平台，构建在核心ASP.NET平台之上，显然是作为对Rails等技术发展的直接响应和对Web表单批评的响应而设计的。下面的部分描述了这个新平台如何克服Web表单的限制，并将ASP.NET带回前沿。

MVC体系结构

区分MVC体系结构模式和ASP.NET MVC框架是很重要的。MVC模式并不新鲜——它可以追溯到1978年和施乐parc的Smalltalk项目——但是它作为Web应用程序的模式在今天已经非常流行，原因如下：

（1）与MVC应用程序的用户交互遵循一个自然循环：用户采取一个动作，应用程序相应地更改其数据模型，并向用户交付一个更新后的视图。然后循环重复。这非常适合作为一系列HTTP请求和响应交付的Web应用程序。

（2）web应用程序需要结合几种技术（例如数据库、HTML和可执行代码），这些技术通常分为一组层或层。这些组合产生的模式自然地映射到MVC中的概念。

ASP.NET MVC框架实现了MVC模式，并在此过程中大大改进了关注点的分离。事实上,ASP.NET MVC实现了MVC模式的现代变体，特别适合于Web应用程序。在第3章中，您将学习更多关于这种体系结构的理论和实践。

通过采用和适应MVC模式，ASP.NET MVC框架为Ruby on Rails和类似平台提供了强有力的竞争，并将MVC模式带入了.NET世界的主流。通过利用使用其他平台的开发人员发现的经验和最佳实践，在很多方面，ASP.NET MVC已经超越了Rails所能提供的。

可扩展性

MVC框架是作为一系列独立的组件构建的，这些组件可以满足. NET接口，也可以构建在抽象基类之上。您可以很容易地用您自己实现的不同组件替换组件，例如路由系统、视图引擎和控制器工厂。通常，MVC框架为每个组件提供三个选项：

（1）使用组件的默认实现（对于大多数应用程序来说，这应该足够了）。

（2）派生默认实现的子类来调整其行为。

（3）用接口或抽象基类的新实现完全替换组件。

您将从第14章开始了解各种组件，以及如何以及为什么要对它们进行调整或替换。

严格控制HTML和HTTP

ASP.NET MVC生成干净的、符合标准的标记。它的内置HTML helper方法生成符合标准的输出，但是与Web表单相比，它有一个更重要的哲学变化。MVC框架鼓励您使用CSS设计简单、优雅的标记，而不是生成您几乎无法控制的大量HTML。

当然，如果您想为复杂的UI元素（如日期选择器或级联菜单）添加一些现成的小部件，ASP.NET MVC对标记的“无特殊要求”方法使使用最好的UI库（如JQUERY UI或引导C

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[19701]，资料为PDF文档或Word文档，PDF文档可免费转换为Word