在上一篇文章中，我們把繁冗的客戶端腳本變成了可以由Visual Studio提示並輕易輸出的服務器端輔助方法。但是，目前的做法還有不少可以改進的地方。我們編寫輔助方法的目的便是為了簡化開發，因此我們還可以在這條路上走的更遠，讓開發人員可以在使用我們的API時覺得更流暢，更有快感。
簡化入口
目前，我們的輔助方法的使用方法大約如下：
<span>Name: </span> <!-- 必填 -->
<input type="text" name="user.Name" />
<% this.JQuery().Validate().Required("user.Name", "please provide your name!!!"); %>
而內置的輔助方法是這樣使用的：
Html.ActionLink("Home", "Index")
比較兩者就可以看出差別：
由於只有“擴展方法”沒有“擴展屬性”，因此JQuery後面的括號不可少。
由於利用了“擴展方法”，因此前面this關鍵字無法省略。
從某些角度看來，這麼做其實並不會造成太大差別。不過在老趙看來，我們在前端定義視圖時，我們並非在使用C#進行開發，而是在使用一種DSL——當然，是C#實現的Internal DSL。例如，在上面的代碼中訪問Html時，老趙並沒有過分認為這是一個“屬性”。在設計DSL，尤其是Internal DSL的時候，我們往往都需要考慮到實際需求，盡可能得到更加優美的語法。這樣看來，this關鍵字和“作用不大”的括號也像是一種累贅。因此我們做的第一件事情，便是簡化輔助方法的入口。
造成“累贅”的關鍵性因素便是“擴展方法”這個特性，但是如果我們要去除擴展方法的使用，就必須把“入口”直接定義在ViewPage中，這就要求我們的視圖繼承我們定義的基類，而不是直接繼承ViewPage。這一點看上去是額外的工作，但是在實際項目中由於自然需要，我們一般都會定義這樣的類型。而即使您的項目還沒有自定義的基類，也建議您從一開始便采取這種做法。因為隨著項目的發展，您很可能在某一時刻就發現您很渴望有一個統一的地方可以處理一些相同的邏輯，如果您這時再去修改項目中所有的視圖，這會是一件勞民傷財的事情。相反，如果您一開始便定義了共同的基類，那麼進行這種功能補充就會變得輕而易舉。而且，即使您沒有為基類添加任何功能，也不會造成任何損失。
目前，我們的基類只需要定義一個JQuery屬性便可：
namespace MvcApp.Views
{
public class ViewPageBase : ViewPage
{
private JQueryHelper m_jquery;
public JQueryHelper JQuery
{
get
{
if (this.m_jquery == null)
{
this.m_jquery = new JQueryHelper(this.ViewContext, this);
}
return this.m_jquery;
}
}
}
}
由於不同的Page對象已經為我們做好了分離，我們已經不需要把JQueryHelper對象放在Page.Items集合中了。而現在，我們便可以使用這樣的方式來改寫之前的代碼：
<span>Name: </span> <!-- 必填 -->
<input type="text" name="user.Name" />
<% JQuery.Validate().Required("user.Name", "please provide your name!!!"); %>
您是否覺得更清楚了一些呢？
