MVC3 + code-first from the EF4 CTP makes throwing together proof-of-concept apps very fast (and painless!). You don't have to do much besides design your models and you get a functioning site to start with.
MS is still advocating task centric UIs? I've hated crap that since they started filling Win7 with vague, ambiguous buttons like "Setup a new network", "Connect to a network", "Connect to the Internet", "Connect to a workplace"... You have to click them to find out what they actually do.
That is a fair point, though I don't think the "task centric" approch can be held accountable for the issues with the design of the windows control panel. This is probably because control panels are not about "tasks" but settings and so it is a terrible paradigm for that.
I agree with you completely regarding model changes; I hope it gets fixed in the next CTP (or beta if they're close enough).
As to the generated UI, it's pretty similar to what you get with Rails scaffolding. I haven't spent a ton of time with it so you may know better than me, but it's nice having the default views generated while wiring everything together and then changing the generated views to build something a little more useful (the same way you'd do with scaffolded Rails objects).
As for point 2., I think you can generate the UI from any model class, right? So you can create a model for each task and generate the scaffolding for that particular model.
Hmmm, interesting idea. Lets say I have a 'change product price' task. ASP MVC will generate controllers/views for CRUD operations and a list. Those don't look very useful.
Actually, if your model has ProductID and NewPrice you can create just the Update controler/view for that. Put some validation on the model, and the scaffolding is done.
Or you could write the form itself with the "EditorFor" helper methods, either for the whole class or for each field.
It's not perfect, but good enough for a quick prototype or first version.
Just to offer a different road, you could do something like that with the previous version of MVC + Fluent NHibernate with automapping and schema_update, if I'm not mistaken :)
Here's a interesting technical interview with Andrew Nurse who created the Razor View Engine for ASP.NET MVC 3. In the interview, he said Razor was his first project once starting at Microsoft.
Word of warning that I found and ScottGu confirmed in the comments of his blog post, if you have the Async CTP bits installed and you install MVC3 RC you will lose the ability to use the watch windows during debugging. Just a heads up to make sure you only have one or the other installed for right now.
I think you shouldn't over-think the question. If you already know C# but are new to Ruby/Django/PHP, it's probably better to go with ASP.NET. I personally go with ASP.NET for the intellisense and refactoring support of Visual Studio. The main drawbacks for me are that deployment is more difficult and expensive than other frameworks.
For kicks, I deployed the same app on Ubuntu 10.04 and Windows 2008 R2 micro instances on AWS. I chose the plain Windows instance - with no software ( ie, IIS & .NET) pre installed. No database is used in this app.
I had the mono/Ubuntu version up and running in about 30 minutes. The longest part of the install was that I chose to use Mono 2.6.7 which isn't officially supported, so you need to do some work to install it. The app was deployed using FastCGI and Nginx.
It took about 90 minutes to get the Windows 2008 version running. Most of which time was spent waiting for the instance to start and waiting for the bloody Platform Installer (worst app ever!) to do whatever it does.
The moral of this story: the Windows micro instances are unusable. But to scale vertically, use Windows. To scale horizontally, or if you are cheap||frugal, give mono/Ubuntu a shot. Can't wait to see what moving to LLVM is going to do to mono's performance.
When you work for a company that already runs on MS infrastructure.
Jeff Atwood of StackOverflow also claims that they have much lower server requirements because C# inherently runs faster than non-compiled languages such as ruby/python/php, but of course there is some debate about whether that balances out the higher cost of IIS/SQLServer licenses.
I'm not an expert in ASP.NET MVC and I'm not a hater either -- but it doesn't seem to offer anything that Rails doesn't (other than aforementioned runs-on-MS-stack and compiled language).
Would love to hear other opinions from people with more .Net MVC experience, though.
That's a pretty fair question. In my opinion, the only reason to go with ASP.NET anything is if you already know C# (or any other .Net language).
Otherwise, Rails, Django, Flask, Cake, etc are going to be significantly easier to get up to speed with, have better communities, have less murky IP situations and are generally going to be less expensive to develop for and to hire developers for.
There are advantages to the CLR world - Tooling is top notch (Mono's tools are lacking right now but seem to be improving quickly), there is a reasonable amount of documentation, even though some of it is of questionable quality. C# performs well, both on Mono and .Net. There are many libraries available (although the quality of the libraries can sometimes be lacking). Many of the higher quality libraries are closed-source commercial libraries. Some of the worst ones are also closed-source commercial packages, so it pays to do research prior to purchasing anything.
The community has been warming to open source - in my opinion this is largely due to the efforts of Miguel de Icaza and everyone working on the Mono Project. (As an aside, if you don't like asp but you do like C#, you should consider checking out and contributing to Manos de Mono, a Mono based web framework which is still in its infancy - https://github.com/jacksonh/manos .)
Microsoft is, and always will be a for-profit company that makes money from selling its software. It has a vested interest in creating platform lock-in, but developers don't have to stick to the Microsoft way of doing things if they choose not to, thanks to the strength of Mono today. Either way, Microsoft is pretty up-front about what the cost of doing business is with them; and they have proven to be pretty consistent with their pricing.
Politics and profits aside, C# is an enjoyable language to use. I haven't spent time with F# yet, but I understand it's quite enjoyable as well. The C# team has done an excellent job of paying attention to programming trends and adopting techniques from other languages. The transition from 1.1 to 2.0 was kind of clunky, but since then they've shown a great deal of good taste in what they've implemented as well as how it's been implemented. Of course, the downside is that C# is a large and complex language. I think the most recent "C# in Nutshell" book is well over a thousand pages.
I have production code deployed in Python, PHP and Clojure, but I'm currently migrating back to .Net for my personal projects. C# developers get an excellent cross-platform deployment story thanks to Mono (MonoTouch, MonoDroid, MonoMac). Honestly, I think Mono runs on pretty much everything from PC, Mac & Linux to WP7, iPhone and Android; as well as game consoles, embedded hardware, etc.
Additionally, many of the new to .Net technologies coming out of Microsoft right now such as F#, C# 5's async framework, MVC3 and Entity Framework 4 are very compelling. Microsoft is kind of a dorky company, but in my opinion they are producing pretty good software right now.
The mvc team is a breath of fresh air, no question. But I'm surprised to hear someone who knows RoR say that they are "pretty close".
There's more to dynamic programming than the dynamic keyword. I don't want to get into which is better, but to say that C# is even in the same league as Ruby for dynamic programming, because of the dynamic keyword, is wrong - if for no other reason that properties from anonymous types (which dynamics are built on top of) are internal. Read meta programming Ruby, or try doing extensive [tb]dd with both, and you'll see how different they are (hint, you don't need DI frameworks in Ruby).
Ruby gems has a rich history, a strong community, and a proven track record. Every ruby developer has, and uses gems. Most packages are in known repositories. Gems has been extended to solve other problems (bundler). NuGet is a good and necessary start, but, again where you say "pretty close", I'd say "pretty far".
Are you sure C# dynamics are built on top of anonymous types? My understanding is that they are actually more like an untyped IQueryable, with syntactic sugar that turns dyn.Blah into the (rough) equivalent of dyn.Select(Blah).
Sorry, you are right. What I was referring to was a dynamic referencing an anonymous type (which is the same as anything else referencing an anonymous type)...Which I still wouldn't write off, because its a fairly common scenario, and even more so when used with dynamics.
RoR is definitely more of a full web stack than ASP.NET MVC, which to me feels like a micro framework layered over top of whatever in the the world ASP.NET is. Personally, I like ASP.NET MVC's micro fx feel though.
You hinted at Ruby not needing DI - for me, that's the biggest advantage when choosing a dynamic language (in my case Python) over C#. IMO, there's something about using DI that just feels wrong (don't mean to start a flame war over that).
Anyway, that's why I use F# in .NET land: the type inference provides the best of all worlds. No need for DI, light syntax, and great runtime speed. F# sucks w/ ASP.NET MVC though.
Yeah you could go on for quite a bit with the list of things the Rails experience has over .NET MVC.
1. Ease of deployment, Heroku compared to IIS
2. Scaffolding generation, not as easy to use, fast, or smart. Extremely hard (read impossible) to customize by comparison as well
3. Routing setup, not as clean and nice, harder to customize (though there are some routing projects out there that help)
4. No database migration story
I could probably go on if I spent much time thinking about it and I'm a Rail noob compared to my .NET MVC experience.
Other than Razor (which is optional), not that much has changed and it is a pretty painless upgrade. Under the old way they used to version software, this is really more like ASP.NET MVC 1.5 SP1
The other thing worth noting is way better support for dependency injection, through the DependecyResolver class. I'm becoming particularly attached to the IViewPageActivator interface for providing custom view creation logic (in my case, injection of helpers and custom session information into the page object).
I'm using an F# domain model assembly. A problem is that MVC's model binding infrastructure assumes model types with mutable properties (I had to write custom model binders to get around this).
I wonder when Microsoft will start paying attention to these details, I mean F# is supposed to be a 'first class citizen' language in Visual Studio now.
