选择.NET Web框架
文/Jonathan Allen 译/韩锴 出处/InfoQ
过去，为.NET的语言选择一种Web框架并算不上一个问题。你的选择无非就是在纯ASP.NET或者混合经典的ASP和ASP.NET的设计之间进行。尽管这通常都被视为过渡性的做法，而不是一种有意识的选择。但是一旦这样做了，你还要在C#或VB语言之间作出决定。
再看看其他的平台，境况几乎是完全颠倒的。你选择了一种语言后，比如Java、Ruby、Python、Smalltalk等等，针对每种语言都能 找到十多个特定的框架。如果选择了非.NET平台，就意味着放弃了采用多种语言的能力，同时获得了自己挑选最合适的框架的能力。
现在我已经完全不关心那些非主流的东西了，比如
MonoRail。我这样做是因为大多数.NET开发者同样也不关心它们。很简单，没有足够多的人通过使用这些框架来验证框架或者开源的支持是否足够好。想要把ASP.NET程序员手中可用的巨大的控件库和模板重现出来是非常困难的。没有什么其他的.Net Web框架可以做到接近这一点。
事实上，人们可以为.NET辩解说，没有任何一种针对任何平台的Web框架可以做到接近.NET的水平。像
Ruby on Rails等不过是在2006年才开始引入“控件”和“组件（
widgets）”的概念。
但是，在Microsoft的世界里，事情正在发生变化。Ruby on Rails，MonoRail和其他的MVC项目并没有被完全地忽视掉。.NET程序员们嫉妒的声音已经被Microsoft听到了，所以Microsoft正在着手开发一个用于
ASP.NET的MVC框架，它完全放弃了旧的WebForms模型。
随之而来的是一个艰难的选择。你会只为了获得MVC的优势，而放弃你的控件库——包括你自己开发的和购买的？为了摆脱视图状态和命名容器这两个孪生的麻烦（twin evils），值得一切从头来过么？
| 感谢原创者的辛勤劳动，希望对您有所帮助，转载请注明原出处。 |
