与普通的命令式方法调用相比，方法链接有什么优点？
看一下来自 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.
%>
Look at this example code, from a Telerik MVC grid:
<% 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(); %>
Now, what is better about that than doing it like this:
<%
var grid = Html.Telerik().Grid(Model.InstallerList);
grid.Name("IntsallerGrid");
grid.DataKeys(key => key.Add(c => c.InstallerID));
// etc. etc.
%>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
没有真正的区别，在本例中，它们只是让您通过返回引用来链接。优势？它更简洁，您不必自己维护参考，除此之外它更多的是关于风格而不是其他任何东西。
当 Telerik 的人将他们的许多组件中的客户端脚本转换为 jQuery（也链接）时，流畅的界面开始出现在他们面前，猜测他们只是喜欢这种风格并将其作为一个选项提供。
现在，在其他情况下，一个方法可能会返回一个与
grid不同的引用或类型，例如.OrderBy()如何返回一个OrderedQueryable而不仅仅是Queryable，在这些情况下，行为上存在潜在差异，因为您没有设置grid =结果每个语句的示例。There's no real difference, in this case, they just let you chain by returning the reference. The advantage? It's more terse and you don't have to maintain a reference yourself, other than that it's more about style than anything else.
When the Telerik guys converted to jQuery (which also chains) for their client-side script in many of their components fluent interfaces started showing up for them, guess they just liked the style and offered it as an option.
Now in other cases one method may return a reference or a type that's not the same as
grid, for example how.OrderBy()returns anOrderedQueryablerather than just aQueryable, in those cases there is a potential difference in behavior, because you're not settinggrid =the result in your example for each statement.流畅的界面是一种内部领域特定语言。如果实施得当，它们可以像自然语言句子一样阅读。
Martin Fowler 的 bliki 有一篇非常好的文章，详细介绍了优点和缺点。
请注意，Fowler（这个名字的提出者）建议将流畅的接口置于更标准的 API 之上。流畅的界面打破了 CommandQuerySeparation。
Fluent interfaces are meant to be a type of internal domain specific language. When implemented well they can read like a natural language sentence.
There's a really good write-up on Martin Fowler's bliki that covers the pros and cons in detail.
Note that Fowler (who came up with the name) recommends that the fluent interface be layered on top of a more standard API. Fluent interfaces break CommandQuerySeparation.
同上“人们将这些称为“流畅的接口”。”
一个很大的好处是避免方法中不必要的参数，尤其是构造函数。例如，蛋糕上可以有糖霜，糖霜上可以写有文字。
你追求
还是可爱的Fluent风格；
Ditto " People refer to these as "Fluent Interfaces". "
A great benefit is to avoid unnecessary parameters in methods, especially constructors. For example a cake can have icing, and icing can have words written on it.
Do you go for
or lovely Fluent style;
这些称为“Fluent Interfaces”。
所谓的好处在于可读性和可发现性或代码，尽管具有良好的智能感知，这些可能不会带来最大的好处。
代码变得更加紧凑，编程风格变得更加声明式 - 您说出您想要发生什么，而不是您希望它如何发生。在这方面，它有助于抽象。
就结果而言 - 没有区别。这只是个人喜好问题，Telerik 作为供应商提供尽可能多的选择，以实现商业意义。
These are called "Fluent Interfaces".
The supposed benefits are in readablity and discoverablity or code, though with good intellisense these may not give the most benefit.
Code becomes a lot more tight and the style of programming becomes more declarative - you say what you want to happen, instead of how you want it to happen. In this respect it helps with abstraction.
In terms of the results - no difference. It is just a matter of personal preference, and Telerik as a vendor offer as much choice as makes business sense.
这些方法链的返回类型不一定是原始网格。此外，在您完成它们之后，并非所有这些都可以轻松表达或有用。使用方法链可以使事情变得紧凑并且将来易于更改。
The return type that those methods chain may not necessarily be the original grid. In addition, not all of them may be easily expressible or useful after you're finished with them. Using a method chain keeps things tight and easy to change in the future.