Controller 和 Action (2)
继上一篇文章之后，本文将介绍 Controller 和 Action 的一些较高级特性，包括 Controller Factory、Action Invoker 和异步 Controller 等内容。
本文目录
开篇：示例准备
文章开始之前，我们先来了解一下一个请求的发出到Action方法处理后返回结果的流程，请试着理解下图：
本文的重点是 controller factory 和 action invoker。顾名思义，controller factory 的作用是创建为请求提供服务的Controller实例；action invoker 的作用是寻找并调用Action方法。MVC框架为这两者都提供了默认的实现，我们也可以对其进行自定义。
首先我们为本文要演示的示例做一些准备，把暂时想到的要用的 View、Controller 和 Action 都创建好。新建一个空的MVC应用程序，在Models文件夹中添加一个名为 Result 的Model，代码如下：
namespace MvcApplication2.Models {
public class Result {
public string ControllerName { get; set; }
public string ActionName { get; set; }
}
}
在 /Views/Shared 文件夹下添加一个名为 Result.cshtml 的视图(不使用Layout)，添加代码如下：
...
<body>
<div>Controller: @Model.ControllerName</div>
<div>Action: @Model.ActionName</div>
</body>
本文的所有Action方法将都使用这同一个View，目的是显示被执行的Controller名称和Action名称。
然后我们创建一个名为Product的Controller，代码如下：
public class ProductController : Controller {
public ViewResult Index() {
return View("Result", new Result {
ControllerName = "Product",
ActionName = "Index"
});
}
public ViewResult List() {
return View("Result", new Result {
ControllerName = "Product",
ActionName = "List"
});
}
}
继续添加一个名为Customer的Controller，代码如下：
public class CustomerController : Controller {
public ViewResult Index() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "Index"
});
}
public ViewResult List() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "List"
});
}
}
准备工作做好了，开始进入正题吧。
自定义 Controller Factory
Controller Factory，顾名思义，它就是创建 controller 实例的地方。想更好的理解Controller Factory是如何工作的，最好的方法就是自己去实现一个自定义的。当然，在实际的项目中我们很少会去自己实现，一般使用内置的，这里只是为了演示它在MVC框架中是如何工作的。自定义一个Controller Factory需要实现 IControllerFactory 接口，这个接口的定义如下：
using System.Web.Routing;
using System.Web.SessionState; namespace System.Web.Mvc {
public interface IControllerFactory {
IController CreateController(RequestContext requestContext, string controllerName);
SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName);
void ReleaseController(IController controller);
}
}
我们创建一个名为 Infrastructure 文件夹，在这个文件夹中创建一个名为 CustomControllerFactory 的类文件，在这个类中我们将简单的实现 IControllerFactory 接口的每个方法，代码如下：
using System;
using System.Web.Mvc;
using System.Web.Routing;
using System.Web.SessionState;
using MvcApplication2.Controllers; namespace MvcApplication2.Infrastructure {
public class CustomControllerFactory : IControllerFactory { public IController CreateController(RequestContext requestContext, string controllerName) {
Type targetType = null;
switch (controllerName) {
case "Product":
targetType = typeof(ProductController);
break;
case "Customer":
targetType = typeof(CustomerController);
break;
default:
requestContext.RouteData.Values["controller"] = "Product";
targetType = typeof(ProductController);
break;
}
return targetType == null ? null : (IController)DependencyResolver.Current.GetService(targetType);
} public SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName) {
return SessionStateBehavior.Default;
} public void ReleaseController(IController controller) {
IDisposable disposable = controller as IDisposable;
if (disposable != null) {
disposable.Dispose();
}
}
}
}
先来分析一下这个类。
这里最重要的方法是 CreateController，当MVC框架需要一个 Controller 来处理请求时调用该方法。它有两个参数，一个是 RequestContext 对象，通过它我们可以得到请求相关的信息；第二个参数是一个string类型的controller名称，它的值来自于URL。这里我们只创建了两个Controller，所以我们在 CreateController 方法中进行了硬编码(写死了controller的名称)，CreateController 方法的目的是创建Controller实例。我们不推荐自定义Controller Factory，原因之一是它是一个很复杂的过程，你需要通过反射动态地定位到正确的Controller，还要处理一些像不同命名空间下同名的Controller歧义和创建Controller实例有什么样的构造函等数潜在问题。
在自定义的Cotroller Factory中，我们可以任意改变系统默认的行为，比如switch语句中的default节点：
requestContext.RouteData.Values["controller"] = "Product";
它将路由的controller值改为Product，使得执行的cotroller并不是用户所请求的controller。
在本系列的 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 文章中也讲了一个用Ninject创建Controller Factory的例子，使用的是 ninjectKernel.Get(controllerType) 方法来创建Controller实例。这里我们使用框架提供的 DependencyResolver 类来创建：
return targetType == null ? null : (IController)DependencyResolver.Current.GetService(targetType);
静态的DependencyResolver.Current属性返回一个IDependencyResolver接口的实现，这个实现中定义了 GetService 方法，它根据 System.Type 对象(targetType)参数自动为我们创建 targetType 实例，和使用Ninject类似。
最后来看看实现 IControllerFactory 接口的另外两个方法。
GetControllerSessionBehavior 方法，告诉MVC框架是否保留Session数据，这点放在文章后面讲。
ReleaseController 方法，当controller对象不再需要时被调用，这里我们判断controller对象是否实现了IDisposable接口，实现了则调用Dispose方法来释放资源。
CustomControllerFactory 类分析完了，和 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 讲的一样，要使用自定义的Controller Factory还需要在 Global.asax.cs 文件的 Application_Start 方法中对自定义的 CustomControllerFactory 类进注册，如下：
protected void Application_Start() {
...
ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory());
}
运行程序，应用程序根据路由设置的默认值显示如下：
你可以定位到/xxx/xxx乱七八糟的URL来验证Controller实例是否是自定的Controller Factory创建的。
使用内置的 Controller Factory
为了帮助理解Controller Factory是如何工作，我们通过实现IControllerFactory接口自定义了一个Controller Factory。对于实现的项目来说，我们一般不会这么做，大多数情况我们使用内置的Controller Factory，叫 DefaultControllerFactory。当它从路由系统接收到一个请求，它从路由实例中找到controller名称的值，然后根据名称找到controller类，这个类必须满足下面几个标准：
- 必须是public。
- 必须是具体的类(非抽象类)。
- 没有泛型参数。
- 类的名称必须以Controller结尾。
- 类必须（间接或直接）实现IController接口。
DefaultControllerFactory类维护了一个满足以上标准的类的列表，这样当每次接收到一个请求时不需要再去搜索一遍。当它找到了合适的Controller类，则使用Controller Activator(一会介绍)来创建Controller类的实例。它内部是通过DependencyResolver类进行依赖解析创建Controller的，和使用Ninject是类似的原理。
你可以通过继承DefaultControllerFactory类重写其中默认的方法来自定义创建 controller 的过程，下面是三个可以被重写的方法：
- GetControllerType，返回Type类型，为请求匹配对应的Controller类，用上面定义的标准来筛选Controller类也是在这里执行的。
- GetControllerInstance，返回是IController类型，作用是创建指定的类型的实例。
- CreateController 方法，返回是IController类型，它是IControllerFactory接口的CreateController方法的实现。默认情况下，它调用 GetControllerType 方法来决定哪个类需要被实例化，然后把Controller对象传递给GetControllerInstance。
重写GetControllerInstance方法，可以实现对创建Controller实例进行加工，最常见的是进行依赖注入。
在本系列的 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 文章中的示例就是一个对 GetControllerInstance 方法进行重写的完整示例，在这就不重复演示了。
现在我们知道 DefaultControllerFactory 通过 GetControllerType 方法拿到 controller 的类型后，它把类型传递给 GetControllerInstance 方法以获取 controller 的实例。那么，GetControllerInstance 又是如何来获取实例的呢？这就需要讲到另外一个controller中的角色了，它就是下面讲的：Controller Activator。
Controller 的激活
当 DefaultControllerFactory 类接收到一个 controller 实例的请求时，在 DefaultControllerFactory 类内部通过 GetControllerType 方法来获得 controller 的类型，然后把这个类型传递给 GetControllerInstance 方法以获得 controller 的实例。
所以在 GetControllerInstance 方法中就需要有某个东西来创建 controller 实例，这个创建的过程就是 controller 被激活的过程。默认情况下 MVC 使用的是 DefaultControllerActivator 类来做这个工作。既然这是默认的情况，那么我们肯定也可进行自定义。创建一个自定义的 Controller Activator 需要实现 IControllerActivator 接口，该接口定义如下：
public interface IControllerActivator {
IController Create(RequestContext requestContext, Type controllerType);
}
它包仅含一个 Create 方法，RequestContext 对象参数用来获取请求相关的信息，Type 类型参数指定了要被实例化的类型。下面我们通过实现这个接口来自定义一个简单的Controller Activator：
public class CustomControllerActivator : IControllerActivator {
public IController Create(RequestContext requestContext, Type controllerType) {
if (controllerType == typeof(ProductController)) {
controllerType = typeof(CustomerController);
}
return (IController)DependencyResolver.Current.GetService(controllerType);
}
}
我们实现 IControllerActivator 的 CustomControllerActivator 非常简单，如果请求的是 ProductController 则我们给它创建 CustomerController 的实例，实际的项目中不会这么做，这里只是为了演示。
为了使用这个自定的 Activator，需要在 Global.asax 文件中的 Application_Start 方法中注册 Controller Factory 时给 Factory 的构造函数传递我们的这个 Activator 的实例，如下：
protected void Application_Start() {
...
ControllerBuilder.Current.SetControllerFactory(new DefaultControllerFactory(new CustomControllerActivator()));
}
运行程序，把URL定位到 /Product ，本来路由将指定到 Product controller， 然后 DefaultControllerFactory 类将请求 Activator 创建一个 ProductController 实例。但我们注册了自义的 Controller Activator，在这个自定义的 Activator 创建 Controller 实例的的时候，我们做了一个“手脚”，改变了这种默认行为。当请求创建 ProductController 实例时，我们给它创建了CustomerController 的实例。结果如下：
其实更多的时候，我们自定义 controller 的激活机制是为了引入IoC，和 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 讲的通过继承 DefaultControllerFactory 引入 IoC 是一个道理。
自定义 Action Invoker
当 Controller Factory 创建好了一个类的实例后，MVC框架则需要一种方式来调用这个实例的 action 方法。如果创建的 controller 是继承 Controller 类的，那么则是由 Action Invoker 来完成调用 action 方法的任务，MVC 默认使用的是 ControllerActionInvoker 类。如果是直接继承 IController 接口的 controller，那么就需要手动来处理 action，见上一篇 [ASP.NET MVC 小牛之路]09 - Controller 和 Action (1) 。下面我们通过自定义一个 Action Invoker 来了解一下 Action Invoker 的运行机制。
创建一个自定义的 Action Invoker 需要实现 IActionInvoker 接口，该接口的定义如下：
public interface IActionInvoker {
bool InvokeAction(ControllerContext controllerContext, string actionName);
}
这个接口只唯一的一个 InvokeAction 方法。ControllerContext 对象参数包含了调用该方法的controller的信息，string类型的参数是要调用的Action方法的名称，这个名称来源于路由系统。返回值为bool类型，当actoin方法被找到并被调用时返回true，否则返回false。
下面是实现了IActionInvoker接口的 CustomActionInvoker 类：
using System.Web.Mvc;
namespace MvcApplication2.Infrastructure {
public class CustomActionInvoker : IActionInvoker {
public bool InvokeAction(ControllerContext controllerContext, string actionName) {
if (actionName == "Index") {
controllerContext.HttpContext.Response.Write("This is output from the Index action");
return true;
}
else {
return false;
}
}
}
}
这个Action Invoker不需要关心实际被调用的Action方法。如果请求的是Index Action，这个 Invoker 通过 Response 直接输出一个消息，如果不是请Index Action，则会引发一个404-未找到错误。
决定Controller使用哪个Action Invoker是由 Controller 中的 Controller.ActionInvoker 属性来决定的，由它来告诉MVC当前的Controller将使用哪个Action Invoker来调用Action方法。如下我们创建一个ActionInvokerController，并在它的构造函数中指定了Action Invoker：
namespace MvcApplication2.Controllers {
public class ActionInvokerController : Controller {
public ActionInvokerController() {
this.ActionInvoker = new CustomActionInvoker();
}
}
}
这个Controller中没有Action方法，它依靠Action Invoker来处理请求，运行程序，将URL定位到 /ActionInvoker/Index 可见如下结果：
如果将URL定位到ActionInvoker下的其他Action，则会返回一个404的错误页面。
我们不推荐去实现自己的Action Invoker。首先内置的Action Invoker提供了一些非常有用的特性；其次是缺乏可扩展性和对View的支持等。这里只是为了演示和理解MVC框架处理请求的又一个过程的细节。
使用内置的 Action Invoker
通过自定义 Action Invoker，我们知道了MVC调用 Action 方法的机制。我们创建一个继承自 Controller 类的 controller，如果不指定Controller.ActionInvoker，那么MVC会使用内置默认的Action Invoker，它是 ControllerActionInvoker 类。它的工作是把请求匹配到对应的 Action 方法并调用之，简单说就是寻找和调用Action方法。
为了让内置的 Action Invoker 能匹配到Action方法，Action方法必须满足下面的标准：
- 必须是公共的（public）。
- 不能是静态的（static）。
- 不能是System.Web.Mvc.Controller中存在的方法，或其他基类中的方法。如方法不能是 ToString 和 GetHashCode 等。
- 不能是一个特殊的名称。所谓特殊的名称是方法名称不能和构造函数、属性或者事件等的名称相同。
注意，Action方法也不能带有泛型，如MyMethod<T>()，虽然Action Invoker能匹配到，但会抛出异常。
内置的 Action Invoker 给我们提供了很多实用的特性，给开发带来很大便利，下面两节内容可以说明这一点。
给 Action 方法定义别名
默认情况下，内置的Action Invoker (ControllerActionInvoker)寻找的是和请求的 action 名称相同的 action 方法。比如路由系统提供的 action 值是 Index，那么 ControllerActionInvoker 将寻找一个名为 Index 的方法，如果找到了，它就用这个方法来处理请求。ControllerActionInvoker 允许我们对此行为进行调整，即可以通过使用 ActionName 特性对 action 使用别名，如下对 CustomerController 的 List action 方法使用 ActionName 特性：
public class CustomerController : Controller {
...
[ActionName("Enumerate")]
public ViewResult List() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "List"
});
}
}
当请求 Enumerate Action 时，将会使用 List 方法来处理请求。下面是请求 /Customer/Enumerate 的结果：
这时候对 /Customer/List 的请求则会无效，报“找不到资源”的错误，如下：
使用 Action 方法别名有两个好处：一是可以使用对于方法名来说是非法的名称来作为请求的action名，如 [ActionName("User-Registration")]。二是，如果你有两个不同的方法，相同的参数相同的名称，但针对不同的HTTP请求（一个使用 [HttpGet]，另一个使用 [HttpPost]），你可以给这两个方法不同的方法名，然后使用 [ActionName] 来指定相同的 action 请求名称。
Action 方法选择器
我们经常会在 controller 中对多个 action 方法使用同一个方法名。在这种情况下，我们就需要告诉 MVC 怎样在相同的方法名中选择正确的 action 方法来处理请求。这个机制称为 Action 方法选择，它在基于识别方法名称的基础上，允许通过请求的类型来选择 action 方法。MVC 框架可使用C#特性来做到这一点，所以这种作用的特性可以称为 Action 方法选择器。
内置 Action 方法选择器
MVC提供了几种内置的特性来支持 Action 方法选择，它包括HttpGet、HttpPost、HttpPut 和 NonAction 等。这些选择器从名字上很容易理解什么意思，这里就不解释了。下面举个 NonAction 的例子。在 CustomerController 中添加一个 MyAction 方法，然后应用 [NonAction] 特性，如下：
public class CustomerController : Controller {
...
[NonAction]
public ActionResult MyAction() {
return View();
}
}
使用 [NonAction] 后，方法将不会被识别为 action 方法，如下是请求 /Customer/MyAction 的结果：
当然我们也可以通过把方法声明为 private 来告诉MVC它不是一个 action 方法。
自定义 Action 方法选择器
除了使用内置的Action方法选择器外，我们也可以自定义。所有的 action 选择器都继承自 ActionMethodSelectorAttribute 类，这个类的定义如下：
using System.Reflection;
namespace System.Web.Mvc {
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public abstract class ActionMethodSelectorAttribute : Attribute {
public abstract bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo);
}
}
它是一个抽象类，只有一个抽象方法：IsValidForRequest。通过重写这个方法，可以判断某个请求是否允许调用 Action 方法。
我们来考虑这样一种情况：同一个URL请求，在本地和远程请求的是不同的 action （如对于本地则绕过权限验证可能需要这么做）。那么自定义一个本地的 Action 选择器会是一个不错的选择。下面我们来实现这样一个功能的 Action 选择器：
using System.Reflection;
using System.Web.Mvc; namespace MvcApplication2.Infrastructure {
public class LocalAttribute : ActionMethodSelectorAttribute {
public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo) {
return controllerContext.HttpContext.Request.IsLocal;
}
}
}
修改 CustomerController，添加一个LocalIndex 方法，并对它应用 “Index”别名，代码如下：
public class CustomerController : Controller {
public ViewResult Index() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "Index"
});
}
[ActionName("Index")]
public ViewResult LocalIndex() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "LocalIndex"
});
}
...
}
这时如果请求 /Customer/Index，这两个 action 方法都会被匹配到而引发歧义问题，程序将会报错：
这时候我们再对 LocalIndex 应用我们自定义的 Local 选择器：
...
[Local]
[ActionName("Index")]
public ViewResult LocalIndex() {
return View("Result", new Result {
ControllerName = "Customer",
ActionName = "Index"
});
}
...
程序在本地运行的时候则会匹配到 LocalIndex action方法，结果如下：
通过这个例子我们也发现，定义了选择器特性的Action方法被匹配的优先级要高于没有定义选择器特性的Action方法。
异步 Controller
对于 ASP.NET 的工作平台 IIS，它维护了一个.NET线程池用来处理客户端请求。这个线程池称为工作线程池(worker thread pool)，其中的线程称为工作线程(worker threads)。当接收到一个客户端请求，一个工作线程从工作线程池中被唤醒并处理接收到的请求。当请求被处理完了后，工作线程又被这个线程池回收。这种线程程池的机制对ASP.NET应用程序有如下两个好处：
- 通过线程的重复利用，避免了每次接收到一个新的请求就创建一个新的线程。
- 线程池维护的线程数是固定的，这样线程不会被无限制地创建，减少了服务器崩溃的风险。
一个请求是对应一个工作线程，如果MVC中的action对请求处理的时间很短暂，那么工作线程很快就会被线程池收回以备重用。但如果执行action的工作线程需要调用其他服务（如调用远程的服务，数据的导入导出），这个服务可能需要花很长时间来完成任务，那么这个工作线程将会一直等待下去，直到调用的服务返回才继续工作。这个工作线程在等待的过程中什么也没做，资源浪费了。设想一下，如果这样的action一多，所有的工作线程都处于等待状态，大家都没事做，而新的请求来了又没人理，这样就陷入了尴尬境地。
解决这个问题需要使用异步(asynchronous) Controller，异步Controller允许工作线程在等待(await)的时候去处理别的请求，这样做减少了资源浪费，有效提高了服务器的性能。
使用异步 Controller 需要用到.NET 4.5的新特性：异步方法。异步方法有两个新的关键字：await 和 async。这个新知识点朋友们自己去网上找找资料看吧，这里就不讲了，我们把重点放在MVC中的异步 Controller 上。
在Models文件夹中添加一个 RemoteService 类，代码如下：
using System.Threading;
using System.Threading.Tasks; namespace MvcApplication2.Models { public class RemoteService { public async Task<string> GetRemoteDataAsync() {
return await Task<string>.Factory.StartNew(() => {
Thread.Sleep(2000);
return "Hello from the other side of the world";
});
}
}
}
然后创建一个名为 RemoteData 的 Controller，让它继承自 AsyncController 类，代码如下：
using System.Web.Mvc;
using MvcApplication2.Models;
using System.Threading.Tasks; namespace MvcApplication2.Controllers {
public class RemoteDataController : AsyncController {
public async Task<ActionResult> Data() { string data = await new RemoteService().GetRemoteDataAsync();
Response.Write(data); return View("Result", new Result {
ControllerName = "RemoteData",
ActionName = "Data"
});
}
}
}
运行程序，URL 定位到 /RemoteData/Data，2秒后将显示如下结果：
当请求 /RemoteData/Data 时，Data 方法开始执行。当执行到下面代码调用远程服务时：
string data = await new RemoteService().GetRemoteDataAsync();
工作线程开始处于等待状态，在等待过程中它可能被派去处理新的客户端请求。当远程服务返回结果了，工作线程再回来处理后面的代码。这种异步机制避免了工作线程处于闲等状态，尽可能的利用已被激活的线程资源，对提高MVC应用程序性能是很有帮助的。
PS：这篇文章写到一半便在草稿箱中沉睡了一个多月，10月份20多天都在内蒙出差，回来都没什么兴致继续写下去。希望朋友们多多支持，让我有动力把这个系列写完。
Controller 和 Action (2)的更多相关文章
-
实现MVC自定义过滤器，自定义Area过滤器，自定义Controller，Action甚至是ViewData过滤器
MVC开发中几种以AOP方式实现的Filters是非常好用的,默认情况下,我们通过App_Start中的FilterConfig来实现的过滤器注册是全局的,也就是整个应用程序都会使用的,针对单独的Fi ...
-
解读ASP.NET 5 &; MVC6系列（10）：Controller与Action
我们知道在MVC5和之前的版本,两个框架的生命周期是不一样的,在新版MVC6中,MVC Controller/Web API Controller已经合二为一了,本章我们主要讲解Controller和 ...
-
[ASP.NET MVC 小牛之路]09 - Controller 和 Action (1)
我们知道,在 MVC 中每个请求都会提交到 Controller 进行处理.Controller 是和请求密切相关的,它包含了对请求的逻辑处理,能对 Model 进行操作并选择 View 呈现给用户, ...
-
[ASP.NET MVC 小牛之路]10 - Controller 和 Action (2)
继上一篇文章之后,本文将介绍 Controller 和 Action 的一些较高级特性,包括 Controller Factory.Action Invoker 和异步 Controller 等内容. ...
-
在ASP.NET MVC 中获取当前URL、controller、action
一.URL的获取很简单,ASP.NET通用: [1]获取 完整url (协议名+域名+虚拟目录名+文件名+参数) string url=Request.Url.ToString(); [2]获取 虚拟 ...
-
Asp.Net_Mvc_获取当前Url、Controller、Action
一.URL的获取很简单,ASP.NET通用: [1]获取 完整url (协议名+域名+虚拟目录名+文件名+参数) string url=Request.Url.ToString(); [2]获取 虚拟 ...
-
004. Asp.Net Routing与MVC 之二： 请求如何激活Controller和Action
上篇讲到 请求到达 MvcRouteHandler ,并且透过 IRouteHandler.GetHttpHandler 获取到了真正的处理程序 MvcHandler 这次我们看看,MvcHandle ...
-
[译] ASP.NET MVC 6 attribute routing – the [controller] and [action] tokens
原文:http://www.strathweb.com/2015/01/asp-net-mvc-6-attribute-routing-controller-action-tokens/ 当在Web ...
-
Yii里获取当前controller和action的id
Yii里获取当前controller和action的id 在控制器里$name = $this->getId(); // controller$name = $action->id; ...
-
C# mvc中为Controller或Action添加定制特性实现登录验证
在本文开始前,先简单讲两个知识点: 1.每个action执行前都会先执行OnActionExecuting方法: 2.FCL提供了多种方式来检测特性的存在,比如IsDefined.GetCustomA ...
随机推荐
-
Redis的持久化的两种方式drbd以及aof日志方式
redis的持久化配置: 主要包括两种方式:1.快照 2 日志 来看一下redis的rdb的配置选项和它的工作原理: save 900 1 // 表示的是900s内,有1条写入,则产生快照 save ...
-
webpack 教程 那些事儿06-gulp+webpack多页
本篇主要讲述用gulp+webpack构建多页应用 折腾到现在,项目还必须要进行,.vue文件必须要加载,也就是webpack必须引入.时间不多了,抛弃上个方案之后,只能牺牲热加载性能,用gulp+w ...
- springmvc 向页面传值
-
windows环境下nginx的启动、停止
Windows下Nginx的启动.停止等命令 在Windows下使用Nginx,我们需要掌握一些基本的操作命令,比如:启动.停止Nginx服务,重新载入Nginx等,下面我就进行一些简单的介绍.1.启 ...
-
devexpress中gridview控件编辑时改变输入法状态
在win7环境下使用Devexpress中的SpinEdit控件,切换成中文[简/繁]输入法输入数字键时有不少输入法会重复产生数字如输入1会变成11,输入123会变成112233.使用SpinEdit ...
-
EBS接口表关系概览（部分）
ItemTable Relationship TransactionTable Relationship PO/PRTable Relationships ReceivingTable Relatio ...
-
移动端rem flexible方案
一.px 自动转换为rem sublim Text3 下载本项目,比如:git clone https://github.com/flashlizi/cssrem 进入packages目录(在Subl ...
-
react 子元素修改父元素值的一个偏方，虽然简单，但是不建议用，
this.state.obj = { name: "小明" } <Zizujian obj={this.state.obj} /> // 子组件这样修改父元素的值 // ...
-
微信小程序开发 [04] 模板和模块化
1.模板 如果相同的wxml代码可能在不同的页面重复使用,ctrl+c配合ctrl+v的方式,后期维护起来未免也太麻烦了.微信提供了"模板",可以在模板中定义代码片段,然后在不同的 ...
-
Caffe+Windows 环境搭建收集
Caffe+Anconda3+VS2015+Win10(64位)环境搭建 Caffe on Windows (Visual Studio 2015+CUDA8.0+cuDNNv5) Win10+VS2 ...