18. HtmlHelper 扩展

首先，参考一下 Rob Conery 的这篇文章，我完全同意他的观点，你应该为每种情况创建 Helper 方法，此外我还建议你像 ASP.NET MVC 团队那样为可重用的 UI 元素创建 Helper 方法，但是对于在哪里放置我们正在实践的这些方法，我有不同的建议。

应用程序开发者

只为你需要在多个视图中重复使用的HtmlHealper创建单独的扩展方法。对于只在一个视图中使用的帮助方法，你可以为整个视图创建一个Helper类，然后创建一个HtmlHelper来返回这个视图Helper类，而把只在这个视图中使用的扩展方法作为类内部的方法。（这部分未按原文翻译，请自行参照原文）例如：

public class DashboardHtmlHelper {
    private readonly HtmlHelper _htmlHelper;

    public DashboardHtmlHelper(HtmlHelper htmlHelper) {
        _htmlHelper = htmlHelper;
    }

    public string DoThis() {
        //Your Code
    }

    public string DoThat() {
        //Your Code
    }
}

public static class HtmlHelperExtension {
    public static DashboardHtmlHelper Dashboard(this HtmlHelper htmlHelper) {
        return new DashboardHtmlHelper(htmlHelper);
    }
}

然后在视图中这样调用：

<%= Html.Dashboard().DoThis() %>

UI 组件开发人员

如果你在开发的是可以在多个 ASP.NET MVC 应用程序中重用的 UI 组件系列，你可以像上面那样为你的整个系列组件创建一个单一名字的Helper。假如你开发的是商业组件，那你可以用你的公司名字来为这个单一的Helper命名，然后在这个Helper中添加方法。否则很容易出现方法的命名冲突。

要是你正在学习 MVCContrib.org 的做法，为 IViewDataContainer 做扩展的话，道理也是一样的。

19. Html编码

在从用户端获取信息的任何情况下，总是使用 Html.Encode(“User Input”) 来编码文本节点，用 Html.AttributeEncode(“User Input”) 来编码Html 元素属性。

20. 不要把Javascript脚本放在你的视图中

不要把你的javascript脚本和html混杂在一起，创建一个单独的 js 文件，把脚本代码放在里面。有时候你可能需要在你的 javascript 代码中传递视图数据，这种特殊的情况下，也只把初始化代码放在视图中。例如，你正在开发 web 2.0 风格的应用，你需要在这个应用中传递 ajax 方法的url，并且需要在 javascript 脚本中传递一些其它的模型数据，这种情况下，你可以参考下面的方式：

视图：

<div id="sideBar" class="column"></div>
        <script type="text/javascript">
            $(document).ready(function(){
                Story.init('<%= Model.UrlFormat %>', '<%= Url.NoIcon() %>', <%= Model.PageCount %>, <%= Model.StoryPerPage %>, <%= Model.CurrentPage %>, '<%= Model.SelectedTab %>', '<%= Model.SelectedOrderBy %>');
            });
        </script>
    </div>
</asp:Content>

Javascript：

var Story = {
    _urlFormat: '',
    _noIconUrl: '',
    _pageCount: 0,
    _storyPerPage: 0,
    _currentPage: 0,
    _currentTab: '',
    _currentOrderBy: '',

    init: function(urlFormat, noIconUrl, pageCount, storyPerPage, currentPage, currentTab, currentOrderBy) {
        Story._urlFormat = urlFormat;
        Story._noIconUrl = noIconUrl;
        Story._pageCount = pageCount;
        Story._storyPerPage = storyPerPage;
        Story._currentPage = currentPage;
        Story._currentTab = currentTab;
        Story._currentOrderBy = currentOrderBy;

        //More Codes
    }
}

这里要为不太熟悉上面的 javascript 的同学解释一下，这是一个在javascript中创建静态类的示例代码。对了，我还差点忘了提一点，永远不要在你的javascript文件中硬编码 ajax 方法的url，虽然 Rob Conery 和 Phil Haack 在他们的教程中是这样干的。这是一个很不好的方式，它破坏了 ASP.NET 路径重写的优雅性。

21. 使用 jQuery 和 jQuery UI

使用 jQuery 和 jQuery UI，它是最好的js库，并且可以使用 Google CDN 托管服务来加载这些库（对于国内用户，如果使用 google 托管的库一定要有承担风险的准备，具体原因嘛，看看国内6月24日左右的IT新闻就知道了）。

<link type="text/css" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/themes/{YOUR Prefered Theme}/jquery-ui.css" rel="stylesheet"/>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/jquery-ui.js"></script>

还有一种更好的方式：

<link type="text/css" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/themes/{YOUR Prefered Theme}/jquery-ui.css" rel="stylesheet"/>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
    google.load("jquery", "1.3.2");
    google.load("jqueryui", "1.7.1");
</script>

以上就是这一次的全部内容。

最后，我要祝贺 ASP.NET MVC 团队开发了如此杰出的框架，尤其是他们从社区接受反馈的方式。我希望能用这个框架开发出更多杀手级的应用（注：杀手级的应用程序，一般指极其优秀的应用程序，这类程序超越了语言本身，比语言更有吸引力而且能增加语言的吸引力）。

相关日志

• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

15. 关于路由的思考

如果你在开发的是一个纯 ASP.NET MVC 的应用程序，可以先关闭已有的路由文件检查，这样可以去除不必要的文件系统检查。如果你这样做了，那么就还需要考虑另外的一些事情。请记住如果你的应用程序运行于 IIS 7集成模式，那么 ASP.NET 应用程序将会拦截所有的请求，不管文件的后缀名是什么。所以你必须要在过滤列表中加一些东西，以便让 ASP.NET MVC 应用程序不处理它们。这其中可能包括静态文件，例如 html、htm、文本文件(尤其是robots.txt)、favicon.ico、脚本、图片和css等等。这也是我在第一部分第2节中提到不喜欢默认文件结构的原因之一。以下是我为 IIS7 定制的路由定义标准模板：

_routes.Clear();

// Turns off the unnecessary file exists check
_routes.RouteExistingFiles = true;

// Ignore text, html, files.
_routes.IgnoreRoute("{file}.txt");
_routes.IgnoreRoute("{file}.htm");
_routes.IgnoreRoute("{file}.html");

// Ignore axd files such as assest, image, sitemap etc
_routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

// Ignore the assets directory which contains images, js, css & html
_routes.IgnoreRoute("assets/{*pathInfo}");

