So ASP.NET MVC Preview 4 is about to hit the streets. I have been watching, waiting, hoping that the ASP.NET effort at copying Rails would be so compelling that I could stomach investing in .NET programming again.
The new preview 4 features:
- filter interceptors (before + after hooks for controllers)
- outputcache filters (action caching)
- handle error filters (custom error page)
- authorize filter (role-based authorization)
- accountcontroller class (wrapper to ASP.NET membership API)
- minor improvement to testing
- some ajax stuff
They are incorporating community-driven features, which is good. But I don’t think the project has anywhere near the velocity it needs. It’s taken them 2 months to get this new functionality out the door… I’m not very excited, because it’s hard not to compare what’s going on to present-day Rails, which is years ahead.
The big concerns I have about ASP.NET MVC are:
- still not opinionated enough. Rather than simplifying .NET web development, they are giving more choices
- the names they are giving features… ugh! Give me the silly Rails “plugin_fu” and “sexy_plugin” names any day vs. filter, filter, filter
- documentation not at your fingertips—maybe it’ll get there, but I bet there will never be a docs site for ASP.NET MVC as simple + easy to use as RailsBrain
- no plugin system that I’ve heard about
- not Restful… /:controller/:action/:id is so 2005. And I suppose for webservices, they still want developers to use SOAP?
I actually want the project to succeed, because it’s tough for organizations who have invested in .NET system to consider switch. And I want my .NET friends to be happier. They truly don’t know what they’re missing in the amazing Ruby community—Rails, Github, Merb, nginx/thin, Sinatra, Radiant, Shoulda, RSpec, and literally dozens of other interconnecting projects.
Objectively speaking ASP.NET MVC is unnecessary because postback/code-behind approach is superior, one look at spaghetti-coded views in MVC model is proof enough. ASP.NET MVC’s raison d’etre is to woo those developers who are fed-up with their amateurish, buggy and incomplete open-source frameworks and are therefore looking for a way out without abandoning MVC.
At least with Microsoft they will get software professionally written & tested so there will be less chance of boxing themselves in when non-trivial problems arise. And if things do go wrong, Microsoft is required to fix any bugs under proper commercial licence, there is no such obligation in open-source world.
Let me get this straight, your main concerns are:
1. Too many choices. I’m suprised to actually see someone wanting MS to shoehorn you in more. Choice is good. It would be ridiculous to force all .NET away from postbacks…
2. Naming? could you have a more inane complaint?
3. Documentation is a valid concern, although MS is known for creating very robust documentation, and the community is pretty good already, and it’s not even in beta.
4. Plugins can be written by competent developers but remember, this is not an attempt at a highly obfuscated claustrophobic framework like rails, with more flexibility you must create more. I’ll take the flexibility, rails is too limiting.
5. Not understanding .NET url routing does not make it 2005. If you think routing is confined to that you hardly qualify as a voice to provide a real review.
In all your post reads as a rails fanatic that wants the ASP.NET MVC be rails for .NET. Its not, it won’t, and in many ways its good that it doesn’t. It doesn’t make the same mistakes rails makes, its not something that scales poorly. While everyone’s opinion is valid, I would hope that noone takes this too seriously.
I’ve got to go with Jeremy, particularly about the routing and REST. A MapRoute something like this gets you some pretty RESTful setups. The patterns in the URL are entirely up to you. That “controller/action/id” is there as a default route in the Visual Studio project is by no means the limit of what you can do.
routes.MapRoute( “CollectionCreate”, “{controller}/create”, new { action = “create” }, new { httpMethod = new HttpMethodConstraint(“PUT”) } );
@Wheelwright
rails views are not spaghetti-code! you can make it as succinct as you want to through partials + helpers
really try to go out and understand how github works. If anyone doesn’t like how Rails (or any of its plugins work) you can simply fork the project, change what you want, use it. If the original author likes your changes, he can pull them into the main project. Or your “next generation” project might become the new standard.
@Jeremy B
if postback model sucks, kill it
code readability matters
Rails isn’t a highly obfuscated, claustrophobic framework… claustrophobic? wtf…
I know that /:controller/:action/:id is simply default routing, as it is in Rails. But Rails has evolved past that with a solid model (REST), and ASP.NET MVC lets you roll your own, just like early Rails. You’ll catch up, someday.
General thoughts here:
Postback doesn’t suck. It’s great for internal “throw away” apps, which there are a ton of.
My feeling is MVC will be used by maybe 15% of asp.net developers in 5 years, I wish MS would concentrate more on making postback less suckish (smaller viewstate, open sourcing their controls or giving us the ability to change how things render, simplifying page lifecycle, etc…)
I really like MVC for the rest of the web languages, especially PHP (CodeIgniter is my choice), but I’m not entirely convinced it’s better then postback to start with. My .aspx have NO business logic in them, I guarantee your .erb files can’t say that :)
“postbacks don’t suck” but they are “suckish” :)
no business logic in .aspx, even in your “throwaway apps”?
the beauty of MVC is that business logic is kept 2 levels from the views – there is never business logic in *my* .erb’s – maybe a little bit of ruby code (if/then or loops) that is easily re-factored to a partial view or a helper, when the page gets a little too long (when it scrolls off 1 page of text in my editor, is my rule).
No business logic in .aspx files. Codebehind acts as controller, data layer is in /App_Code directory. Certainly not as reusable as standard MVC controllers, but it does separate business logic from the view.
if/else sounds like business logic to me :)
I do agree MVC is the way to go with PHP or Ruby, just not entirely convinced for asp.net
Summary: It’s not rails.
I guess that is a pretty succinct summary Allori ;)
“I know that /:controller/:action/:id is simply default routing, as it is in Rails. But Rails has evolved past that with a solid model (REST), and ASP.NET MVC lets you roll your own, just like early Rails. You’ll catch up, someday.”
Ok, so I’ve worked w/ both Rails and MVC. I think MVC is definitely less mature, but.. being less than a year old, and not even in Beta yet, my response is “So what, it should be”.
The comment I quoted above makes no sense. The URL pattern alone does not define REST/non-REST; /controller/action/id is a perfectly RESTful URL. I’m not remotely clear on how being more flexible would require ASP.Net to ‘catch up’ to Rails’ URL routing… what exactly is backwards about having choice?
The main difference I can see between the MVC implementation of ASP.Net and Rails is that Rails more or less enforces the “convention over configuration” thing, ASP.Net MVC recommends it, but doesn’t enforce it. That, to me, is a good thing, not a thing that requires “catching up”.