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.

So for the next gen of our ASP.NET based software platform, which we’ll build on .NET 2.0 w VS.NET 2005, here are some key components:

1. MS SQL database, we’ve borrowed the naming scheme from Rails—why not?
2. Historically we’ve done a lot of work inside SQL queries (a LOT of work)—we’ll move away from that practice in the interest of centralizing business logic into the business tier (which sits above the DAL and below the app)
3. After investigating the use of O/R Mappers vs. DAL code generators, we decided to “roll our own”—we build a C# application that generates a basic class for each table with CRUD + collection operations. Everytime we change the DB, we’ll have to regenerate the DAL, but no longer will we need to make manual code edits in that layer.
4. The app layer (web app, web service, desktop app) will deal with presentation details only—we’ll refactor rigorously to push business logic down to a shared business layer.

We may build a web helper project for presentation code that is shared among web projects.

As a result of all this, we’ll have a thick shared business layer—but we’ll have all the “complicated” code in one project, with it’s goal being to make the code in the app layer as readable + simple as possible.

Update: We dumped our custom coded DAL in favor of .NET 2.0 Strongly-typed data sets. Working good so far.