ASP.NET MVC下的异步Action的定义和执行原理[转]

http://www.cnblogs.com/artech/archive/2012/06/20/async-action-in-mvc.html

Visual Studio提供的Controller创建向导默认为我们创建一个继承自抽象类Controller的Controller类型，这样的Controller只能定义同步Action方法。如果我们需要定义异步Action方法，必须继承抽象类AsyncController。这篇问你讲述两种不同的异步Action的定义方法和底层执行原理。[本文已经同步到《How ASP.NET MVC Works?》中]

目录 
一、基于线程池的请求处理 
二、两种异步Action方法的定义 
    XxxAsync/XxxCompleted 
    Task返回值 
三、AsyncManager 
四、Completed方法的执行 
五、异步操作的超时控制

一、基于线程池的请求处理

ASP.NET通过线程池的机制处理并发的HTTP请求。一个Web应用内部维护着一个线程池，当探测到抵达的针对本应用的请求时，会从池中获取一个空闲的线程来处理该请求。当处理完毕，线程不会被回收，而是重新释放到池中。线程池具有一个线程的最大容量，如果创建的线程达到这个上限并且所有的线程均被处于“忙碌”状态，新的HTTP请求会被放入一个请求队列以等待某个完成了请求处理任务的线程重新释放到池中。

我们将这些用于处理HTTP请求的线程称为工作线程（Worker Thread），而这个县城池自然就叫做工作线程池。ASP.NET这种基于线程池的请求处理机制主要具有如下两个优势：

  • 工作线程的重用：创建线程的成本虽然不如进程的激活，却也不是一件“一蹴而就”的事情，频繁地创建和释放线程会对性能造成极大的损害。而线程池机制避免了总是创建新的工作线程来处理每一个请求，被创建的工作线程得到了极大地重用，并最终提高了服务器的吞吐能力。
  • 工作线程数量的限制：资源的有限性具有了服务器处理请求的能力具有一个上限，或者说某台服务器能够处理的请求并发量具有一个临界点，一旦超过这个临界点，整台服务将会因不能提供足够的资源而崩溃。由于采用了对工作线程数量具有良好控制的线程池机制，ASP.NET MVC并发处理的请求数量不可能超过线程池的最大允许的容量，从而避免了在高并发情况下工作线程的无限制创建而最导致整个服务器的崩溃。

如果请求处理操作耗时较短，那么工作线程处理完毕后可以及时地被释放到线程池中以用于对下一个请求的处理。但是对于比较耗时的操作来说，意味着工作线程将被长时间被某个请求独占，如果这样的操作访问比较频繁，在高并发的情况下意味着线程池中将可能找不到空闲的工作线程用于及时处理最新抵达请求。

如果我们采用异步的方式来处理这样的耗时请求，工作线程可以让后台线程来接手，自己可以及时地被释放到线程池中用于进行后续请求的处理，从而提高了整个服务器的吞吐能力。值得一提的是，异步操作主要用于I/O绑定操作（比如数据库访问和远程服务调用等），而非CPU绑定操作，因为异步操作对整体性能的提升来源于：当I/O设备在处理某个任务的时候，CPU可以释放出来处理另一个任务。如果耗时操作主要依赖于本机CPU的运算，采用异步方法反而会因为线程调度和线程上下文的切换而影响整体的性能。

二、两种异步Action方法的定义

在了解了在AsyncController中定义异步Action方法的必要性之后，我们来简单介绍一下异步Action方法的定义方式。总的来说，异步Action方法具有两种定义方式，一种是将其定义成两个匹配的方法XxxAsync/XxxCompleted，另一种则是定义一个返回类型为Task的方法。

XxxAsync/XxxCompleted

如果我们使用两个匹配的方法XxxAsync/XxxCompleted来定义异步Action，我们可以将异步操作实现在XxxAsync方法中，而将最终内容的呈现实现在XxxCompleted方法中。XxxCompleted可以看成是针对XxxAsync的回调，当定义在XxxAsync方法中的操作以异步方式执行完成后，XxxCompleted方法会被自动调用。XxxCompleted的定义方式和普通的同步Action方法比较类似。

