现在的位置: 首页 > 综合 > 正文

火星人代码示例:系统设置(asp.net MVC3中View的复用示例)

2013年09月13日 ⁄ 综合 ⁄ 共 7514字 ⁄ 字号 评论关闭
文章目录

功能简介

最终功能如图:

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

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

这段代码,等一下将会出现关键字“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)
{
    <td style = "border: none; ">
        <div class = "help-sample">
            <table>
                <tr>
                    <td style = "border: none; width: 500px; ">
                        @MFCUI.Image("", "/Products/StoryTree/Index16.png") <b>@Product.StoryTreeTypeTexts[(int)type]     </b>
                        @if (Model.StoryTreeType == type)
                        {
                            <b>[当前设置]</b>
                        }
                        else
                        {
                            @MFCUI.Link("[启用]", "/MFC/Configs/AjaxSet?key=" + Product.StoryTreeTypeKey + "&value=" + (int)type + "&user=$" + Model.ID, returnTo: this)
                            @:        
                        }
                        <table>
                            <tr>
                                <td style = "border: none; width: 200px; ">
                                    @RenderPage("~/Areas/DLC/Views/Products/ManagementMethod/StoryTreeTypes/_" + Model.StoryTreeType + ".cshtml")
                                </td>
                                <td style = "border: none; ">
                                    @MFCUI.Image("", "/Products/Products/ManagementMethods/_" + type + "Example.png") <br/><br/>
                                </td>
                            </tr>
                        </table>
                    </td>
                </tr>
            </table>
        </div>
    </td>
}

注意

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">
            <tr>
                @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType.cshtml")
            </tr>
            <tr>
                @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType1.cshtml", Product.StoryTreeTypeValues)
            </tr>
        </table>

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

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

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

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

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

@foreach (var currentConfig in PageData[0])
{
    <td style = "border: none; ">
        <div class = "help-sample">
            <table>
                <tr>
                    <td style = "border: none; width: 500px; ">
                        @MFCUI.Image("", PageData[1]) <b>@PageData[2][(int)currentConfig]     </b>
                        @if (PageData[3] == currentConfig)
                        {
                            <b>[当前设置]</b>
                        }
                        else
                        {
                            @MFCUI.Link("[启用]", "/MFC/Configs/AjaxSet?key=" + PageData[4] + "&value=" + (int)currentConfig + "&user=$" + Model.ID, returnTo: this)
                            @:        
                        }
                        <table>
                            <tr>
                                <td style = "border: none; width: 200px; ">
                                    @RenderPage(PageData[5])
                                </td>
                                <td style = "border: none; ">
                                    @MFCUI.Image("", Page[6] + "_" + currentConfig + ".png") <br/><br/>
                                </td>
                            </tr>
                        </table>
                    </td>
                </tr>
            </table>
        </div>
    </td>
}

而接口也变成:

            <tr>
                @RenderPage("~/Areas/Products/Views/Products/SetManagementMethods/_StoryTreeType.cshtml")
            </tr>
            <tr>
                @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/")
            </tr>

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

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

第六步:加入对StatusList的处理

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

        <table class = "noborder">
            <tr>
                @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/")
            </tr>
            <tr>
                @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/")
            </tr>
        </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行代码就能调用出来(故事树、组织结构图、燃尽图、所有菜单(每个菜单都是延迟加载的)……)

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

本人正在参加CSDN博客之星评选,如果读完并喜欢这篇文章,欢迎投票:http://vote.blog.csdn.net/item/blogstar/cheny_com

抱歉!评论已关闭.