Asp.net MVC contorllers
在Ajax全面开花的时代,ASP.NET Web Forms 开始慢慢变得落后。有人说,Ajax已经给了Asp.net致命一击。Ajax使越来越多的控制在Html和客户端代码完成。随着时间的推移,导致了架构的变化,也使ASP.NET Web Forms有点不能适应当今潮流。
基于当前的ASP.NET运行时环境和MVC模式,诞生了一个新的架构——ASP.NET MVC,这种组合的Web开发模式顺应了当今的开发的趋势。
在ASP.NET MVC中,每一个请求最终就是执行一个特殊类中的Action方法。Action的执行结果被传递给带有视图模版的视图子系统中。浏览器最终的响应结果就是由Action的执行结果和这个模版创建的。
与Web Forms不同,ASP.NET MVC是由各个层的代码连接在一起的,这些层次之间既不是相互交叉,也不是单一一坨的模块。正因如此,根据自定义组件能很轻松的替换其中任何一层,这样就提高了解决方案的可维护性和稳定性。使用ASP.NET MVC,不仅有标签的完全控制权,还可以使用样式和喜欢的js框架。
尽管你想坚持使用Web Froms,但是对于当今的Web开发来说,ASP.NET MVC 确实是一个更好的选择。我们不需要花费太多的时间去学习,但是我们必须知道怎么运用以及MVC工作原理。如果这样做了,那么我们投入将会快速的带给我们应有的回报。
注:本系列是基于ASP.NET MVC 5。该版本是向前兼容的,也就是说,一台电脑中可以同时安装新老版本,新版本运行不会影响现存MVC版本代码。
路由请求
最初,ASP.NET平台的开发主要是围绕着服务器端物理页面请求的思想。在ASP.NET应用程序中使用的大多数的URL是由两部分组成:包含逻辑的物理网页的路径,和一些填充在查询字符串中的作为参数的数据。这种方式已经使用了有些年了,现在仍在被使用。ASP.NET运行时环境没有限制我们只能调用特定位置或者文件的资源。通过写一个专门的HTTP处理程序,并绑定到URL,我们就可以使用ASP.NET响应一个非依赖于物理文件的请求执行代码。这只是ASP.NET MVC不同于ASP.NET Web Forms众多不同中的一个方面。接下来我们看看如何通过使用一个HTTP处理程序来模拟ASP.NET MVC行为。
注:在软件中,专业术语URI(Uniform Resource Identifier)是用于通过位置或名称来引用的资源。当URI通过位置来标识资源时,就是URL(Uniform Resource Locator)。当URI通过名称标识资源时,就变成了URN(Uniform Resource Name)。在这方面,ASP.NET MVC是设计来处理更通用的URI,而ASP.NET Web Forms被设计来处理位置识别物理资源。
模拟ASP.NET运行时
我们构建一个简单的ASP.NET Web Forms应用程序,使用HTTP处理程序搞清楚ASP.NET MVC应用程序的内部机制。我们从最基本的ASP.NET Web Forms应用程序开始。
定义辨认URLs的语法
请求的URLs不需要匹配服务器端的物理文件。第一步列出应用程序有意义的URLs。为了避免太特殊,我们假设支持几个固定的URLs,把他们映射到一个HTTP处理程序模块。下面的代码片段显示了请求中默认Web.config的变化
<system.web>
<httpHandlers>
<add verb="*" path="home/test/*" type="MvcEmule.Components.MvcEmuleHandler"/>
</httpHandlers>
</system.web>
MvcEmuleHandler
只要应用程序收到一个与配置中匹配的URL请求,就会转到相应的处理程序。
定义HTTP处理程序行为
在ASP.NET中,HTTP处理程序是一个实现了IHttpHandler接口的组件。非常简单,只有两个成员,代码如下:
public class MvcEmuleHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
// 业务逻辑
} public Boolean IsReusable
{
get { return false; }
}
}
public class MvcEmuleHandler : IHttpHandler
大多数时候,HTTP处理程序是根据输入数据的查询字符串传递(query string)相关的硬编码行为。然而,他不能阻止我们使用请求处理程序最为抽象工厂,增加一个或多个简介层。事实上,我们可以使用请求处理程序中的请求信息,来确定外部的实际服务请求。按照这种方式,一个简单的HTTP请求程序可以服务于大量的请求,只要调用一些更加专门的组件。
HTTP 处理程序可以解析出 URL中的标记(Controller、action、param),并使用该信息来标识类和调用的方法。下面是它如何工作的示例:
public void ProcessRequest(HttpContext context)
{
// 转化 URL 并获取 controller, action, 和参数
var segments = context.Request.Url.Segments;
var controller = segments[].TrimEnd('/');
var action = segments[].TrimEnd('/');
var param1 = segments[].TrimEnd('/'); // 使用前缀和命名空间组装Controller类名
var fullName = String.Format("{0}.{1}Controller",
this.GetType().Namespace, controller);
var controllerType = Type.GetType(fullName, true, true); // 实例化controller
var instance = Activator.CreateInstance(controllerType); // 调用 controller 实例的 action 方法
var methodInfo = controllerType.GetMethod(action,
BindingFlags.Instance |
BindingFlags.IgnoreCase |
BindingFlags.Public);
var result = String.Empty;
if (methodInfo.GetParameters().Length == )
{
result = methodInfo.Invoke(instance, null) as String;
}
else
{
result = methodInfo.Invoke(instance, new Object[] { param1 }) as String;
} // 返回结果
context.Response.Write(result);
}
public void ProcessRequest(HttpContext context)
我们假设上面的代码中,服务器名称后面的第一个标记,唯一标识了服务请求的组件(类)。第二个标记涉及这个组件(类)中需要调用的方法名最后,第三个标记标识传递的参数
请求HTTP处理程序
在浏览器中输入一个URL http://localhost:9086/home/test/*,他的结果就是,“home”标识了类名,“test”标识方法名,无论结尾是什么,都作为参数。类型进一步制定,扩展为包含命名空间和后缀。根据实例,,最终类名是MvcEmule.Components.HomeController。预计这个类对于应用程序是可用的,也暴露一个名为Test的方法。看下结果:
public class HomeController
{
public String Test(Object param1)
{
var message = "<html><h1>Got it! You passed ‘{0}’</h1></html>";
return String.Format(message, param1);
}
}
public String Test(Object param1)
这个简单的实例说明了如何使用ASP.NET MVC最基本的机制。控制器(Controller)是一个为请求提供服务的专门的组件。控制器(Controller)是一个只有方法没有状态的类。一个独特的系统级HTTP处理程序负责将发来的请求匹配到一个特定的控制器类,这样一个类的实例将执行一个给定的操作方法,并产生一个响应。
那么Url 的方案是怎样呢?在此示例中,我们只是使用硬编码的 URL。在 ASP.NET MVC 中,有一种非常灵活的语法,可以使用表示应用程序能够识别的这些 Url。此外,一个新的系统组件在运行时管道中截取的请求、 处理 URL,并触发的 ASP.NET MVC HTTP 处理程序。此组件是 URL 路由的 HTTP 模块。关于URL路由模块,下次再译。