过去，为.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），值得一切从头来过么？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论