LocalizationHelper类可改进之处：
1.不应对Controller做使用局部资源的扩展，因为Controller里只应该知道全局资源。
public static string Resource(this Controller controller, string expression, params object[] args)
{
return GetLangString(controller.HttpContext, expression, "~/Views" + controller.HttpContext.Request.Path + ".aspx", args);
}
原因是：
首先，从松耦合设计的角度考虑，View相对于Controller应该是透明的，找View是ViewEngine的职责，Controller只需要知道View的名字，而不需要也不应该知道其位置。在asp.net MVC里通过View的名字找具体的View的机制是松耦合的， 默认实现是WebFormViewEngine类，这个类继承自VirtualPathProviderViewEngine，而VirtualPathProviderViewEngine实现了IViewEngine，理论上只要实现了IViewEngine接口的类均可以有自己的方式来作为查找View的机制，而不一定按"~/Views" + controller.HttpContext.Request.Path + ".aspx"来定位。
其次，客观上只有找的是Page，且"~/Views" + controller.HttpContext.Request.Path + ".aspx"及对应的资源文件存在的时候才会正常运行，一旦View是UserControl或者位置在Share目录就会找不到，而出异常。
建议的解决方案：
（1）在Controller只可以访问全局资源
（2）如果非要用局部资源，则只应在Model里存入Key，访问具体局部资源的过程要推迟到View阶段。
方案二：
（1） 修改Html.Resource方法，完善其查找View的途径，让它的机制与WebFormViewEngine的机制相同。
方案二的修改难度低，只需要修改Resource方法，不必改Controller里的代码。但它使Html类与具体类WebFormViewEngine产生了强耦合，违反低耦合设计原则。
2.性能改进： 每取一次资源，就会new一个CultureInfo对象，具体请看GetResourceString方法，Language.GetCurrentLanguageFormat()也存在同样的性能问题。
结合以前的研究，我提出以下改进建议：
（1） 定义系统支持的语言列表，列表中第一项为默认语言，系统运行后，建立与语言列表对应的一组CultureInfo对象，在后续的请求中需要哪个就用哪个，不需要再New对象。
（2） 页面上添加选择语言的选项，可让用户来选择想看的语言。选择语言对应的逻辑是用JS修改Cookie并刷新页面。
