3 ms·
I guess I owe an explanation. Most significantly, much of the Rails magic comes from Ruby. So when you say the two (WebForms and ASP.NET MVC) aren't alike, its
by latch 16y ago
I guess I owe an explanation.
Most significantly, much of the Rails magic comes from Ruby. So when you say the two (WebForms and ASP.NET MVC) aren't alike, its like you are forgetting that they both use C#. The DLR is a small step, but it isn't in the same league. We can disagree that Ruby is such a significant productivity boost over C# - that's fine. But, if you think language is completely irrelevant, then imagine an MVC framework like ASP.NET MVC where you had to code your HttpModules, HttpHandlers, controllers, models and data access code in C. Concrete example? You don't do DI in a Rails app...yet it permeates through any WebForms/MVC app you write.
Then there's the tooling. WebForms and MVC share the same deployment and package management. Both are young and inferior to Cap and Gems (but they are young and they've done a good job with it so far). They are both hosted on IIS and essentially deployed/configured/managed the same. WebForms and MVC share the same IDE.
Then there's community. ASP.NET MVC and WebForms generally have access to the same libraries (nUnit, NHibernate, JSON.NET), the same resources, and the same community leaders (hey, I was one of them!)
So far, ASP.NET MVC and WebForms share: Language, Community, Tools, Libraries and deployment story. None of these are shared with Ruby.
Let's talk about code. Neither ASP.NET MVC nor WebForms have a cohesive model/data access story. Microsoft doesn't really provide an "M" with ASP.NET MVC. You can pick DataSets (oh wait, we don't like that anymore), or Linq2Sql (oh wait, we don't like that anymore), or Entity Framework (lolz) or NHibernate. Or, you can use Castle's ActiveRecord. None of these are very similar to Rail's ActiveRecord. So, when it comes to modeling and persisting your data, WebForms and MVC are exactly the same - which happens to be quite different than Rails.
WebForms and MVC share HttpHandlers and HttpModules/Global.asax. These are pretty nice (especially managed HttpHandlers in IIS 7). They also share the same built-in configuration management. But those are, yet again, something they share with each other, not with Rails.
Controllers? Ya, ASP.NET MVC shares more in common here with Rails than it does with WebForm's page model. And I agree this is pretty substantial..but even under the covers, things aren't all the similar. Email sending is very different (in Rails it builds on top of the controller core, which is why I include it here). Routing, model binding, validation...ASP.NET MVC and Rails are more similar than ASP.NET MVC and WebForms...but they still aren't that similar.
Views? ASP.NET MVC shares some stuff with Rails, but easily as much with WebForms. Asset management (or lack thereof), nested layouts...
Honestly, the only thing the two share in common is a controller with actions. And, when you look at typical ASP.NET MVC code, controllers/actions tend to do a lot more than than an equivalent Rails actions.
ASP.NET MVC shares more with Silverlight or WinForms development than it does with Rails.
EDIT:
Somehow in all that I forgot to mention that WinForms and MVC share the same framework (.NET) and runtime (DLR/CLR). Neither of which is anything like what Rails runs on.
- arethuza 16y ago"ASP.NET MVC shares some stuff with Rails, but easily as much with WebForms." It's pretty simple to make ASP.NET MVC to use a different view engine (I prefer String Template, but there are plenty others) - arguably that pretty much removes any lingering flavor of the WebForms.
- latch 16y agoI see how changing the view engine addresses the 10 bigger points that I made.
- city41 16y agoYour 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.