作为演示，我在如下一个HomeController中定义了一个名为Article的异步操作来呈现指定名称的文章内容。我们将指定文章内容的异步读取定义在ArticleAsync方法中，而在ArticleCompleted方法中讲读取的内容以ContentResult的形式呈现出来。

   1: public class HomeController : AsyncController
   2: {
   3:     public void ArticleAsync(string name)
   4:     {
   5:         AsyncManager.OutstandingOperations.Increment();
   6:         Task.Factory.StartNew(() =>
   7:             {
   8:                 string path = ControllerContext.HttpContext.Server.MapPath(string.Format(@"\articles\{0}.html", name));
   9:                 using (StreamReader reader = new StreamReader(path))
  10:                 {
  11:                     AsyncManager.Parameters["content"] = reader.ReadToEnd();
  12:                 }
  13:                 AsyncManager.OutstandingOperations.Decrement();
  14:             });
  15:     }
  16:     public ActionResult ArticleCompleted(string content)
  17:     {
  18:         return Content(content);
  19:     }
  20: }

对于以XxxAsync/XxxCompleted形式定义的异步Action方法来说，ASP.NET MVC并不会以异步的方式来调用XxxAsync方法，所以我们需要在该方法中自定义实现异步操作的执行。在上面定义的ArticleAsync方法中，我们是通过基于Task的并行编程方式来实现对文章内容的异步读取的。当我们以XxxAsync/XxxCompleted形式定义的异步Action方法的时候，会频繁地使用到Controller的AsyncManager属性，该属性返回一个类型为AsyncManager对象，我们将在下面一节对其进行单独讲述。

在上面提供的实例中，我们在异步操作开始和结束的时候调用了AsyncManager的OutstandingOperations属性的Increment和Decrement方法对于ASP.NET MVC发起通知。此外，我们还利用AsyncManager的Parameters属性表示的字典来保存传递给ArticleCompleted方法的参数，参数在字典中的Key（content）与ArticleCompleted的参数名称是匹配的，所以在调用方法ArticleCompleted的时候，通过AsyncManager的Parameters属性指定的参数值将自动作为对应的参数值。

Task返回值

如果采用上面的异步Action定义方式，意味着我们不得不为一个Action定义两个方法，实际上我们可以通过一个方法来完成对异步Action的定义，那就是让Action方法返回一个代表异步操作的Task对象。上面通过XxxAsync/XxxCompleted形式定义的异步Action可以采用如下的定义方式。

   1: public class HomeController : AsyncController
   2: {
   3:     public Task<ActionResult> Article(string name)
   4:     {
   5:         return Task.Factory.StartNew(() =>
   6:             {
   7:                 string path = ControllerContext.HttpContext.Server.MapPath(string.Format(@"\articles\{0}.html", name));
   8:                 using (StreamReader reader = new StreamReader(path))
   9:                 {
  10:                     AsyncManager.Parameters["content"] = reader.ReadToEnd();
  11:                 }
  12:             }).ContinueWith<ActionResult>(task =>
  13:                 {
  14:                     string content = (string)AsyncManager.Parameters["content"];
  15:                     return Content(content);
  16:                 });
  17:     }
  18: }

上面定义的异步Action方法Article的返回类型为Task<ActionResult>，我们将异步文件内容的读取体现在返回的Task对象中。对文件内容呈现的回调操作则通过调用该Task对象的ContinueWith<ActionResult>方法进行注册，该操作会在异步操作完成之后被自动调用。

如上面的代码片断所示，我们依然利用AsyncManager的Parameters属性实现参数在异步操作和回调操作之间的传递。其实我们也可以使用Task对象的Result属性来实现相同的功能，Article方法的定义也改写成如下的形式。

   1: public class HomeController : AsyncController
   2: {
   3:     public Task<ActionResult> Article(string name)
   4:     {
   5:         return Task.Factory.StartNew(() =>
   6:             {
   7:                 string path = ControllerContext.HttpContext.Server.MapPath(string.Format(@"\articles\{0}.html", name));
   8:                 using (StreamReader reader = new StreamReader(path))
   9:                 {
  10:                     return reader.ReadToEnd();
  11:                 }
  12:             }).ContinueWith<ActionResult>(task =>
  13:                 {                    
  14:                     return Content((string)task.Result);
  15:                 });
  16:     }
  17: }

三、AsyncManager

