The benefit of this approach is by using code generation, you get strong typing everywhere and it doesn't require compiling expressions which can hurt performance.
I've been using it for about 1 month now and really like it. For instance, I love the new strongly typed Html helpers, it sure beats using magic strings:
<%= Html.TextBoxFor(m => m.User.FirstName)%>
According to the MVC roadmap, this feature will be part of MVC 2, but even if it shouldn't, I still have the futures source code so I can use this helper implementation as a last resort.
I think it has some features that really should be in the MVC library but I would stay away from the strongly-typed action links. That can get extremely expensive on the CPU potentiall9y adding SECONDS (not MS) to your page render time.
One of the functions available in MVC futures I often find myself using is RenderAction since it is the only way to worka around partial output caching.
发布评论
评论（5）
首先，仅仅因为它是一个字符串，并不意味着它就是一个“神奇”的字符串。 其次，我建议查看 David Ebbo 在这里写的 T4MVC 模板：http://blogs.msdn.com/davidebb/archive/2009/06/17/a-new-and-improved-asp- net-mvc-t4-template.aspx。
这种方法的好处是通过使用代码生成，您可以在任何地方获得强类型，并且不需要编译可能会损害性能的表达式。
First of all, just because it's a string, doesn't make it a "magic" string. Second of all, I would recommend looking at the T4MVC templates David Ebbo writes about here: http://blogs.msdn.com/davidebb/archive/2009/06/17/a-new-and-improved-asp-net-mvc-t4-template.aspx.
The benefit of this approach is by using code generation, you get strong typing everywhere and it doesn't require compiling expressions which can hurt performance.
我已经使用它大约 1 个月了，非常喜欢它。 例如，我喜欢新的强类型 Html 助手，它肯定胜过使用魔术字符串：
根据 MVC 路线图，此功能将成为 MVC 2 的一部分，但即使不应该，我仍然有 futures 源代码，所以我可以使用这个辅助实现作为最后的手段。
I've been using it for about 1 month now and really like it. For instance, I love the new strongly typed Html helpers, it sure beats using magic strings:
According to the MVC roadmap, this feature will be part of MVC 2, but even if it shouldn't, I still have the futures source code so I can use this helper implementation as a last resort.
使用 ASP.NET MVC Futures 的功能的风险是，
The risks of using features from ASP.NET MVC Futures are
我认为它有一些确实应该在 MVC 库中的功能，但我会远离强类型操作链接。 这可能会导致 CPU 成本极高，可能会导致页面渲染时间增加几秒（而不是毫秒）。
http: //www.chadmoran.com/blog/2009/4/23/optimizing-url- Generation-in-aspnet-mvc-part-2.html
我经常使用的 MVC future 中可用的功能之一是 RenderAction，因为它是解决部分输出缓存的唯一方法。
I think it has some features that really should be in the MVC library but I would stay away from the strongly-typed action links. That can get extremely expensive on the CPU potentiall9y adding SECONDS (not MS) to your page render time.
http://www.chadmoran.com/blog/2009/4/23/optimizing-url-generation-in-aspnet-mvc-part-2.html
One of the functions available in MVC futures I often find myself using is RenderAction since it is the only way to worka around partial output caching.
对未来不太确定，但我强烈推荐 Mvccontrib 库，它依赖于期货。
Not so sure about the futures, but I would highly recommend the Mvccontrib library which depends on some bits in the futures.