火星人代码示例：系统设置（asp.net MVC3中View的复用示例）

功能简介

最终功能如图：
 

上面一行两张图，是火星人的用户故事树配置界面，在每个用户故事的后面都有一个按钮（悬停可见），点击后出现操作菜单，其中一部分是新建下级故事菜单。

若用户选择左侧，菜单上只包括一个项目“通用故事”；若选择右侧，则包括很多故事（受当前故事类型的约束，这个比较复杂以后再说）。

这段代码，等一下将会出现关键字“StoryTreeType”，左侧叫做“Simple”（简单树），右侧叫做“Leveled”（等级树）。

 

下面一行两张图，是火星人的状态链配置界面，在上面提到的操作菜单上，除了能新建故事之外，还能将当前故事转移到另外一个状态。

若用户选择左侧，菜单上只包括与开发相关的状态（新建-待开发-开发中-开发完毕-部署完毕）；做选择右侧，则会出现所有状态（新建后有审批等环节，而部署过程也包括多个状态）。

 

这段代码，等一下将会出现关键字“StatusList”，左侧叫做“DevelopmentOnly”（仅包含研发状态），右侧叫做“All”（所有）。

很显然，不只是这两排界面很类似，这四个界面和背后的模型都非常相近，下面谈谈如何以最小代码实现这个配置功能。

 

开发过程

Controller部分的代码略过，重点看Model和View的封装。

第一步：开发出StoryTreeType部分的Model代码

public partial class Product
{
    public const string UserDefaultProductIDKey = "DefaultProductID";

    //StoryTree type (Simple, Leveled, etc.)
    public const string StoryTreeTypeKey = "StoryTreeType";
    public enum StoryTreeTypes
    {
        Simple = 0,
        Leveled = 1
    }

    public static readonly StoryTreeTypes[] StoryTreeTypeValues = { StoryTreeTypes.Simple, StoryTreeTypes.Leveled };
    public static readonly string[] StoryTreeTypeTexts = { "缺省（使用简单父子关系形成故事树）", "使用系统定义的故事等级形成故事树" };

    public StoryTreeTypes StoryTreeType
    {
        get { return (StoryTreeTypes)Config.ReadValueAsInt(StoryTreeTypeKey, "$" + ID); }
    }

    public string StoryTreeTypeText
    {
        get { return StoryTreeTypeTexts[Config.ReadValueAsInt(StoryTreeTypeKey)]; }
    }
}

注意这段代码里边有一个叫做Config的类，它负责把不同的配置写到数据库中的一个公共表里边，因此为了完成这个功能，我们并不需要讨论数据存储问题。

 

这得益于火星人之前已经封装好的众多功能。
 

第二步：实现StoryTreeType的View

 

注意下面的代码，已经将StroyTreeType的两种类型进行了Foreach循环处理，而不是写死在里边。

有时候会觉得只有两种，还做什么循环，但如果不循环就需要两段很接近的代码，调试和维护都很费劲。而且一旦养成这种习惯，很容易把整个软件都写散了。

@foreach (var type in Product.StoryTreeTypeValues)
{
    "border: none; ">
        "help-sample">
            <table>

                    "border: none; width: 500px; ">
                        @MFCUI.Image("", "/Products/StoryTree/Index16.png") @Product.StoryTreeTypeTexts[(int)type]
                        @if (Model.StoryTreeType == type)
                        {
                            [当前设置]
                        }
                        else
                        {
                            @MFCUI.Link("[启用]", "/MFC/Configs/AjaxSet?key=" + Product.StoryTreeTypeKey + "&value=" + (int)type + "&user=$" + Model.ID, returnTo: this)
                            @:
                        }
                        <table>

                                "border: none; width: 200px; ">
                                    @RenderPage("~/Areas/DLC/Views/Products/ManagementMethod/StoryTreeTypes/_" + Model.StoryTreeType + ".cshtml")

                                "border: none; ">
                                    @MFCUI.Image("", "/Products/Products/ManagementMethods/_" + type + "Example.png")


                        table>


            table>

 

      

} 

注意

 

1. 这段代码里边有一个叫做“/MFC/Configs/AjaxSet?..."的调用，这个调用将直接完成设置工作（写入数据库），并立刻刷新当前页（注意有个“returnTo: this，是火星人中回到当前页的封装）。