// Ignore the error directory which contains error pages
_routes.IgnoreRoute("ErrorPages/{*pathInfo}");

//Exclude favicon (google toolbar request gif file as fav icon which is weird)
_routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.([iI][cC][oO]|[gG][iI][fF])(/.*)?" });

//Actual routes of my application

接下来是我的一些不同于手册指南的个人偏好。默认情况下 ASP.NET MVC 产生的 url 形如 {controller}/{action}，在你开发一个多模块的应用程序是这是不错的选择，但是对于一些很小的应用程序，我通常喜欢从 url 中去掉控制器(controller)只留下方法名(action name)。如此一来，原来的“www.yourdomain.com/Story/Dashboard” 及 “www.yourdomain.com/Membership/Signin” 就会变成 “www.yourdomain.com/Dashboard” 和“www.yourmain.com/Signin”。所以我要添加一些新路由：

_routes.MapRoute("SignUp", "SignUp", new { controller = "Membership", action = "SignUp" });
_routes.MapRoute("SignIn", "SignIn", new { controller = "Membership", action = "SignIn" });
_routes.MapRoute("ForgotPassword", "ForgotPassword", new { controller = "Membership", action = "ForgotPassword" });
_routes.MapRoute("SignOut", "SignOut", new { controller = "Membership", action = "SignOut" });
_routes.MapRoute("Profile", "Profile", new { controller = "Membership", action = "Profile" });
_routes.MapRoute("ChangePassword", "ChangePassword", new { controller = "Membership", action = "ChangePassword" });

_routes.MapRoute("Dashboard", "Dashboard/{tab}/{orderBy}/{page}", new { controller = "Story", action = "Dashboard", tab = StoryListTab.Unread.ToString(), orderBy = OrderBy.CreatedAtDescending.ToString(), page = 1 });
_routes.MapRoute("Update", "Update", new { controller = "Story", action = "Update" });
_routes.MapRoute("Submit", "Submit", new { controller = "Story", action = "Submit" });

_routes.MapRoute("Home", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = string.Empty });

16. 如果需要的话，创建新的ActionResult

ASP.NET MVC 包含有很多种用于不同目的的 ActionResult，但我们仍有可能会需要新的 ActionResult。例如xml、rss、atom等等。在这种情况下，我的建议是不要使用通用的 ContentResult， 而是创建一种新的 ActionResult. MVCContrib 项目中有一个 XmlResult，你可以用它来返回 xml，但是不支持 feed。显然依靠它来将未知对象转换为 rss/atom 是很困难的，这时你就可以创建一个定义ActionResult的模型。例如：

public class AtomResult : ActionResult {
    public AtomResult(string siteTitle, string feedTitle, IEnumerable<IStory> stories) {
        SiteTitle = siteTitle;
        FeedTitle = feedTitle;
        Stories = stories;
    }

    public string SiteTitle {
        get;
        private set;
    }

    public string FeedTitle {
        get;
        private set;
    }

    public IEnumerable<IStory> Stories {
        get;
        private set;
    }

    public override void ExecuteResult(ControllerContext context) {
        string xml = Build(context);

        HttpResponseBase response = context.HttpContext.Response;
        response.ContentType = "application/atom+xml";
        response.Write(xml);
    }
}

然后在控制器中就可以这样写：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Atom")]
public ActionResult Shared() {
    IEnumerable<stories> stories = GetSharedStories();

    return new AtomResult("My Site", "My shared stories in atom", stories);
}

17. 把你的视图拆分为多个视图控件

如果你的视图文件变得越来越大，那你可以考虑把它拆分为多个视图控件。至于视图空间是否在多个页面中重用，并没有关系。因为这样做可以让真正的视图文件变得更加具有可读性。考虑一下下面的视图：

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    My Secret App : Dashboard
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <div id="heading"></div>
    <div class="columns">
        <div id="main" class="column">
            <div id="storyListTabs" class="ui-tabs ui-widget ui-widget-content ui-corner-all">
                <% Html.RenderPartial("TabHeader", Model);%>
                <div id="tabContent" class="ui-tabs-panel ui-widget-content ui-corner-bottom">
                    <div id="storyList">
                        <% Html.RenderPartial("SortBar", Model);%>
                        <div class="clear"></div>
                        <% Html.RenderPartial("NoLinkMessage", Model);%>
                        <form id="update" action="<%= Url.Update()%>" method="post">
                            <% Html.RenderPartial("List", Model);%>
                            <% Html.RenderPartial("ActionBar", Model);%>
                            <% Html.RenderPartial("Pager", Model);%>
                        </form>
                    </div>
                </div>
            </div>
            <%Html.RenderPartial("Submit", new StorySubmitViewModel());%>
        </div>
        <div id="sideBar" class="column"></div>
    </div>
</asp:Content>

继续阅读：《ASP.NET MVC 最佳实践（四）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

