简单干净的C#方法设计案例：SFCUI.AjaxLoadPage()之二
合并显而易见的代码
所谓显而易见的代码，就是看上去和别处相同的代码。
在这个例子中，就是View‘中初始页面显示的内容与未来刷新的内容重复；Controller中初始显示的运算和刷新的相同。
Controller好办，如此：
而cshtml页面中，只需要添加一个在页面初始化时自动刷新的函数，就能把<div id = "leftpad">变成空的，由刷新页面来填充。代码变成：
$(document).ready是多出来的代码，负责第一次初始化时填充<div id = "leftpad>的内容。
封装多余的技术代码
何为多余的技术代码？之前在AjaxValue系列中曾经提到过接口封装的两个原则：
最小信息原则：方法接口应只传递最必须的业务信息。
包括两个层面：
1. 技术数据不要传递
2. 业务数据不能重复
现在，先从业务角度分析，这个函数接口设计中，到底哪些信息是必须的；让我们来用这一原则，把上面最后的一段cshtml代码，变成一行代码。
1. 如果要刷新，应该调用什么函数（一般是一个JS函数，提供给左边的红框，红框运行成功，就调用这个JS函数）
2. 用于刷新页面的Ajax Url（上述JS函数被调用后，应该到哪个Url获取刷新内容）
3. 刷新成功后，要继续执行什么操作（另外一个JS函数，比如刷新的内容“错过了document.Ready”要重新套用一下——尝试了live功能，不知道为什么无效；或者要串联刷新多个区域，本例中没有）
没了（后面还会看到一些，不过是为了别的功能）。有几个东西是多余的：
1. $(document).ready.....，因为每个AjaxPageLoad都执行，所以是固定的，不用作为参数传入接口。
2. function refreshLeft() ...{ $"#refreshLeft")....，因为这个按钮是多余的，并不需要人手去点击，只是函数实现中的一个步骤而已。换言之这个按钮叫什么都无所谓，只要ready / function / SFCUI.Link(id: ...)中出现的值相同就行，无需人工指定。
3. <div id = "leftpad"></div>也是多余的！因为既然在这里写下那一行代码，就在代码处LoadPage，至于Load到什么东西里边，ID叫什么，都无所谓。
所以，接口调用应该是：
这句话是一个helper，将负责生产前面代码中提到的<script>及其中的两个函数ready和refreshLeft、中间的<div>@SFCUI.Link中的Ajax调用</div>、最后的<div id = "leftpad">
下面是Helper的源代码，里边多了一些参数，最后解释：
1. 先看突然跳出来的int id = _rand.next()
之前提到，我们有很多“随便”的变量，比如那个"refreshLeft"，叫什么都行，外界不关心。但是如果设为常数，则如果在同一个页面上放两个LoadPage的时候，会打架，所以用个Random生成ID。为什么用static 的呢？因为Random的生成机制，是利用调用时的系统时间作为“种子”，从种子产生下一个随机数。如果调用时间间隔为“0”，就会产生出相同的种子进而相同的随机数。static就没有这个问题了，大家用一个，顺着排。
总之，随机的id代替了"refreshLeft"这个本来需要传进来的“变量”。
2. TagBuilder script则直接在代码上方产生一段script，免去了编写script的工作。
为什么要判断refreshFunction为NULL的情况呢？因为有一种场景不会重复刷新。
在我的项目中，菜单极其复杂，产生菜单的时间，甚至比页面本身都长。但我们也不像牺牲强大的菜单换取性能，怎么办呢？子菜单延时产生！
由于人们在页面出现后的1～5秒内都不会操作菜单（要离开这个页面时才会操作），所以我们设置所有繁重的子菜单都使用AjaxLoadPage加载，而且注意最后一个参数timeout，它们多数在1000毫秒后才加载，那时候页面早就爽快地展示在用户面前了。
这种场景，不会有人刷新菜单了，所以就不用RefreshFunction这个参数。
3. TagBuilder pageContainer 代替了原来最后的<div id = "leftpad">，它的id也是随机生成的，但是由于1、2、3中保持了id的互相照应，虽然外界看不到，但是内部却顺畅运行。
4. 最后多了个style，是我们加载菜单时的需要，这里就不多说了。
尾声
合并显而易见的代码是初级程序员的基本功，也是产品代码的基本要求；封装多余的技术代码难度较大，但是只要用心，上述提到的原则也没有做不到的。
为什么要费劲封装呢？散装的代码对程序员要求低，只要好好测试，功能相同，也不会出现缺陷，不也一样吗？
在16年的IT从业中我发现，所有最后开发面临崩溃的软件，很少有受到单个技术难题或缺陷困扰的，多数都百病缠身；而百病缠身的主要问题，是可维护性差；而可维护性差的主要原因，是代码臃肿重复，尤其是似重复而不重复。
封装后，则：
1. 总是使用同一段代码，易于维护。
2. 总是重复使用，代码的质量有保障。
3. 一个地方发现缺陷，修改代码后可以同时避免多个地方的缺陷。
4. 在无需深入到技术层面的时候，可以方便地在业务层面阅读代码。
5. 把时间花费在深究代码的封装上，比重复码字要有趣得多。
……
在之前的IT职业生涯的“危险职业”系列中有很多人提到：“我一直在做重复劳动，没有积累，是不是很危险？怎么办？”其实万事万物看似重复，其实不重复。本人从事Web编程只有一年多（其中只有6个月的编程量超过总工作量的50%），Jquery上上个月刚大致弄明白，但是我相信很多Web编程很久的程序员都不会封装这些代码的，而是“重复地”拷贝粘贴代码。
所以实际上，没有重复的工作，只有重复的工作心态。
之后我会写一篇关于“重复劳动中如何提高”的IT职业生涯系列文章。