2. 最上面的标题（“缺省（使用简单父子关系形成故事树）”和“使用系统定义的故事等级形成故事树”）、图片（最下面一个@MFCUI.Image()）都是在这个页面写出来的

3. 两个RenderPage用于显示“优点”“缺点”“建议”这些差别比较大的文字，分别存储在两个文件里边，文件名是在RenderPage里边用Model.StoryTreeType拼装出来的。
2和3表明了在MVC的View中的几个很重要的封装原则：

A. 相似的部分一定要For循环出来在一个View通过拼接中解决

B. 略微不同的参数使用变量拼接出来

C. 图片、Partial View的命名要与变量对应，这样方便拼接

D. 最大的不同，使用Partial View来处理。

第三步：为StatusList的Model部分“打草稿”

（写这篇博客的时候，我的代码刚刚写到这里，为了能拷贝到一点“草稿代码”，不等编码得到验证就开始写了）

做了很多年的封装，感觉最快速的方法，仍然是试探性封装，也就是先写出一个部分（如上面的StoryTreeType），然后拷贝另外一个相似的部分（如下面的StatusList），然后观察其相似点和不同点，然后才进行封装。

与直接在开头就设计封装相比，这种方法比较容易学习和接受，对人员的要求也相对较低。本人编程这么多年，还是没把握在所有情况下都面对空屏幕直接先写底层，然后派生出子类。

注意StatusList部分的代码是直接拷贝、粘贴、修改出来的，它们是“草稿代码”，用来观察封装要点的。日后将被取代。

public partial class Product
{
    public const string UserDefaultProductIDKey = "DefaultProductID";

    //StoryTree type (Simple, Leveled, etc.)
    public const string StoryTreeTypeKey = "StoryTreeType";
    public enum StoryTreeTypes
    {
        Simple = 0,
        Leveled = 1
    }

    public static readonly StoryTreeTypes[] StoryTreeTypeValues = { StoryTreeTypes.Simple, StoryTreeTypes.Leveled };
    public static readonly string[] StoryTreeTypeTexts = { "缺省（使用简单父子关系形成故事树）", "使用系统定义的故事等级形成故事树" };

    public StoryTreeTypes StoryTreeType
    {
        get { return (StoryTreeTypes)Config.ReadValueAsInt(StoryTreeTypeKey, "$" + ID); }
    }

    public string StoryTreeTypeText
    {
        get { return StoryTreeTypeTexts[Config.ReadValueAsInt(StoryTreeTypeKey)]; }
    }

    //Status list type (DevelopmentOnly, Allowed, etc.)
    public const string StatusListTypeKey = "StatusListType";
    public enum StatusListTypes
    {
        DevelopmentOnly = 0,
        Allowed = 1
    }

    public static readonly StatusListTypes[] StatusListTypeValues = { StatusListTypes.DevelopmentOnly, StatusListTypes.Allowed };
    public static readonly string[] StatusListTypeTexts = { "缺省（只显示开发相关的状态）", "使用用户自定义的允许状态" };

    public StatusListTypes StatusListType
    {
        get { return (StatusListTypes)Config.ReadValueAsInt(StatusListTypeKey, "$" + ID); }
    }

    public string StatusListTypeText
    {
        get { return StoryTreeTypeTexts[Config.ReadValueAsInt(StatusListTypeKey)]; }
    }
}

第四步：将StoryTreeType和StatusList改写为一个基类的派生类

说实话，这个改写过程失败了，5分钟后发现，因为每行代码都有不同之处，即使改写成功，初始化代码不比这些代码少。

 

而且还要冒着放弃enum的风险，所以终止了改写计划。
 

第五步：将处理StoryTreeType的View改写为同时可以处理StatusList的

很多新手在这个时候可能会直接开始动手，但下面介绍一下一个小技巧：

1. 先开辟一个第二战场：

<table class = "noborder">

        @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType.cshtml")


        @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType1.cshtml", Product.StoryTreeTypeValues)

table>

下面的_StoryTreeType1.cshtml是拷贝出来的，将显示在原来页面的下面，这样可以修改的同时可以观察新旧代码及其效果。

2. 一点点把StoryTreeType1中的StoryTreeType的影子抹掉

所谓影子，就是直接写着“StoryTreetype”而非一个变量的地方。当然，每抹掉一个，就要多传入一个参数。这里用的是PageData[]参数（MVC3新出现的）。

注意抹一点测试一下，遇到问题越早越好。

 