• 支持命名空间
• 支持延迟静态绑定技术
• 支持跳转标签（受限制的goto）
• 支持闭包（Lambda表达式和匿名函数）
• 新增两个魔法函数，__callStatic 和 __invoke
• 新增 Nowdoc 语法支持，与 Heredoc 语法相同但是带有单引号
• 可以在静态变量和类成员、类构造函数中使用 Heredoc 语法
• Heredoc 可以用双引号定义，以便与 Nowdoc 的单引号区别
• 构造函数可以在类之外用 const 关键词进行定义
• 增加了条件操作符的简短形式 ?: (例如 a = condition ? true : false）
• 200 到 399 的状态码在HTTP数据流容器被认为是成功
• 允许动态访问静态成员
• 允许对异常进行嵌套
• 增加并且默认启用垃圾回收机制

此外，针对Windows版本的改变有：

• 不再支持Windows98,ME和NT4，最低支持Windows 2000
• Windows 二进制版本针对 i586 或更高版本编译，不再支持 i386和i486
• 对 Windows 系统上的 64位 PHP 提供支持（实验性的）
• 支持Visual C++ 9（VC9）编译，可以使用 Visual Studio 2008。
• PDO_OCI 的 php_pdo_oci8.dll 库（用于Oracle 8的客户端类库）不再构建，替代它的是 php_pdo_oci.dll（去掉了“8”），用于 Oracle 10 或者 11。与其他版本的数据库连接继续支持。
• 针对 OCI8 的扩展，除了php_oci8.dll之外增加了一个php_oci8_11g.dll，但是不能同时启用。php_oci8.dll与Oracle 10.2客户端类库结合使用，而php_oci8_11g.dll 和 Oracle 11客户端类库结合使用。与其他版本数据库的连接继续支持。

Windows版本新增加了对下列函数的支持：

• checkdnsrr()
• dns_get_record()
• fnmatch()
• getmxrr()
• getopt()
• imagecolorclosesthwb()
• inet_ntop()
• inet_pton()
• link()
• linkinfo()
• mcrypt_create_iv()
• readlink()
• socket_create_pair() – 这个函数以前就在Windows中支持，但是由于在PHP 4.3.0中的一个bug而被禁用
• stream_socket_pair()
• symlink()
• time_nanosleep()
• time_sleep_until()

除了上述改变外，Windows版本还有一些其它提升性能或者增加兼容性的改进，而最为重要的则是一条针对Windows的说明：

在windows下采用ISAPI方式运行PHP已经被遗弃，采用改进的FastCGI SAPI模块来代替。我在2008年6月23日的日志中曾经笑称“PHP成为IIS‘一等公民’”，那是只是从微软IIS团队官方发布PHP的FastCGI模块，以及微软和Zend的合作而对PHP在Windows平台上的使用做了最乐观的展望，而后来微软在IIS7以后的版本内置FastCGI模块，甚至在云服务中也内置FastCGI支持，则更说明了PHP与Windows的联姻将继续增强。可惜的是直到Windows7发布之后，网上的绝大部分教程依然在教新手采用ISAPI方式运行PHP，甚至是采用PHP4的安装方式。甚至还有人专门跑到我的空间里叫嚣在Windows下运行PHP是如何如何。开源社区对Windows平台的妖魔化，至今影响深远。正是由于拒绝导致了他们对Windows、ASP.NET、C#的不了解，甚至直至今日还死抱着Windows比Linux慢、不如Linux安全之类的陈旧观念。

如今PHP 5.3.0也像ASP.NET一样，引入了命名空间、延迟绑定、匿名函数、Lambda表达式等先进特性，可见编程语言与平台无关性在未来将更加凸显，而混合编程的正确性和先进性也将不断得到体现。封闭自己，拒绝变化的产品和思想，在开发领域只有死路一条。

相关日志

• 2008-06-04 -- 在ASP中实现UNIX时间戳
• 2008-05-23 -- 给UCenter的拥蹩们泼点冷水
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-06-08 -- 在 IIS 7.x 中用 FastCGI 运行 PHP
• 2008-06-23 -- 微软官方FastCGI，PHP成为IIS“一等公民”
• 2008-06-22 -- 动易SW中的一个严重但不影响使用的bug（二）
• 2008-06-22 -- 静态页面生成的思考

7. 不要在控制器中使用HttpContext类及其派生类

在你的控制器中不要引用到HttpContext以及它的派生类。这让你能比较容易地进行控制器的单元测试。如果你需要访问与HttpContext相关的对象比如User、QueryString、Cookie等，你可以使用自定义的行为过滤器（博客园的老赵有一篇文章对这一条进行了深入的论述，并提出了自己的解决方案，建议阅读）或者创建一些接口和容器，并把它传入控制器的构造函数。例如，下面的路由：

routes.MapRoute(
    "Dashboard",
    "Dashboard/{tab}/{orderBy}/{page}",
    new {
        controller = "Story",
        action = "Dashboard",
        tab = StoryListTab.Unread.ToString(),
        orderBy = OrderBy.CreatedAtDescending.ToString(),
        page = 1
    }
);

而控制器的行为方法则定义为：

[AcceptVerbs(HttpVerbs.Get),OutputCache(CacheProfile = "Dashboard"),UserNameFilter]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

UserNameFilter这个过滤器负责传递UserName：

public class UserNameFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string Key = "userName";

        if (filterContext.ActionParameters.ContainsKey(Key)) {
            if (filterContext.HttpContext.User.Identity.IsAuthenticated) {
                filterContext.ActionParameters[Key] = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuting(filterContext);
    }
}

[更新：一定要明确你已经对控制器或者是对控制器中的行为添加了 Authorize 属性，参见原文评论。]

8. 用行为控制器来转换行为方法参数

用行为过滤器来把传入值转换为你的控制器行为方法参数，再看一下 Dashboard方法的代码，我们以 Enum 类型接受 tab 和 orderBy这两个参数。

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard"), StoryListFilter]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

过滤器 StoryListFilter 将负责把它由 路由的值/查询字符串 转换为适当的数据类型。

public class StoryListFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string TabKey = "tab";
        const string OrderByKey = "orderBy";

        NameValueCollection queryString = filterContext.HttpContext.Request.QueryString;

        StoryListTab tab = string.IsNullOrEmpty(queryString[TabKey]) ?
                            filterContext.RouteData.Values[TabKey].ToString().ToEnum(StoryListTab.Unread) :
                            queryString[TabKey].ToEnum(StoryListTab.Unread);

        filterContext.ActionParameters[TabKey] = tab;

        OrderBy orderBy = string.IsNullOrEmpty(queryString[OrderByKey]) ?
                            filterContext.RouteData.Values[OrderByKey].ToString().ToEnum(OrderBy.CreatedAtDescending) :
                            queryString[OrderByKey].ToEnum(OrderBy.CreatedAtDescending);

        filterContext.ActionParameters[OrderByKey] = orderBy;

        base.OnActionExecuting(filterContext);
    }
}

你也可以用自定义模型绑定器来达到同样的目的。如果要那样做的话，你需要为每个枚举创建一个独立的模型绑定器，而不是用一个行为过滤器来处理所有的枚举参数。用模型绑定器还有一个问题，一旦你注册了一个类型，在行为中它就总是被使用，而行为过滤器则是可以根据需要选择使用的。

9. 行为过滤器的位置

如果你要对你的控制器的所有行为方法应用同一个行为过滤器，你可以把这个过滤器放在控制器的定义上而不必给每个行为方法应用。如果你要对你的所有控制器应用同一个行为过滤器，你应该创建一个基控制器，对它应用该过滤器，并让所有的控制器继承这个基控制器。例如 story 控制器应该只在用户已经登陆的情况下才可以使用，并且我们需要把当前用户的用户名传入 story 控制器下的方法，另外Story控制器应该压缩返回的数据：

[Authorize, UserNameFilter]
public class StoryController : BaseController {
}

[CompressFilter]
public class BaseController : Controller {
}

