NerdDinner分析
NerdDinner的一个优点就是接口设计非常恰当，我觉得编程最有搞头的可能就是接口设计，很多“问题代码”都是接口设计不当造成的。
创建与编辑的方法接口对比：
创建：public ActionResult Create(Dinner dinner)
编辑：public ActionResult Edit(int id, FormCollection collection)
为什么Edit不用Edit (Dinner dinner)这种看起来更简洁的写法呢？首先，Edit页最后是要保存数据的，但这些数据往往不是在页面上完全包含，比如创建日期一般就不会放在编辑页面上。所以Edit方法不能用类似Create的那种接口，而是先根据id来从数据源取出Dinner对象，然后用UpdateModel(dinner);方法更新那些在编辑页面上有的字段，然后再保存到数据源。
接口举例
比如public ActionResult ViewErrorLog(ViewErrorSearchOption searchOption)就是很好的接口设计，因为一进入这个方法就能直接用参数了，public ActionResult CalendarAdmin(FormCollection formCollection)可能是不太好的，是可以进一步改进的接口，因为首先，这个方法的功能不单一，是一碗意大利面（意大利面主要原因并不是某种编程语言（比如Basic）造成的，而是编程者的编程思想，高手即使用汇编也能写出比较容易读懂的代码），里面用了大量的formCollection["XXX"]形式的代码来一个一个获取参数，缺乏对输入参数的抽象。解决方法是从2方面，一是“拆”，即页面改造，用Ajax+PartialView对功能做拆分，二是抽象，对输入和输出参数做抽象，使参数获取和使用简单化。
当一个页面简单的时候，这个页面可能适合整体做，不需要做什么功能拆分和Ajax，比如ViewErrorLog页面。但当页面包含了搜索条件、显示搜索结果、编辑保存等众多功能时，必须拆。拆了会变成几个方块，比如BusinessBranchAdmin。不拆就会变成意大利面，比如CalendarAdmin没有拆。注意BusinessBranchAdmin代码仍然较多，主要是页面上有级联下拉框和较多的页面元素，这里面有很多都是可以进一步优化的，要解决的主要问题是功能重复的时候，代码没有设计成可重用，这其实在开发过程中是正常现象，因为不可能一下子就设计出一个最优的系统，但一直保持这样，一直不去优化，就会给进一步开发及后期维护工作带来巨大工作量和Bug，经常否定自我，优化老代码才能走的顺。
接口代码分析
BusinessBranchAdmin里分成3个方法：
1. public ActionResult BusinessBranchAdmin()方法处理带有BusinessId参数的Get请求，这是一种容错的写法，当没有参数的时候，它会显示NotFound页面,现在感觉是多此一举了，用public ActionResult BusinessBranchAdmin(decimal businessId)更合适，因为这是后台代码，后台一般人不会乱弄个Url乱搞的。正常情况下return View(formModel);
2. public ActionResult Edit(int BusinessBranchId)处理获取Get请求，它由客户端的Ajax代码showEdit方法触发，正常情况下它返回的是一个PartialView：return PartialView("BusinessBranchForm" , info);不过我检查代码时发现了笔误，写的是return View("BusinessBranchForm", info);不过两种写法都能正常运行，不过因为BusinessBranchForm是用户控件，所以用PartialView更合适。数据返回浏览器后由onGetDetailComplete方法处理，显示在divEdit里。
3. public ActionResult Edit(int BusinessBranchId, FormCollection formValues)处理Post请求，由客户端postEditForm方法触发，这个方法里用到了通用提交表单的postForm方法。服务器端处理成功后会return PartialView("EditSuccess");失败会设置错误信息并return PartialView("BusinessBranchForm", info);
整个页面的JS只有非常简短的，一目了然的，可望词生义的5个函数，共25行。
CalendarAdmin里有很多方法，拿最重要的前2个方法为例：
1. public ActionResult CalendarAdmin()，这个方法处理Get请求，既处理最初显示搜索条件的任务，又处理后续的根据参数查询数据的任务，以及分页逻辑等等众多功能，非常不容易看明白。有几个编码问题比较突出：一个是获取参数的GetParamters方法，里面全部是out参数，还有些方法里会改变某些参数的值，这都不是一种好的接口设计,要解决这个问题，最管用的还是“拆”字诀，然后对输入输出数据做抽象。
2. public ActionResult CalendarAdmin(FormCollection formCollection)处理Post请求，处理首次检索任务，里面有非常多与第一个方法相同的逻辑功能代码。我发现里面有一个意大利面的铁证：Goto语句，可见逻辑之复杂。解决方法还是“拆”字诀，拆才能简单化，拆才能清晰易懂。
Html结构分析
结构良好的：
CSS：
<style type="text/css">
.outputTable
{
background-color: White;
width: 100%;
}
.outputTable tr
{
height: 25px;
}
.outputTable th
{
background-color: #C0D6F6;
}
.outputTable td
{
background-color: #ECF3FD;
}
</style>
Html：
<table border="0" cellpadding="3" cellspacing="2" id="divCalendarList" class="outputTable">
<%--<caption>
Search Result</caption>--%>
<thead>
<tr>
<th>dgtStartDateTime
</th>
</tr>
</thead>
<tbody>
<% foreach (SIL.RealStew.DAL.Entities.BusinessBranch c in Model.BusinessBranches)
{ %>
<tr>
<td>
<a href="javascript:showEdit(<%= c.BuBrId %>)">BuBrName</a>
</td>
</tr>
<% } %></tbody>
</table>
结构不好的（class="bold"， height="25"，bgcolor="#C0D6F6"之类的完全可以写在CSS里）：
<table border="0" cellpadding="3" bgcolor="#ffffff" cellspacing="2" id="divCalendarList" style="width: 100%">
<tr class="bold">
<td height="25" bgcolor="#C0D6F6">
<%= Html.Resource("dgtStartDateTime")%>
</td>
</tr>
<% foreach (SIL.RealStew.BLL.Home.Model.CalendarViewEntry c in Model.CalendarList)
{ %>
<tr bgcolor="#ECF3FD" >
<td height="25">
<%= c.CaEnStartDate == null ? "" : ConvertDateTime.ConvertToCurrentDatetimeFormat(c.CaEnStartDate.Value.Date.ToString()) + (c.CaEnStartTime == "00:00" ? "" : "<br>" + c.CaEnStartTime)%>
</td>
</tr>
<% } %>
</table>
多语言代码分析
1. Global.asax里的protected void Application_BeginRequest(object sender, EventArgs e)方法
2. Language类EnvironmentLanguage属性
3. EnquiryLoadManager类的GetTradeDetail方法的language参数可以省去，方法里用语言的时候用Language.EnvironmentLanguage就行了，不需要从外面传进来。需要用Culture的地方，比如格式化日期、货币的地方，用CultureInfo.CurrentCulture就行了。
编程风格分析
1. 最常见的问题是超长的行，比如memberCallCentreModel.CountryList = new SelectList(countryEntityList as IEnumerable, "CountryID", "CountryName", memberCallCentreModel.SearchCountryID);
如果写成以下风格会更有可读性：
memberCallCentreModel.CountryList =
new SelectList(countryEntityList as IEnumerable
, "CountryID"
, "CountryName"
, memberCallCentreModel.SearchCountryID);
2. 代码（特别是Html）的缩进和空行特别乱，就不举例了
3. JS的存放，我并不认为所有的JS都应该放到单独的JS文件，首先有很多JS代码都会用到服务器端变量，直接在页面里写会更方便，假如代码太多，放在页面上就会影响视线了，不容易弄清楚页面结构，适合放在单独的JS文件里。少量代码且用到服务器端变量的适合直接放在页面上，如果不论什么都放到JS文件里，则会增加文件的数量，万一有什么修改的话，还需要打开2个文件对比着看，增加工作量。JS文件缓存可以节省流量，提高速度，但现在带宽都挺高的，一小段JS并不会带来性能问题，反而可以减少请求数，至少能在首次载入时增加速度。
4. int pageSize = int.Parse(ConfigurationManager.AppSettings["PageSize"]);这是典型的HardCoding形式，不利于维护，用我写的SolutionConfig.PageSize可以避免之。
5. 无效代码：即被注释掉的代码，是很影响视线的。我的习惯是在重构时将过时的代码注释掉，当重构完成时，删掉其中的大部分，只留极少数有参考价值的代码。然后每次看到漏删的完全没用的无效代码时，彻底删除之。
通用级连下拉框代码的分析
1. 本示例代码的数据源是Xml文件，集成到数据库里需要做适当改动
2. 在Web.config里配置级联下拉框的Key与Key的层次结构以及Key与数据提供类的映射。
3. 顶级下拉框基础数据提供类需要继承SelectListProviderBase，
比如public class Countries : SelectListProviderBase
4. 有父亲的数据提供类要继承HasParentBase，
比如Cities，Suburbs，Streets
5. 取下拉框数据用DdlFormModel.CreateInstance方法，这个方法有3个重载，一个用于顶级下拉框，一个用于中间级下拉框，一个用于末级下拉框
6. 页面上引入commonddl.js
7. 页面上引用通用级联下拉框用户控件，例如：
<% Html.RenderPartial("GetDdl", Model.Countries); %>
8. 下拉框外层元素的Id命名约定：为内层下拉框Id后加Wrapper。
通用分页存储过程分析
SP名称：Utility_GetOnePage
核心代码：ROW_NUMBER() OVER (order by '+@OrderBy+') as Pos
其它：都是一些拼SQL的语句
注意事项：调用这个存储过程的存储过程必须在最后有Select语句，正常有的没有问题，如果没有，需要加上（一般写成Select 1），因为要兼容Netail工具让其生成返回IDataReader的方法，否则会生成返回void的方法。
调用方法：参考SILCustom_Business_Search存储过程
