2010-08-13 27 views
1

看看下面這個例子的代碼,從Telerik的MVC網格:方法鏈相比普通的命令式方法調用有什麼優勢?

<% Html.Telerik().Grid(Model.InstallerList) 
    .Name("InstallerGrid") 
    .DataKeys(key => key.Add(c => c.InstallerID)) 
    .Columns(column => 
    { 
     column.Template(action => 
      {%> 
       <%= Html.ActionLink("Edit", "Edit", new{ id = action.InstallerID}) %> 
      <%}); 

     column.Bound(model => model.CompanyName); 
     column.Bound(model => model.EmailAddress); 
    }) 
    .Scrollable(scrolling => scrolling.Enabled(true)) 
    .Pageable(paging => paging.Enabled(true)) 
    .Sortable(sorting => sorting.Enabled(true)) 

    .Render(); %> 

現在,什麼是關於比做得這樣好:

<% 
    var grid = Html.Telerik().Grid(Model.InstallerList); 
    grid.Name("IntsallerGrid"); 
    grid.DataKeys(key => key.Add(c => c.InstallerID)); 
    // etc. etc. 

    %> 

回答

2

Fluent接口意味着是一種內部域特定語言。如果執行得好,他們可以像自然語言句子一樣閱讀。

在Martin Fowler的bliki上有一篇非常好的文章,詳細說明了利弊。

請注意,Fowler(提出了該名稱)建議將流暢接口分層放置在更標準的API之上。流暢的接口中斷CommandQuerySeparation

0

這些被稱爲"Fluent Interfaces"

假設的好處是可讀性和可發現性或代碼,雖然具有良好的智能感知,但這些可能不會帶來最大的好處。

代碼變得更加嚴密,編程風格變得更加陳述 - 你說你想要發生什麼,而不是你希望如何發生。在這方面它有助於抽象。

就結果而言 - 無差異。這只是個人喜好的問題,作爲供應商的Telerik提供的選擇與商業意義相同。

3

有沒有real區別,在這種情況下是,它們只是讓你通過鏈接返回引用。優勢?它更簡潔,你不必自己維護一個參考,除了它比其他任何東西更關注風格。

當Telerik們轉換爲jQuery(也鏈接)他們的許多組件的客戶端腳本時,流暢的界面開始爲他們顯示出來,他們只是喜歡這種風格並將其作爲選項提供。

現在,在其他情況下,一個方法可以返回引用或類型的一樣grid,例如如何.OrderBy()返回OrderedQueryable,而不僅僅是一個Queryable,在這些情況下有行爲上的電位差,因爲您沒有在每個語句的示例中設置grid =結果。

2

同上「人們稱這些爲‘流利接口’。」

一個很大的好處是避免不必要的方法參數,尤其是構造函數。例如,蛋糕可能會結冰,而糖霜可能會寫上字。

你去

Cake cake = new Cake(Icing.None, ""); // no icing, no words 
    Cake birthday = new Cake(Icing.None, "Happy Birthday"); // invalid option! 

或可愛流利的風格;

Cake cale = new Cake(); // No icing, no words 
    Cake birthday = new Cake().Icing(Icing.Chocolate).Word("Happy Birthday"); 
+0

應該注意的是.Net 4+參數可以是可選的:) – 2010-08-13 11:06:21

0

那些方法鏈的返回類型可能不一定是原始網格。另外,在完成這些工作後,並不是所有的人都可以很容易地表達出來或者很有用。使用方法鏈可以使事情保持緊密,並且容易在將來進行更改。

相關問題