表達式樹是LINQ To everything 的基礎，同時各種類庫的Fluent API也 大量使用了Expression Tree。還記得我在不懂expression tree時，各種眼花繚亂的API 看的我各種膜拜，當我熟悉expression tree 后恍然大悟，不用看代碼也能知道別人的API 是如何設計的(^_^)。 接下來這篇博客就談談如何使用expression tree擴展MVC中的HtmlHelper和UrlHelper。
場景
當我們在MVC中生成一個action的url會這樣寫：var url=UrlHelper.Action("index", "Home"); 如果要render一個action時會這樣寫：Html.RenderAction("index", "Home");
這樣的寫法瑕疵在於我們傳遞了兩個字符串類型的參數在代碼中，而我們又免不了對action和controller做重命名操作：index->default, 即便是你用resharper這樣的工具重命名也無法將UrlHelper.Action("index", "Home"); 改變為UrlHelper.Action("default", "Home");
vs甚至在編譯時都不會檢查出來這個錯誤。 所以我們的目標是：設計出具有靜態檢查的API，讓vs 提示出這個錯誤來，甚至是重命名時直接把相關代碼都能重命名。
使用Expression Tree 重新設計這兩組API
目標：設計出類似的API：Url.Action((HomeController c) => c.Index());
1.很明顯我們需要在UrlHelper上寫個擴展方法：
public static string Action<TController>(
this UrlHelper url,
Expression<Func<TController, ActionResult>> actionSelector,
string protocol = null,
string hostname = null)
{
var action = "Index"; //待解析
var controller = "Home";//帶解析
var routeValues = new RouteValueDictionary();//待解析
return url.Action(action, controller, routeValues, protocol, hostname);
}
現在只需要根據表達式Expression<Func<TController, ActionResult>> actionSelector 解析出action,controller,還有routeValues即可
2.解析出controller 的名稱
分析：controller的名稱可以根據泛型方法中的泛型參數TController得到
private static string GetControllerName(Type controllerType)
{
var controllerName = controllerType.Name.EndsWith("Controller")
? controllerType.Name.Substring(0, controllerType.Name.Length - "Controller".Length)
: controllerType.Name;
return controllerName;
}
3.解析action的名稱
分析：由於表達式Expression<Func<TController, ActionResult>> actionSelector 是一個MethodCallExpression, 所以可以很容易得到action的名稱：var action=call.Method.Name;
這樣已經完成了最簡單的url構造方案， 但是我們還沒有處理帶有參數的action類型，例如：Url.Action((HomeController c) => c.Detail(10, 20));
4.解析routeValues
分析：action中的參數實際上就是MethodCallExpression中的參數，我們解析這個expression的參數即可，然后得到RouteValues
private static RouteValueDictionary GetRouteValues(MethodCallExpression call)
{
var routeValues = new RouteValueDictionary();
var args = call.Arguments;
ParameterInfo[] parameters = call.Method.GetParameters();
var pairs = args.Select((a, i) => new
{
Argument = a,
ParamName = parameters[i].Name
});
foreach (var argumentParameterPair in pairs)
{
string name = argumentParameterPair.ParamName;
object value = argumentParameterPair.Argument.GetValue();
if (value != null)
{
var valueType = value.GetType();
if (valueType.IsValueType)
{
routeValues.Add(name, value);
}
throw new NotSupportedException("unsoupported parameter type {0}".FormatWith(value.ToString()));
}
}
return routeValues;
}
如此一來，類似Url.Action((HomeController c) => c.Detail(10, 20));這樣的action也可以構造出Url了。
if (valueType.IsValueType)
{
routeValues.Add(name, value);
}
此代碼並不支持復雜類型的參數，對於action中傳入復雜的類型，比如：
public class User
{
public int Age { get; set; }
public string Email { get; set; }
}
如果Action中的參數使用了User類型：
public ActionResult SayHelloToUser(User user)
{
return new EmptyResult();
}
如何解析呢？
var properties = PropertyInfoHelper.GetProperties(valueType);
foreach (var propertyInfo in properties)
{
routeValues.Add(propertyInfo.Name, propertyInfo.GetValue(value));
}
大功告成，現在已經完美解決了各種類型的參數傳入。
同樣的道理，我們可以擴展HtmlHelper 的 RenderAction(), ActionLink()….
缺陷
早在09年，jeffery zhao就發表了lambda方式生成url的博客，對比了幾種方案的性能問題，並且給出了優化方案,當然，我在寫這篇博客的時候還沒有真正嘗試去優化這個方案，只是再次拜讀了大神的方案，記得早些年就讀過這些文章，但是今天重新讀過仍然獲益匪淺，不由得感嘆幾句，莫非跑題了;-);-)
接下來我會思考這個優化的問題。