简单干净的C#方法设计案例：SFCUI.AjaxValue()之二

先重温一下原则:

最小信息原则：方法接口应只传递最必须的业务信息。

包括两个层面：

1. 技术信息不要暴露

2. 业务信息不能重复

业务信息分析

先别管技术问题，想一想做这个事情需要哪些数据才能完成？

1. 原来的值是多少（显示用）

2. 可能的值有哪些（选择用）

3. 点一个值后，应该执行什么操作（这个是核心业务）

4. 返回后做什么（刷新用）

还有一些问题哪去了？

5. 返回的值刷新到哪里？这个调用者不管，他让我们安排，显示也是我们显示（比如一个DIV），刷新自然就是刷新我们显示的那个位置。

6. 如果返回后什么都不做怎么办？看着办。

最终方法接口设计为：

print?public static MvcHtmlString AjaxValue(int id, string value, string[] values, string urlFormat, string ajaxOnSuccess = null)

怎么多了个ID？因为要显示很多个这种Ajaxalue， 用ID来区分。

urlFormat是什么？他是用来定义生成的Ajax链接的格式的，请看下面的调用（略微存在一些问题的）：

print?@SFCUI.AjaxValue(story.ID, effortValue.ToString(), Effort.EffortPlannedValues, "/SFC/Efforts/AjaxSetEffortPlanned?itemID=" + story.ID + "&value={0}", ajaxOnSuccess: "refreshLeftPad");

这几个参数顺序说明是：story.ID修改谁的值，effrotValue当前值，...EffortPlannedValues可能的值，"...."AjaxLink的href格式{0}里边未来将放着被选择的value，ajaxOnSuccess是正确返回调用的函数。

接口设计原则的分析

从理论上说，在任何 cshtml中放置这句话，就具备了所有的业务信息，剩下的全是技术问题，在这个方法里边解决，外面一概不管，这就叫做“技术信息不要暴露”的子原则。

怎么前面说“略微存在一些问题”呢？因为story.ID在这个里边出现了两遍，第一次是一个整数参数传递进去了，第二次是用来生成了urlFormat传递进去了，第二次多余，应该改成：

print?@SFCUI.AjaxValue(story.ID, effortValue.ToString(), Effort.EffortPlannedValues, "/SFC/Efforts/AjaxSetEffortPlanned?itemID={0}&value={1}", ajaxOnSuccess: "refreshLeftPad");

这样里边在0放置id，1放置value，就能拼凑出AjaxLink来。

现在，再删除任何一个字母和标点符号信息就不够了，这就叫做“业务信息不能重复”子原则。

掌握了这个原则，就能在第一时间确认接口的参数（本人喜欢称之为“外观”），然后开工编写。

当然有时候不能第一次就写出最简练的接口，那么可以尝试先“散装”一下，是一个函数，还是一堆DIV，先写出来再说，写完了，再封装成最简形式。

下一篇，会大致说一下AjaxLink里边的实现。