在上面演示的异步Action的定义中，我们通过AsyncManager实现了两个基本的功能，即在异步操作和回调操作之间传递参数和向ASP.NET MVC发送异步操作开始和结束的通知。由于AsyncManager在异步Action场景中具有重要的作用，我们有必要对其进行单独介绍，下面是AsyncManager的定义。

   1: public class AsyncManager
   2: {   
   3:     public AsyncManager();
   4:     public AsyncManager(SynchronizationContext syncContext);
   5:  
   6:     public EventHandler Finished;
   7:  
   8:     public virtual void Finish();
   9:     public virtual void Sync(Action action);
  10:     
  11:     public OperationCounter OutstandingOperations { get; }
  12:     public IDictionary<string, object> Parameters { get; }
  13:     public int Timeout { get; set; }
  14: }
  15:  
  16: public sealed class OperationCounter
  17: {
  18:     public event EventHandler Completed;    
  19:     
  20:     public int Increment();
  21:     public int Increment(int value);
  22:     public int Decrement();
  23:     public int Decrement(int value);
  24:     
  25:     public int Count { get; }
  26: }

如上面的代码片断所示，AsyncManager具有两个构造函数重载，非默认构造函数接受一个表示同步上下文的SynchronizationContext对象作为参数。如果指定的同步上下文对象为Null，并且当前的同步上下文（通过SynchronizationContext的静态属性Current表示）存在，则使用该上下文；否则创建一个新的同步上下文。该同步上下文用于Sync方法的执行，也就是说在该方法指定的Action委托将会在该同步上下文中以同步的方式执行。

AsyncManager的核心是通过属性OutstandingOperations表示的正在进行的异步操作计数器，该属性是一个类型为OperationCounter的对象。操作计数通过只读属性Count表示，当我们开始和完成异步操作的时候分别调用Increment和Decrement方法作增加和介绍计数操作。Increment和Decrement各自具有两个重载，作为整数参数value（该参数值可以是负数）表示增加或者减少的数值，如果调用无参方法，增加或者减少的数值为1。如果我们需要同时执行多个异步操作，则可以通过如下的方法来操作计数器。

   1: AsyncManager.OutstandingOperations.Increment(3);
   2:  
   3: Task.Factory.StartNew(() =>
   4: {
   5:     //异步操作1
   6:     AsyncManager.OutstandingOperations.Decrement();
   7: });
   8: Task.Factory.StartNew(() =>
   9: {
  10:     //异步操作2
  11:     AsyncManager.OutstandingOperations.Decrement();
  12: });
  13: Task.Factory.StartNew(() =>
  14: {
  15:     //异步操作3
  16:     AsyncManager.OutstandingOperations.Decrement();
  17: });

对于每次通过Increment和Decrement方法调用引起的计数数值的改变，OperationCounter对象都会检验当前计数数值是否为零，如果则表明所有的操作运行完毕，如果预先注册了Completed事件，该事件会被触发。值得一提的时候，表明所有操作完成执行的标志是计数器的值等于零，而不是小于零，如果我们通过调用Increment和Decrement方法使计数器的值称为一个负数，注册的Completed事件是不会被触发的。

AsyncManager在初始化的时候就注册了通过属性OutstandingOperations表示的OperationCounter对象的Completed事件，使该事件触发的时候调用自身的Finish方法。而虚方法Finish在AsyncManager中的默认实现又会触发自身的Finished事件。

如下面的代码片断所示，Controller类实现了IAsyncManagerContainer接口，而后者定义了一个只读属性AsyncManager用于提供辅助执行异步Action的AsyncManager对象，而我们在定义异步Action方法是使用的AsyncManager对象就是从抽象类Controller中集成下来的AsyncManager属性。

   1: public abstract class Controller : ControllerBase, IAsyncManagerContainer,...
   2: {
   3:     public AsyncManager AsyncManager { get; }
   4: }
   5:  
   6: public interface IAsyncManagerContainer
   7: {    
   8:     AsyncManager AsyncManager { get; }
   9: }

四、Completed方法的执行

对于通过XxxAsync/XxxCompleted形式定义的异步Action，我们说回调操作XxxCompleted会在定义在XxxAsync方法中的异步操作执行结束之后被自动调用，那么XxxCompleted方法具体是如何被执行的呢？

异步Action的执行最终是通过描述该Action的AsyncActionDescriptor对象的BeginExecute/EndExecute方法来完成的。通过之前“Model的绑定”的介绍我们知道通过XxxAsync/XxxCompleted形式定义的异步Action通过一个ReflectedAsyncActionDescriptor对象来表示的，ReflectedAsyncActionDescriptor在执行BeginExecute方法的时候会注册Controller对象的AsyncManager的Finished事件，使该事件触发的时候去执行Completed方法。