但是如果继承的层次达到或者高于2层，应该另找方法来应用过滤器。最新的 Oxite 代码里有一些非常出色的动态应用过滤器的方法，我强烈推荐你去看一下。

10. 小心使用UpdateModel

我要再次强调 Justin Ethredge 在他的文章中已经提过的这个问题，开发中一定小心，避免陷进UpdateModel的陷阱里去。

11.控制器不要包含任何域逻辑

控制器应该只负责：

• 验证输入
• 调用Model层来为显示视图准备数据
• 返回视图或者跳转到另一个行为

如果你在控制器中坐了其它的事情，那就说明你把它们放错了地方。你在控制器中坐的这些事情或许更应该交给模型去处理。只要你遵守了这条规则，你的每个控制器方法代码应该不会超过20到25行。 Ian Cooper 有一篇很棒的文章《Skin Controller Fat Model》，有空的时候你一定要读一下。

12. 避免使用 ViewData，尽量使用ViewData.Model

依赖于数据字典不仅使你的代码难以重构，而且你还不得不在试图中编写转换代码。实际上即使你给你的控制器的每个方法都单独编写一个类作为数据模型，那也是完全可以的。如果你觉得编写这些视图数据模型类是一项非常乏味的工作的话，你可以使用 MVCContrib 项目中 ViewDataExtensions，它包含一些用于返回强类型对象的不错的扩展。但是如果你的视图数据的数据字典中包含了多个数据类型的话，你还是没办法摆脱数据字典和他的字符串名。

13. 用 PRG 模式来修改数据

Tim Barcz, Matt Hawley, Stephen Wather 甚至 Scott Gu 都写了这方面的文章，你可以在 这里、这里、这里和这里找到它们。这个模式的一个问题是当一项验证失败或者发生任何错误的时候，你不得不把ModelState复制到TempData里面。如果你是手动来做这件事，请不要再那样做了，你可以用行为过滤器自动处理它，就像下面这样：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard"), StoryListFilter, ImportModelStateFromTempData]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page)
{
    //Other Codes
    return View();
}

[AcceptVerbs(HttpVerbs.Post), ExportModelStateToTempData]
public ActionResult Submit(string userName, string url)
{
    if (ValidateSubmit(url))
    {
        try
        {
            _storyService.Submit(userName, url);
        }
        catch (Exception e)
        {
            ModelState.AddModelError(ModelStateException, e);
        }
    }

    return Redirect(Url.Dashboard());
}

还有行为过滤器的代码：

public abstract class ModelStateTempDataTransfer : ActionFilterAttribute {
    protected static readonly string Key = typeof(ModelStateTempDataTransfer).FullName;
}

