What ASP.NET MVC Could Learn From Rails

I can understand the authors frustration when it comes to the default providers with ASP.NET and looking for alternative solutions. But in my opinion, taking time to create your own custom providers is worth the effort and time because chances are the only need to be written once and afterwards can be used over and over again. That doesn't always solve the database issue but definitely cuts down the future development time.

One thing that does solve the database issue is EF Code First, or perhaps Subsonic with its SimpleRepository (both generate schema from your classes).

I am disinclined to agree that we need a "full stack" solution for ASP MVC. I love, love, love Ruby. I think it's a fantastic language. But when I want to do web work in Ruby I use Sinatra, because I want to choose the pieces of my stack, and Rails is so large that the barrier to entry is too great to justify when I only plan on spending a few minutes to a few hours on the project.
With ASP MVC, I think we have the equivalent to the Sinatra experience on Ruby (yes, I know there are ports of Sinatra on .net, I'm making a loose association ;-)). If you throw something like EF code first and Caliburn or MVVMLight into the mix you've got 75% of that stack you were missing (Caliburn.Micro uses MEF by default).

Ha, I just so happened to read Scott Hanselman's blog tonight and kicked this story relating to migrating your data models in EF Code First.
http://dotnetkicks.com/database/Data_Migration_With_Entity_Framework_Code_First

Creating a membership database in Asp.net is easy using the aspnet_regsql tool:
http://msdn.microsoft.com/en-us/library/ms229862(v=vs.80).aspx