Your argument is mostly that ASP.NET classic and ASP.NET MVC are similar because they come from the same technology stack. The same argument suggests that WinFo

Your argument is mostly that ASP.NET classic and ASP.NET MVC are similar because they come from the same technology stack. The same argument suggests that WinForms and WPF are similar to ASP.NET MVC too. Everyone was surprised by your initial comment because hardly anyone expected anything different from this. Of course ASP.NET MVC uses the CLR, C#, IIS, etc. That's entirely to be expected. It's also a technical detail and doesn't get at the heart of what ASP.NET MVC is really trying to be and the type of development model it is putting forward. Which I would argue is far more important and pertinent than the fact that ASP.NET MVC still uses web.config files. ASP.NET MVC was written to be flexible, testable (this was paramount), and focus on separation of concerns. Even well written classic ASP.NET applications are very difficult to test. To accomplish this MVC was forced to use a lot of interfaces and yes dependency injection. But that's an artifact of the language and again not a surprising fact at all. Ruby is capable of things that C# can only dream of. And when C# 6 or 7 finally make it possible, it will come with awful syntax and more stuff thrown into the kitchen sink language. So yes, Rails can win big things here because of Ruby. ASP.NET MVC can't win big things here because of C#. Although it's not as bad as you make it out to be. But again, no one is surprised by this. Don't forget a major focus of Rails 3 was to decouple things and make them more modular -- Make it easier for developers to choose a data access layer other than ActiveRecord if they wanted to. I'd strongly argue Microsoft looked at Rails 1 and 2 and wisely made the choice to not strongly couple a data access layer into MVC.