也就是说针对当前Controller的AsyncManager的Finished事件的触发标志着异步操作的结束，而此时匹配的Completed方法会被执行。由于AsyncManager的Finish方法会主动触发该事件，所以我们可以通过调用该方法使Completed方法立即执行。由于AsyncManager的OperationCounter对象的Completed事件触发的时候会调用Finish方法，所以当表示当前正在执行的异步操作计算器的值为零时，Completed方法也会自动被执行。

如果我们在XxxAsync方法中通过如下的方式同时执行三个异步操作，并在每个操作完成之后调用AsyncManager的Finish方法，意味着最先完成的异步操作会导致XxxCompleted方法的执行。换句话说，当XxxCompleted方法执行的时候，可能还有两个异步操作正在执行。

   1: AsyncManager.OutstandingOperations.Increment(3);
   2:  
   3: Task.Factory.StartNew(() =>
   4: {
   5:     //异步操作1
   6:     AsyncManager.Finish();
   7: });
   8: Task.Factory.StartNew(() =>
   9: {
  10:     //异步操作2
  11:     AsyncManager.Finish();
  12: });
  13: Task.Factory.StartNew(() =>
  14: {
  15:     //异步操作3
  16:     AsyncManager.Finish();
  17: });

如果完全通过为完成的异步操作计数机制来控制XxxCompleted方法的执行，由于计数的检测和Completed事件的触发只发生在OperationCounter的Increment/Decrement方法被执行的时候，如果我们在开始和结束异步操作的时候都没有调用这两个方法，XxxCompleted是否会执行呢？同样以之前定义的用语读取/显示文章内容的异步Action为例，我们按照如下的方式将定义在ArticleAsync方法中针对AsyncManager的OutstandingOperations属性的Increment和Decrement方法调用注释调用，ArticleCompleted方法是否还能正常运行呢？

   1: public class HomeController : AsyncController
   2: {
   3:     public void ArticleAsync(string name)
   4:     {
   5:         //AsyncManager.OutstandingOperations.Increment();
   6:         Task.Factory.StartNew(() =>
   7:             {
   8:                 string path = ControllerContext.HttpContext.Server.MapPath(string.Format(@"\articles\{0}.html", name));
   9:                 using (StreamReader reader = new StreamReader(path))
  10:                 {
  11:                     AsyncManager.Parameters["content"] = reader.ReadToEnd();
  12:                 }
  13:                 //AsyncManager.OutstandingOperations.Decrement();
  14:             });
  15:     }
  16:     public ActionResult ArticleCompleted(string content)
  17:     {
  18:         return Content(content);
  19:     }
  20: }

实际上ArticleCompleted依然会被执行，但是这样我们就不能确保正常读取文章内容，因为ArticleCompleted方法会在ArticleAsync方法执行之后被立即执行。如果文章内容读取是一个相对耗时的操作，表示文章内容的ArticleCompleted方法的content参数在执行的时候尚未被初始化。在这种情况下的ArticleCompleted是如何被执行的呢？

原因和简单，ReflectedAsyncActionDescriptor的BeginExecute方法在执行XxxAsync方法的前后会分别调用AsyncManager的OutstandingOperations属性的Increment和Decrement方法。对于我们给出的例子来说，在执行ArticleAsync之前Increment方法被调用使计算器的值变成1，随后ArticleAsync被执行，由于该方法以异步的方式读取指定的文件内容，所以会立即返回。最后Decrement方法被执行使计数器的值变成0，AsyncManager的Completed事件被触发并导致ArticleCompleted方法的执行。而此时，文件内容的读取正在进行之中，表示文章内容的content参数自然尚未被初始化。

ReflectedAsyncActionDescriptor这样的执行机制也对我们使用AsyncManager提出了要求，那就是对尚未完成的一步操作计数器的增加操作不应该发生在异步线程中，如下所示的针对AsyncManager的OutstandingOperations属性的Increment方法的定义是不对的。

   1: public class HomeController : AsyncController
   2: {
   3:     public void XxxAsync(string name)
   4:     {
   5:         Task.Factory.StartNew(() =>
   6:             {
   7:                 AsyncManager.OutstandingOperations.Increment()；
   8:                   //...
   9:                   AsyncManager.OutstandingOperations.Decrement();
  10:             });
  11:     }
  12:     //其他成员
  13: }

下面采用正确的定义方法：

   1: public class HomeController : AsyncController
   2: {
   3:     public void XxxAsync(string name)
   4:    {
   5:        AsyncManager.OutstandingOperations.Increment()；
   6:         Task.Factory.StartNew(() =>
   7:             {
   8:                 //...
   9:                 AsyncManager.OutstandingOperations.Decrement();
  10:             });
  11:     }
  12:     //其他成员
  13: }