最后View的内部变成（注意完全看不到任何和StoryTreeType相关的痕迹了）：

@foreach (var currentConfig in PageData[0])
{
    "border: none; ">
        "help-sample">
            <table>

                    "border: none; width: 500px; ">
                        @MFCUI.Image("", PageData[1]) @PageData[2][(int)currentConfig]
                        @if (PageData[3] == currentConfig)
                        {
                            [当前设置]
                        }
                        else
                        {
                            @MFCUI.Link("[启用]", "/MFC/Configs/AjaxSet?key=" + PageData[4] + "&value=" + (int)currentConfig + "&user=$" + Model.ID, returnTo: this)
                            @:
                        }
                        <table>

                                "border: none; width: 200px; ">
                                    @RenderPage(PageData[5])

                                "border: none; ">
                                    @MFCUI.Image("", Page[6] + "_" + currentConfig + ".png")


                        table>


            table>

 

      

} 

而接口也变成：

    @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType.cshtml")


    @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType1.cshtml",
        Product.StoryTreeTypeValues, "/Products/StoryTree/Index16.png", Product.StoryTreeTypeTexts, Model.StoryTreeType, Product.StoryTreeTypeKey,
        "~/Areas/DLC/Views/Products/ManagementMethod/StoryTreeType/_" + Model.StoryTreeType + ".cshtml",
        "/Products/Products/ManagementMethods/")

注意看下面“第二战场”出现了很多输入参数。

 

从外观看，上下两个View的显示效果完全相同（就不贴图了）。

 

第六步：加入对StatusList的处理

删除第一个tr的代码，拷贝出来一个处理StatusListType的tr，并逐步修改使之可以工作：

<table class = "noborder">

        @RenderPage("~/Areas/Products/Views/Products/SetManagementMethod/_StoryTreeType1.cshtml",
            Product.StoryTreeTypeValues, "/Products/StoryTree/Index16.png", Product.StoryTreeTypeTexts, Model.StoryTreeType, Product.StoryTreeTypeKey,
            "~/Areas/DLC/Views/Products/ManagementMethod/StoryTreeType/",
            "/Products/Products/ManagementMethod/StoryTreeType/")


        @RenderPage("~/Areas/Products/Views/Products/SetManagementMethod/_StoryTreeType1.cshtml",
            Product.StatusListTypeValues, "/MFC/Statuses/Index16.png", Product.StatusListTypeTexts, Model.StatusListType, Product.StatusListTypeKey,
            "~/Areas/DLC/Views/Products/ManagementMethod/StatusListType/",
            "/Products/Products/ManagementMethod/StatusListType/")

table>

有几个小技巧：
1. 修改过程中，应该修改一个参数就查看一下是否还工作。

2. 优先修改那些不太会导致错误的数据，比如可以先修改"/MFC/Statuses/Index16.png", Product.StatusListTypeTexts这两个参数，因为他们是文字，基本上不会导致错误。

看看最后结果（因为缺少两个图片，所以屏幕显示有问题）：

 

后续及总结

后续

做完这些，_StoryTreeType1.cshtml这个文件名已经不妥了，因为它可以1行代码完成任何系统配置（包含一个标题，若干可选项，一组描述，一张图片），所以下一步需要修改它的名字，并且放到合适的地方。

不过就我们自己的习惯而言，我们会先改动名字，然后就放在原来使用它的地方。直到下一次真正被重新使用，再商量放在什么地方合适。

这句话的官方说法叫做“Use it before reusing it“，如果它现在就管这四个界面，就让它好好管着，等日后再说。

总结

整个过程包括写作本博客，大约耗时2小时。

可能有人会问：不过就是4个页面嘛，就是拷贝粘贴，也用不了1个小时啊，为什么要这么费劲？

有这么几个原因：

1. 未来我们大约会有20多个这样的设置页面，按上面介绍的封装，每生成一页只需要在View中添加一行代码。

2. 由于我们还没有美术人员，所以未来可能会改动页面效果，而这些页面都需要保持相同的风格。

3. 未来技术上可能也会做一些改动，比如那个Config，这些改动都不希望去修改很多代码。

其实，整个火星人的产品，就是在这种积木代码中产生的，有很多意想不到的地方都是只要1～2行代码就能调用出来（故事树、组织结构图、燃尽图、所有菜单（每个菜单都是延迟加载的）……）

这种习惯一旦养成了，代码就会越来越精练，而编写过程也越来越简单。