public class ExportModelStateToTempData : ModelStateTempDataTransfer {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        //Only export when ModelState is not valid
        if (!filterContext.Controller.ViewData.ModelState.IsValid) {
            //Export if we are redirecting
            if ((filterContext.Result is RedirectResult) || (filterContext.Result is RedirectToRouteResult)) {
                filterContext.Controller.TempData[Key] = filterContext.Controller.ViewData.ModelState;
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

public class ImportModelStateFromTempData : ModelStateTempDataTransfer {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        ModelStateDictionary modelState = filterContext.Controller.TempData[Key] as ModelStateDictionary;

        if (modelState != null) {
            //Only Import if we are viewing
            if (filterContext.Result is ViewResult) {
                filterContext.Controller.ViewData.ModelState.Merge(modelState);
            } else {
                //Otherwise remove it.
                filterContext.Controller.TempData.Remove(Key);
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

MVCContrib 项目也有这个功能，但是我不喜欢他们在用一个单独类来处理的方式，我喜欢对“哪个方法输出”和“哪个方法输入”有更多的控制权。

14. 为你的视图模型创建父类层并用行为过滤器来构成公共部分

为你的视图模型类编写一个父类层，并用过滤器来构成它的公共部分。例如我正在开发的这个非常小的应用程序，我需要知道用户是否已经认证，已及用户名。

public class ViewModel {
    public bool IsUserAuthenticated {
        get;
        set;
    }

    public string UserName {
        get;
        set;
    }
}

还有行为过滤器的代码：

public class UserNameFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string Key = "userName";

        if (filterContext.ActionParameters.ContainsKey(Key)) {
            if (filterContext.HttpContext.User.Identity.IsAuthenticated) {
                filterContext.ActionParameters[Key] = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuting(filterContext);
    }
}

public class ViewModelUserFilter : ActionFilterAttribute {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        ViewModel model;

        if (filterContext.Controller.ViewData.Model == null) {
            model = new ViewModel();
            filterContext.Controller.ViewData.Model = model;
        } else {
            model = filterContext.Controller.ViewData.Model as ViewModel;
        }

        if (model != null) {
            model.IsUserAuthenticated = filterContext.HttpContext.User.Identity.IsAuthenticated;

            if (model.IsUserAuthenticated) {
                model.UserName = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

正如你所看到的，如果在控制器里预先设定它的话，它并没有替换模型，而是在它发现模型与它符合的时候，才作为控制器的公共部分起作用。另一个好处是，由于视图只依赖于父类层，你可以不必返回具体的model，而只需要返回 View()。

继续阅读：《ASP.NET MVC 最佳实践（三）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

1. 创建UrlHelper的扩展方法来生成url

尽量避免以字符串方式直接传递controller, action 或者 route name，最好是为创建为UrlHelper创建扩展方法来封装url。例如：

public static class UrlHelperExtension {
    public static string Home(this UrlHelper helper) {
        return helper.Content("~/");
    }

    public static string SignUp(this UrlHelper helper) {
        return helper.RouteUrl("Signup");
    }

    public static string Dashboard(this UrlHelper helper) {
        return Dashboard(helper, StoryListTab.Unread);
    }

    public static string Dashboard(this UrlHelper helper, StoryListTab tab) {
        return Dashboard(helper, tab, OrderBy.CreatedAtDescending, 1);
    }

    public static string Dashboard(this UrlHelper helper, StoryListTab tab, OrderBy orderBy, int page) {
        return helper.RouteUrl("Dashboard", new { tab = tab.ToString(), orderBy = orderBy.ToString(), page });
    }

    public static string Update(this UrlHelper helper) {
        return helper.RouteUrl("Update");
    }

    public static string Submit(this UrlHelper helper) {
        return helper.RouteUrl("Submit");
    }
}

这样，如果在你的视图中有类似这样的代码：

    <%= Html.ActionLink("Dashboard", "Dashboard", "Story") %>
    <a href="<%= Url.RouteUrl("Profile")%>">Profile</a>

你就可以用下面的这种方式来代替它们：

<a href="<%= Url.Dashboard() %>">Dashboard</a>
<a href="<%= Url.Profile() %>">Profile</a>

在控制器里也可以用，原来的代码：

return RedirectToAction(
    "Dashboard",
    "Story",
    new {
        tab = StoryListTab.Favorite,
        orderBy = OrderBy.CreatedAtAscending,
        page = 1
    }
);

可以写成：

return Redirect(Url.Dashboard(StoryListTab.Favorite,
                                OrderBy.CreatedAtAscending, 1));

当然了，你也可以使用 future assembly 中的强类型版本来获得控制器、方法以及参数值，或者创建你自己的强类型版本以免将来进行重构时太过于痛苦，但是请一定记住，它没有官方支持并且将来有可能会发生改变。上面的方式也可以和强类型版本搭配使用。当然“另外增加一个间接层”（Scott Ha 喜欢用的引语）有一些好处，在编写单元测试的时候还有一个好处是你只需处理 RedirectResult 而无须同时处理 RedirectResult 和 RedirectToRouteResult。

2. Create Extension Method of UrlHelper to map your JavaScript, Stylesheet and Image Folder

默认情况下 ASP.NET MVC 创建Content、Scripts文件夹来做这些事，这一点我不喜欢，我更喜欢下面的这种文件夹结构，这样在IIS里我可以只让静态文件缓存在Assets文件夹而不是多个文件夹：

• Assets
• +images
• +scripts
• +stylesheets

无论是结构是什么样的，还是要为UrlHelper创建一些扩展方法来映射这些文件夹，以便你在视图中可以很方便地指向它们，这样以后如果你要改变目录结构，你就无须做大量查找替换的工作。我还建议你为所有经常在视图中用到的资源创建UrlHelper的扩展方法。例如：

public static string Image(this UrlHelper helper, string fileName) {
    return helper.Content("~/assets/images/{0}".FormatWith(fileName));
}

public static string Stylesheet(this UrlHelper helper, string fileName) {
    return helper.Content("~/assets/stylesheets/{0}".FormatWith(fileName));
}

public static string NoIcon(this UrlHelper helper) {
    return Image(helper, "noIcon.png");
}

然后当需要用到这些路径的时候，原来的代码

<link href="../../Content/Site.css" rel="stylesheet" type="text/css" />

就可以写成这样：

<link href="<%= Url.Stylesheet("site.css")%>" rel="stylesheet" type="text/css" />

3. 中使用启动加载器

我在以前的文章中已经提到过这一点，总的来说就是：如果你要在 Global.asax 的 Application_Start 中做很多处理，比如 注册路由规则(Routers)、注册控制器工厂(Controller Factory)、模型绑定(Model Binders)、视图引擎(View Engine)、启动程序级的特定后台服务或者为特定部分创建独立任务等，那就用启动加载器来执行这些操作。这会让你的代码更简洁，更可测。这一点在用 ASP.NET MVC 构建门户级应用时尤其有用，因为这类应用中的每个模块都可能有一些不影响到其他模块的启动初始化操作。但是如果你只是开发一个小应用，上面提到的这些对你来说都不是问题，你当然也可以继续用默认的 global.asax。

4. 不要硬编码对依赖注入容器的调用，用通用服务定位器来代替。

不要让任何特定的依赖注入容器(DI Container)打乱你的代码，更好的办法是使用通用服务定位器(Common Service Locator)，它是对底层依赖注入进行的抽象，已经支持几乎所有流行的依赖注入容器，它让你可以任意替换底层的依赖注入对象而无须修改代码，因为每个依赖注入容器都具有一些不同于其它容器的特性。Tim Barcz 最近写了一篇关于这个话题的很棒的文章，我不太明白他为什么没有提到我们对我们偏爱的依赖注入容器有多痴迷。通用服务定位器对绝大部分常用情景都提供了支持，而对一些特殊情况比如对已实体化对象的依赖注入，我印象里有 StructureMap、Ninject 和 Unity，你可以调用静态方法 ServiceLocator.Current.GetInstance 来代替。 通用服务定位器 是 Jeremy D Miller 发起的 依赖注入容器开发者(the DI Containers creators)的集体作品。

用通用服务定位器创建控制器工厂非常容易：

public class CommonServiceLocatorControllerFactory : DefaultControllerFactory {
    protected override IController GetControllerInstance(Type controllerType) {
        return (controllerType == null) ? base.GetControllerInstance(controllerType) : ServiceLocator.Current.GetInstance(controllerType) as IController;
    }
}

我希望 MVCContrib 的成员们也用这样的方式，而不是为每个容器创建一个独立的控制器工厂。

5. 用恰当的的AcceptVerbs属性来修饰你的控制器方法

ASP.NET MVC 比 Web Forms 更容易遭受攻击。所以务必让对数据进行修改的控制器方法只接受 Post 方式请求（HttpVerbs.Post）。如果安全对你来说至关重要，你还可以用 ValidateAntiForgeryToken 或者 Captcha。我强烈推荐 Derik Whittaker 写的一篇 很好的文章 以及视频介绍了怎么把 reCaptcha 整合到 ASP.NET MVC 应用程序（作者注：不要错过了 DimeCasts.net 的另一个短片，我从中学到了很多）。我的经验法则是对所有数据修改方法使用 HttpVerbs.Post，对所有数据读取操作使用 HttpVerbs.Get。

6. 用OutputCache修饰你的频繁调用的操作方法

当你需要返回不频繁更新的数据时使用 OutputCache 属性，最常见的例子是首页、Feed等。你在返回Html以及Json数据类型的方法中都可以使用这个属性。在使用的时候，注意只指定CacheProfile参数，不要指定任何其它东西，用 web.config 输出缓存控制节可以很好地调整它。例如：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard")]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

在 web.config 文件中的配置：

<system.web>
    <caching>
        <outputCacheSettings>
            <outputCacheProfiles>
                <clear/>
                <!-- 15 Seconds -->
                <add
                    name="Dashboard"
                    duration="15"
                    varyByParam="*"
                    location="Client"
                    />
            </outputCacheProfiles>
        </outputCacheSettings>
    </caching>
</system.web>

请继续阅读：《ASP.NET MVC 最佳实践（二）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

　　这次继续分析这个Bug。在新版本的API_Function.asp这个文件中，selectSingleNode这个函数一共用到了5次，有两次是在SendPost函数里，在很早的版本里那两个地方就用的是selectSingleNode，因为那里传递的参数用的是“//status”和“//message”，是正确的XPath，因此不用考虑那里了。此外的三处，代码如下：

'**************************************************
'函数名：getNodeText
'作  用：获取XML文件中指定节点的文本
'参  数：strNodeName   ----节点名称
'返回值：解析出来的文本值，
'**************************************************
Function getNodeText(strNodeName)
    If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
    If IsNode(strNodeName) Then
        getNodeText = sMyXmlDoc.documentElement.selectSingleNode(strNodeName).Text
    Else
        getNodeText = ""
    End If
End Function  

'**************************************************
'函数名：setNodeText
'作  用：设置XML文件中指定节点的文本
'参  数：strNodeName   ----节点名称
'　　　　strNodeText   ----要设置的文本
'返回值：0 = 设置成功; 否则返回Err.Description
'**************************************************
Function setNodeText(strNodeName, strNodeText)
    If IsNull(strNodeText) Or IsEmpty(strNodeText) Or strNodeText = "" Then Exit Function
    If IsNull(strNodeName) Or IsEmpty(strNodeName) Or strNodeName = "" Then Exit Function
    If IsNode(strNodeName) Then sMyXmlDoc.documentElement.selectSingleNode(strNodeName).Text = strNodeText
End Function  

'**************************************************
'函数名：IsNode
'作  用：检查一个Node是否存在且文本不为空
'参  数：strNodeName   ----节点名称
'返回值：True or False
'**************************************************
Function IsNode(strNodeName)
    IsNode = False
    If strNodeName = "" Then Exit Function
    If sMyXmlDoc.documentElement.selectSingleNode(strNodeName) Is Nothing Then
        IsNode = False
    Else
        IsNode = True
    End If
End Function

　　我们来看，为什么设置message的值不会成功并且不报错呢？原因就在于setNodeText这个函数的最后一句：

　　IsNode这个函数，从函数的注释（还好这个没改）可以看出，作用是“检测一个元素是否存在且文本不为空”，这个函数本来的作用是用于检查传递的数据包中的“自定义元素”和“扩展元素”的，因为各个接口对标准的支持程度不同，因此在获取数据的时候，有的元素可能只是穿了空值过来，那我们就没有必要对该元素进行处理了，所以要用IsNode来检查一下。但是在setNodeText这个函数里没有调用过IsNode检查。就算调用了，按照以前的方式，一定会取到“message”元素的默认值，从而返回True。

　　在新版本中，由于采用了selectSingleNode来取“message”已经取不到了，自然，IsNode这个函数在检查到message的时候，必然返回空值，因为 sMyXmlDoc.documentElement.selectSingleNode Is Nothing这个判断为真了，所以会返回False。于是，sMyXmlDoc.documentElement.selectSingleNode(“message”).Text 这个语句就不会执行，也就不会引发500错误了。

　　做个假设，如果在修改了取元素的方式之后，没有给setNodeText和getNodeText加上IsNode判断，则必然引发500错误。或者，没有修改过IsNode这个函数，则仍然会返回True，然后引发500错误。正好是加上了判断，于是所有对message元素的值的读写都被忽略了，默认值“操作已成功”就这样被原封不动地回发给所有请求，而响应包中的用户数据元素也一样。

　　下面是纠正bug的代码：

第二种改法：用selectSingleNode的方法，代码如下

　　这样就能充分利用selectSingleNode的简洁了，但是还要注意哦，由于新版本的createXmlDom不再是自动生成支持的最高版本的xmldom对象，而是生成默认版本（系统默认版本一般都是3.0以下），而低于4.0的版本中，selectSingleNode对XPath的支持是有问题的，不支持带函数的XPath，所以还要小心！

相关日志

• 2008-06-18 -- 动易SW中的一个严重但不影响使用的bug(一)
• 2008-05-23 -- 给UCenter的拥蹩们泼点冷水
• 2008-06-22 -- 静态页面生成的思考
• 2008-06-04 -- 在ASP中实现UNIX时间戳
• 2007-01-30 -- 整合开发的新思路
• 2006-04-12 -- 用JavaScript动态输出的JS脚本不能执行
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-05 -- PHP 5.3.0 发布

　　但是我们不得不考虑到目前流行的html静态页生成的后遗症——后期维护，实际上这也正式目前我们团队在工作中已经遇到的大问题。

　　我们的网站每天更新量大约在2000条信息左右，目前仅新闻频道就已经有几十万条信息，我们每天同时有十多名甚至二十多名编辑同时在线更新。目前我们的网站目录已经有近10G大小，每次把网站文件打包需要三个多小时（不包括数据库，数据库是SQL Server）。因此编辑工作繁忙的时段，上传、生成等工作集中在一起，后台速度严重降低。

　　除此之外，每当我们需要对网站的栏目、页眉、页脚等方面进行一次改动，就不得不重新生成静态文件（现在我们采用生成shtml文件，服务器端包含页眉页脚的方式，已经基本解决这个问题），或者我们的网页模板进行了改动，必须重新生成静态文件。

　　这一切造成网站的规模越大，后期维护难度越大，成本越高。

　　针对这一切，我想到静态生成的另一种方式，当然，会增加模板制作的难度，但是同时却有更多的好处，那就是进一步分离网站的内容和结构。

　　我们知道生成静态文件最大的目的是减少数据库查询。生成静态页只需要一次请求就得到页面内容。那如果我们生成静态xml内容呢？这样一次生成之后，内容页以后基本不用再次生成（这相当于以前用文本数据存储的形式，但是文本数据存储是服务器端脚本通过I/O方式读取文档，而xml静态内容是客户端直接请求xml，完全无需服务器端做任何解析或者运算）。

　　有人说，生成xml了那怎么实现多姿多彩的网页效果啊？我们知道xslt可以把xml格式化成html，而且这种格式化可以在服务器端完成也可以在客户端完成。因此我们完全可以输出的就是指定了xslt的xml文件。内容很少，不需改动，就算改动了，也只需要重新生成当前的xml文件，磁盘读写内容大大减小。

　　基本的实现思路和带来的好处如下：

1. 服务器端生成静态的xml，xslt相当于页面模板，是固定的，css文档是外部的。xml负责内容，xslt负责结构，css负责表现。
2. 如果一个网站需要改变风格，比如颜色、背景和简单的布局变化，只需要写css就可以实现；如果更进一步，需要改变页面结构，只需要修改xslt（千万文章也只是一个或几个xslt）。立即更改立即生效。
3. 不用在每次改版的时候重新生成任何的静态文件；并且，我们可以把公共信息单独输出xml，不和内容页混合在一起，要知道，一个xslt并不是只能单独处理一个xml.如此以来，当我们改变了导航结构等公共信息，依然只需要重新生成一个文件，就像更新了一下缓存。
4. 用户访问的时候，每次只下载内容部分，不需要重新下载xslt和css，等于不用ajax却实现了局部更新。

　　这个思路并不是首创，我上网查找相关资料的时候发现有不少同类思路。动易系统在ASP版本中也实现过栏目导航的xml输出，不过只是为了让flash等非asp的应用便于读取栏目结构罢了。另外还有人成功实现了生成静态xml，采用Ajax方式在客户端实现页面内容的变换。

　　可见这并不是一个不可行的思路，当然具体实现起来需要解决很多问题，而且它也有它的缺点：

　　网页制作从静态html模板+标签变成了css文件和静态html（页面设计师实现）+xslt模板（UI工程师或者程序员实现）+xml标签数据和内容数据（应用开发商实现）；

　　但是这个困难只针对一个环节，就是建站环节，而事实上如果官方提供的xslt能够输出结构优秀的html结构，那么设计师其实不需要修改xslt对最终html文档结构做大的变动就可以对网站样式进行彻底地改变。

　　而且这样以来，程序员的web标准知识欠缺或者不了解xhtml，不能输出优秀的符合大家需要的html也不会影响到高水平站长对web标准的追求。

　　我坚信如果这个方案能够得到完善并实施，对于网站管理者来说，绝对是利大于弊。

相关日志

• 2008-06-22 -- 动易SW中的一个严重但不影响使用的bug（二）
• 2008-06-18 -- 动易SW中的一个严重但不影响使用的bug(一)
• 2008-05-23 -- 给UCenter的拥蹩们泼点冷水
• 2007-01-30 -- 整合开发的新思路
• 2006-04-12 -- 用JavaScript动态输出的JS脚本不能执行
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-05 -- PHP 5.3.0 发布
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）

BUG描述：整个动易API接口的响应功能，除了操作状态码正常，其它部分完全失效，不会返回错误提示，也不会返回用户信息。

BUG重现：在启用了整合的站点，直接访问/API/API_Response.asp，将会看到<status>1</status>（表示请求不正确或者操作失败），以及<message>操作已成功完成</message>（操作成功返回的默认值）。就表示该BUG存在。

BUG影响：大部分情况下，各个应用程序并不会向动易请求用户信息，因此除了在登陆失败、注册失败等失败操作会提示用户“操作已成功”的假象以外，暂时不会造成其它影响。

　　动易SW里有这样一个问题，只有启用了整合接口并且曾经在整合的其它系统中遇到过错误提示的朋友才会发现：

　　每当整合出现问题或者是登陆、注册等一系列操作出错的时候，我们知道以前是返回错误的具体提示，包括服务器缺乏相关组件，或者接口配置错误，或者用户信息错误等，都会有不同的提示。到了SW里，这些操作同样也会返回错误，不会让你操作成功。但是错误的提示是什么呢？全部都是“操作已成功完成”，这个搞笑的问题出在哪里呢？

　　以前设计API的时候，考虑到最常见的情况是用户注册、登陆、注销这些日常操作，而这些操作里又是成功的居多，所以我在用于返回信息的Response.xml模板里，设置了默认返回状态为0（表示成功），默认返回信息为“操作已成功完成”。这就是这个bug的缘起了。

　　那么，以前老的版本反而没有这个问题，为什么新版本里出现这个问题呢？第一反应：当出现错误的时候，没有修改message，也就是错误提示信息。好，我们打开API_Response.asp检查一下，发现当操作错误的时候，代码是这样的：

If FoundErr Then
    sPE_Items(conStatus, 1) = "1"
    sPE_Items(conMessage, 1) = ErrMsg
    prepareXML (False)
    WriteXml
Else
    sPE_Items(conStatus, 1) = "0"
    prepareXML (False)
    WriteXml
End If

　　我用黄色背景标记的这行，翻译过来就是“设置提示信息的内容为ErrMsg（具体的错误信息）”，说明不是没有修改，于是我们继续往下查，sPE_Items这是一个API使用的全局数组，二维的，sPE_Items(a, b)，a代表xml里的不同元素，b为0标识我们要访问的是元素名称，1标识我们要访问的是元素里的内容；而conMessage是一个常数，实际上它等于4。在全局数组里sPE_Items(4, 1)代表的就是xml中message这个元素的内容。

　　接下来是prepareXML(False)这个函数。这个函数的作用是加载xml模板，然后用数组里的内容去替换默认值。经检查，在prepareXML这个函数里，当返回出错信息的时候的代码如下：

　　这里不会有什么问题，看来问题就出在setNodeText这个函数上了。新版本中的这个函数是：

　　以前的版本中代码是：

　　区别就在于，新版本用selectSingleNode这个方法获取节点，以前版本中我用getElementsByTagName().Item(0)这个方法来获取节点。两个方法都是返回xml文档树中的一个元素对象。新版本的代码简洁，直接从树中读取一个元素，而我的方法是读取文档树中所有标签为strNodeName（本例中指的是message）的元素列表，然后取第一个。

　　我排错的时候看到这里就已经明白问题所在了。因为当初我第一次写到这里的时候就犯过新版中这个错误。selectSingleNode这个方法的参数类型是XPath，而getElementsByTagName这个方法的参数类型是string。我们这里给的“message”，不是一个XPath，如果在我们的文档中用XPath来标识这个元素，正确的应该是“/root/body/message”，但是由于sMyXmlDoc这个对象取得是xml文档树的根元素，也就是root，所以其实也可以用“/body/message”来访问到。文档中只有一个message元素，因此也可以用“//message”来访问。不管用哪一种都行，但是用“message”是不对的。

　　所以这里给xml中所有body的子元素赋值都会失败。这就是问题所在了。

　　同理可知，在新版本的接口中，如果是整合的程序向动易发送请求，那么不管什么请求，返回的xml包中，都只有两个有效数据，一个是告诉对方响应者是动易系统，另一个就是告诉对方操作状态是成功还是失败。至于错误的具体提示，只有默认值，而其它的数据，比如检索用户信息，返回的则全部是空值。还好目前的整合中基本上不会用到这些元素，所以也就成了一个“严重”但不影响使用的bug了。关于这个bug为什么没有引发500错误以及如何修正，下次我再继续说。

　　除此之外，动易的新版本接口还增加了一个新元素（sex），可以理解为符合接口规范的自定义元素，但是这个元素表示的是用户性别。这是在标准中定义的必备扩展元素，元素名称是gendar（英文单词意思是性别）。等于放弃了对标准元素gendar的支持，增加了一个自定义元素sex。

　　不知道三方是否在这个新增元素上做过沟通取得了共识。如果没有的话，那么这里又是一个新bug，就是通用注册的时候，其它程序将不能通知动易记录用户的性别，动易也没法通知其它用户。

　　我第一次看到这个新增元素的时候百思不得其解。如果是gendar命名不恰当，要改的话，那应该会发公告通知PDO接口规范更新到1.1或者2.0，新增sex元素，gendar元素状态变为“不推荐”，这是w3c在xhtml规范里喜欢用的方式。先不推荐但是还兼容，让你有时间慢慢改，以后时机恰当再取消。

　　但是我奇怪的是gendar无论从语意上讲还是从哪方面讲，都不算是命名不规范的元素啊，甚至是比sex更规范的元素。sex只不过是在部分web应用里习惯的用法而已。其英文单词意思是“性”，而不是“性别”。

　　莫非做这个修改的技术员在修改接口的时候不看接口规范？不得而知了。但是对于selectSingleNode不能根据元素名称选择元素这个问题，的确是不应该犯的。

　　发现我写的代码被更改并不是因为我写错了，本来应该是高兴的吧，但是我却高兴不起来。我依然是动易的忠实FANS，我希望它更好。

相关日志

• 2008-06-22 -- 动易SW中的一个严重但不影响使用的bug（二）
• 2008-05-23 -- 给UCenter的拥蹩们泼点冷水
• 2008-06-22 -- 静态页面生成的思考
• 2008-06-04 -- 在ASP中实现UNIX时间戳
• 2007-01-30 -- 整合开发的新思路
• 2006-04-12 -- 用JavaScript动态输出的JS脚本不能执行
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-05 -- PHP 5.3.0 发布

　　但是在研究UC的过程中却也有一些细小的收获。这篇文章说说PHP中的时间戳。在PHP中，时间函数time()获得的不是我们在ASP中的事件函数Now()所返回的“2008-06-04 21:19:41”这样的形式，而是“1123495443”这样的形式。这个记录的是所表示的时间与1970年1月1日午夜零点之间的事件差，单位为秒，不考虑闰年等因素。

　　如果要编写UC的ASP客户端，这个问题是必然要面对的，实际上即使不为UC编写客户端，这个特性引入ASP还是有不少好处的。下面是具体的实现办法：

　　这两个函数分别用于标准时间转Unix时间戳和Unix时间戳转标准时间。用法在函数前面的注释里写得很清楚了。

相关日志

• 2008-05-23 -- 给UCenter的拥蹩们泼点冷水
• 2009-07-05 -- PHP 5.3.0 发布
• 2008-06-22 -- 动易SW中的一个严重但不影响使用的bug（二）
• 2008-06-18 -- 动易SW中的一个严重但不影响使用的bug(一)
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-06-08 -- 在 IIS 7.x 中用 FastCGI 运行 PHP
• 2008-09-19 -- Oblog检测搜索引擎的一个问题

在康盛创想的论坛上能看到有不少JSP程序、ASP.NET程序员都在咨询或者说抱怨官方的开发文档和示例太难看懂，完全是基于PHP的，如果不把PHP搞懂，很难实现在其它开发平台下的接口开发。而官方的回答只是“以后考虑”。

动易SF 1.1的发布公告中也指出基于UCenter的接口已经列入开发计划中。令广大动易站长欢欣鼓舞。

但是，我却不得不在这里给众多开发人员和站长们泼一盆冷水&mdash;&mdash;基于目前的UCenter，是没办法开发其它平台的接口的。原因很简单，UCenter服务器端默认了客户端的接口路径为“应用URL” + “api/uc.php”，而且这个是不能在配置文件或者后台修改的。

也就是说，不管你在什么平台下，是什么开发语言，你的接口必须为uc.php。那么，只有一个解决方法，就是在你的服务器上映射.php的后缀到你的程序语言的解析器，让.php也变成asp文件或者.net页面的后缀。那你的站点就不可能再同时支持php和asp，或者php和jsp，或者php和asp.net。而如果你是虚拟主机用户，你需要做的事情更多。

我们可以通过简单的方法修改UCenter，使之支持各平台语言的接口（要修改的文件只有4个左右），但是如此一来，等于是第三方开发人员或者说二次开发人员需要对服务器端进行修改，那已经不像是一个“通用平台”的问题了。

其次，在跨平台的信息传递中，UCenter大量使用的是Get/Post方式发送URLEncode编码的数据，而不是在所有平台所有编码语言下都有良好支持的xml格式。这样开发人员不得不继续花费大量时间来处理编码问题。

还有，UCenter由于采用PHP开发，大量使用了PHP的特性的东西，比如UNIX时间戳，比如键值对的数组，而在其它语言平台中，对这些东西的支持是各有不同的。虽然能够处理，但是却非常麻烦。

UCenter目前给我们带来一个最大的启发，就是一个中心，多套应用的模式，以及采用P3P来实现跨域Cookie处理的思路。

我相信，随着UCenter的出现解决了一系列跨站整合中的问题后，完善的跨站用户中心应该会很快出现。而UCenter如果不在下一版本中做大规模的改变，它是不太可能成为最终的通用整合中心的。至少这么久以来，我们可以看到康盛自己的.NET论坛都还没能支持这个UCenter，就能说明一些问题。

相关日志

• 2008-06-22 -- 动易SW中的一个严重但不影响使用的bug（二）
• 2008-06-18 -- 动易SW中的一个严重但不影响使用的bug(一)
• 2008-06-04 -- 在ASP中实现UNIX时间戳
• 2009-07-05 -- PHP 5.3.0 发布
• 2008-06-22 -- 静态页面生成的思考
• 2007-01-30 -- 整合开发的新思路
• 2006-04-12 -- 用JavaScript动态输出的JS脚本不能执行
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）