最后再强调一点，不论是显式调用AsyncManager的Finish方法，还是通过调用AsyncManager的OutstandingOperations属性的Increment方法是计数器的值变成零，仅仅是让XxxCompleted方法得以执行，并不能真正阻止异步操作的执行。

五、异步操作的超时控制

异步操作虽然适合那些相对耗时的I/O绑定型操作，但是也并不说对一步操作执行的时间没有限制。异步超时时限通过AsyncManager的整型属性Timeout表示，它表示超时时限的总毫秒数，其默认值为45000（45秒）。如果将Timeout属性设置为-1，意味着异步操作执行不再具有任何时间的限制。对于以XxxAsync/XxxCompleted形式定义的异步Action来说，如果XxxAsync执行之后，在规定的超时时限中XxxCompleted没有得到执行，一个TimeoutException会被抛出来。

如果我们以返回类型为Task的形式定义异步Action，通过Task体现的异步操作的执行时间不受AsyncManager的Timeout属性的限制。我们通过如下的代码定义了一个名为Data的异步Action方法以异步的方式获取作为Model的数据并通过默认的View呈现出来，但是异步操作中具有一个无限循环，当我们访问该Data方法时，异步操作将会无限制地执行下去，也不会有TimeoutException异常发生。

   1: public class HomeController : AsyncController
   2: {
   3:     public Task<ActionResult> Data()
   4:     {
   5:         return Task.Factory.StartNew(() =>
   6:         {
   7:             while (true)
   8:             { }
   9:             return GetModel();
  10:                 
  11:         }).ContinueWith<ActionResult>(task =>
  12:         {
  13:             object model = task.Result;
  14:             return View(task.Result);
  15:         });
  16:     }
  17:     //其他成员
  18: }

在ASP.NET MVC应用编程接口中具有两个特殊的特性用于定制异步操作执行的超时时限，它们是具有如下定义的AsyncTimeoutAttribute和NoAsyncTimeoutAttribute，均定义在命名空间System.Web.Mvc下。

   1: [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited=true, AllowMultiple=false)]
   2: public class AsyncTimeoutAttribute : ActionFilterAttribute
   3: {
   4:     
   5:     public AsyncTimeoutAttribute(int duration);
   6:     public override void OnActionExecuting(ActionExecutingContext filterContext);    
   7:     public int Duration { get; }
   8: }
   9:  
  10: [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited=true, AllowMultiple=false)]
  11: public sealed class NoAsyncTimeoutAttribute : AsyncTimeoutAttribute
  12: {
  13:     // Methods
  14:     public NoAsyncTimeoutAttribute() : base(-1)
  15:     {
  16:     }
  17: }

从上面给出的定义我们可以看出这两个特性均是ActionFilter。AsyncTimeoutAttribute的构造函数接受一个表示超时时限（以毫秒为单位）的整数作为其参数，它通过重写OnActionExecuting方法将指定的超时时限设置给当前Controller的AsyncManager的Timeout属性进行。NoAsyncTimeoutAttribute是AsyncTimeoutAttribute的继承者，它将超时时限设置为-1，意味着它解除了对超时的限制。

从应用在这两个特性的AttributeUsageAttribute定义可看出，它们既可以应用于类也可以用于也方法，意味着我们可以将它们应用到Controller类型或者异步Action方法（仅对XxxAsync方法有效，不能应用到XxxCompleted方法上）。如果我们将它们同时应用到Controller类和Action方法上，针对方法级别的特性无疑具有更高的优先级。

时间： 2024-10-06 07:56:10

ASP.NET MVC下的异步Action的定义和执行原理[转]的相关文章

ASP.NET MVC下的异步Action的定义和执行原理

Visual Studio提供的Controller创建向导默认为我们创建一个继承自抽象类Controller的Controller类型,这样的Controller只能定义同步Action方法.如果我们需要定义异步Action方法,必须继承抽象类AsyncController.这篇问你讲述两种不同的异步Action的定义方法和底层执行原理.[本文已经同步到<How ASP.NET MVC Works?>中] 目录 一.基于线程池的请求处理 二.两种异步Action方法的定义     XxxAs

在 ASP.NET MVC 中使用异步控制器

