zoukankan      html  css  js  c++  java
  • multilanguage

    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应该是透明的,找ViewViewEngine的职责,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"及对应的资源文件存在的时候才会正常运行,一旦ViewUserControl或者位置在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并刷新页面。

  • 相关阅读:
    如何使用 Python 進行字串格式化
    骨牌摆放问题 POJ 2411(状态压缩DP)
    ACM/OI中C++常用优化(实用/调试/技巧)代码(语法)
    Windows 系统如何完全卸载 VSCode
    Python 在VSCode中使用
    第十一场训练赛
    L1-046 整除光棍 (20分)
    Problem 330A
    POJ 2187 Beauty Contest (凸包 旋转卡壳)
    程序员:写作能收获什么?
  • 原文地址:https://www.cnblogs.com/bighuiwolf/p/1867160.html
Copyright © 2011-2022 走看看