线程池 一直想把项目改写成异步,但是ASP.NETMVC3下写的过于繁琐,.NET 4.5与ASP.NET MVC下代码写起来就比较简单了, MS好像也一直喜欢这样搞,每一个成熟的东西,都要演变好几个版本,才能趋于规范. ASP.NET MVC 中为什么需要使用异步呢,IIS有一个线程池来处理用户的请求,当一个新的请求过来时,将调度池中的线程以处理该请求,然而,但并发量很高的情况下,池中的线程已经不能够满足这么多的请求时候,池中的每一个线程都处于忙的状态则在处理请求时将阻塞处理请求的线程,并且该

ASP.NET mvc下在Controller下action的跳转方式

在ASP.NET mvc下,action有多种挑战方式: return RedirectToAction("Index");//一个参数时在本Controller下 如果RedirectToAction(ActionName,ControllerName) //可以直接跳到别的Controller. return RedirectToRoute(new {controller="Home",action="Index"});//可跳到其他cont

ASP.NET MVC中使用异步控制器

线程池 一直想把项目改写成异步,但是ASP.NETMVC3下写的过于繁琐,.NET 4.5与ASP.NET MVC下代码写起来就比较简单了, MS好像也一直喜欢这样搞,每一个成熟的东西,都要演变好几个版本,才能趋于规范. ASP.NET MVC 中为什么需要使用异步呢,IIS有一个线程池来处理用户的请求,当一个新的请求过来时,将调度池中的线程以处理该请求,然而,但并发量很高的情况下,池中的线程已经不能够满足这么多的请求时候,池中的每一个线程都处于忙的状态则在处理请求时将阻塞处理请求的线程,并且该

ASP.NET MVC下的四种验证编程方式

原文:ASP.NET MVC下的四种验证编程方式 ASP.NET MVC采用Model绑定为目标Action生成了相应的参数列表,但是在真正执行目标Action方法之前,还需要对绑定的参数实施验证以确保其有效性,我们将针对参数的验证成为Model绑定.总地来说,我们可以采用4种不同的编程模式来进行针对绑定参数的验证. 目录 一.手工验证绑定的参数 二.使用ValidationAttribute特性 三.让数据类型实现IValidatableObject接口 四.让数据类型实现IDataError

ASP.NET MVC下的四种验证编程方式【转】

ASP.NET MVC采用Model绑定为目标Action生成了相应的参数列表,但是在真正执行目标Action方法之前,还需要对绑定的参数实施验证以确保其有效 性,我们将针对参数的验证成为Model绑定.总地来说,我们可以采用4种不同的编程模式来进行针对绑定参数的验证. 目录 一.手工验证绑定的参数 二.使用ValidationAttribute特性 三.让数据类型实现IValidatableObject接口 四.让数据类型实现IDataErrorInfo接口 一.手工验证绑定的参数 在 定义具

在ASP.NET MVC下通过短信验证码注册

以前发短信使用过短信猫,现在,更多地是使用第三方API.大致过程是: → 用户在页面输入手机号码→ 用户点击"获取验证码"按钮,把手机号码发送给服务端,服务端产生几位数的随机码,并保存在某个地方(Session, Applicaiton, 数据库, 等等),调用第三方的API→ 第三方发送几位数的随机码至用户手机→ 用户在页面输入接收到的随机码→ 把随机码等发送给服务端,与服务端保存的随机码比较,如果一致,就通过,让注册 就按如下界面来说吧: 我们需要考虑的方面包括: ● 手机号码:判

在ASP.NET MVC下有关上传图片脏数据的解决方案

在"在ASP.NET MVC下实现单个图片上传, 客户端服务端双重限制图片大小和格式, 服务端裁剪图片"中,已经实现了在客户端和服务端限制图片大小和格式,以及在服务端裁剪图片.但还有一个重要的话题是需要面对的,那就是图片脏数据问题. 假设用户添加产品信息,并且上传了图片,可之后用户没有点击页面上的添加按钮,这就导致上传图片成为"脏数据",存在着却一直不会被使用.解决这个问题的大致思路是: ○ 在上传图片的时候,把图片保存到一个临时文件夹,或者叫缓存文件夹○ 当用户真

ASP.NET MVC下的四种验证编程方式[续篇]

在<ASP.NET MVC下的四种验证编程方式>一文中我们介绍了ASP.NET MVC支持的四种服务端验证的编程方式("手工验证"."标注ValidationAttribute特性"."让数据类型实现IValidatableObject或者IDataErrorInfo"),那么在ASP.NET MVC框架内部是如何提供针对这四种不同编程方式的支持的呢?接下来我们就来聊聊这背后的故事. 一.ModelValidator与ModelVal