Yesterday, David Fowler blogged about the Microsoft.Data APIs that come with ASP.NET WebMatrix.  While there were some positive comments, the majority were negative.  The reason for that is that a lot of readers completely missed the point of the API.  David is partially to blame for that, as he had not properly put it into context.  He since wrote a follow up post which fills in those gaps (and here is another one by Andrew Nurse), but I’ll try to do a slightly different take on this.

So in what sense did some readers ‘miss the point’?  They read it as:

Microsoft is now recommending a new data API.  That API uses raw SQL rather than an ORM.  Bunch of Microsoft idiots, what are they thinking!?

The reality is of course quite different.  As great as ORMs are, there is a measurable number of web developers who favor writing raw SQL over using an ORM.  That is a fact, and if you’re trying to pretend that it is not the case, you’re in denial.  Though they tend to be less vocal, there are a lot of people who prefer the raw SQL approach, for a variety of reasons.  But the point of this post is not about whether one should use an ORM vs raw SQL, as enough blood has been poured over that.

Instead, this post is about this new Microsoft.Data API.  Here is a one liner that describes its goal:

Given that someone will use raw SQL, how can we make it easier.

The first part of the sentence is key, and is what makes all the comments along the lines of “they should not use raw SQL because …” completely moot.  Simply put, if you are an ORM user this technology is not for you.

Instead, the only relevant way to look at this API is to discuss whether it is indeed an improvement over the old ADO.NET API.  And in my opinion that is no brainer.  Pretty much everyone who has seen it in this light has agreed.  Among the advantages over ‘classic’ ADO.NET:

• It uses far fewer concepts to achieve the same things.  Having to deal with SqlConnection/SqlCommand/SqlDataReader can be overwhelming.
• It makes it easier to use parameterized queries, hence reducing the risks of SQL injection issues (Andrew’s post has some simple examples).
• It uses ‘dynamic’ to make it more natural to access row values.

Is it revolutionary compared to classic ADO.NET?  Clearly not, and no one claims that!  But it is a long overdue simplification to the messy ADO.NET APIs, and in that sense it is pure goodness.

Now you can get back to your favorite ORM and feel safe that your world is not under assault.

Feels like just yesterday that we released ASP.NET MVC 2 to the world and here I am already talking about an early preview. In a way, we’re right on schedule. It was almost exactly a year ago that we released Preview 1 of ASP.NET MVC 2.

Today I’m happy to announce that ASP.NET MVC 3 Preview 1 is available for download. Give it a try out and let us know what you think. Some key notes before you give it a whirl:

• ASP.NET MVC 3 Preview 1 tooling requires Visual Studio 2010
• ASP.NET MVC 3 Preview 1 runtime requires the ASP.NET 4 runtime

As usual, to find out what’s in this release, check out the release notes. Also at the recent MVCConf, a virtual conference about ASP.NET MVC, I recorded a talk that provided a sneak peek at ASP.NET MVC 3 Preview 1. The audio quality isn’t great, but I do demo some of the key new features so be sure to check it out.

So what’s in this release that I’m excited about? Here’s a small sampling:

• Razor View Engine which ScottGu wrote about recently. Note that for Preview 1, we only support the C# version (CSHTML). IN later previews, we will add support for the VB.NET version (VBHTML). Also, Intellisense support for Razor syntax in Visual Studio 2010 will be released later.
• Dependency Injection hooks using service locator interface. Brad Wilson should have a few blog posts on this over the next few days.
• Support for .NET 4 Data Annotation and Validation attributes.
• Add View dialog support for multiple view engines including custom view engines.
• Global Action Filters

In the next few days you should see more details about each of these areas start to show up in various blog posts. I’ll try to keep this blog post updated with relevant blog posts so you can find them all. Enjoy!

Related

• Scott Guthrie has a detailed write-up of what’s new in ASP.NET MVC 3 Preview 1 in his trademarked style.
• Brad Wilson describes Service Location in ASP.NET MVC 3 in his four part series.
• Scott Hanselman recently barged into my office to discuss ASP.NET MVC 3. I was totally unprepared so I sent him to talk to the intern, Morgan, who shares my office while I scrambled. So if you’re interested in watching a schizophrenic video about ASP.NET MVC 3 Preview 1 and the unrelated Sprite Control for ASP.NET, check out this Channel 9 video.
• I recorded a video about ASP.NET MVC 3 Preview 1 for the MVCConf. I’m linking to it again here for convenience.

There’s an old saying, “Good things come to those who wait.” I remember when I first joined the ASP.NET MVC project, I (and many customers) wanted to include a new streamlined custom view engine. Unfortunately at the time, it wasn’t in the card since we had higher priority features to implement.

Well the time for a new view engine has finally come as announced by Scott Guthrie in this very detailed blog post.

While I’m very excited about the new streamlined syntax, there’s a lot under the hood I’m also excited about.

Andrew Nurse, who writes the parser for the Razor syntax, provides more under-the-hood details in this blog post. Our plan for the next version of ASP.NET MVC is to make this the new default view engine, but for backwards compatibility we’ll keep the existing WebForm based view engine.

As part of that work, we’re also focusing on making sure ASP.NET MVC tooling supports any view engine. In ScottGu’s blog post, if you look carefully, you’ll see Spark listed in the view engines drop down in the Add View dialog. We’ll make sure it’s trivially easy to add Spark, Haml, whatever, to an ASP.NET MVC project.

Going back to Razor, one benefit that I look forward to is that unlike an ASPX page, it’s possible to fully compile a CSHTML page without requiring the ASP.NET pipeline. So while you can allow views to be compiled via the ASP.NET runtime, it may be possible to fully compile a site using T4 for example. A lot of cool options are opened up by a cleanly implemented parser.

In the past several months, our team has been working with other teams around the company to take a more holistic view of the challenges developing web applications. ScottGu recently blogged about the results of some of this work:

• SQLCE 4 – Medium trust x-copy deployable database for ASP.NET.
• IIS Express – A replacement for Cassini that does the right thing.

The good news is there’s a lot more coming! In some cases, we had to knock some heads together (our heads and the heads of other teams) to drive focus on what developers really want and need rather than too much pie in the sky architectural astronomy.

I look forward to talking more about what I’ve been working on when the time is right.

Wow, has it already been over a year since the last major version of Subtext? Apparently so.

Today I’m excited to announce the release of Subtext 2.5. Most of the focus on this release has been under the hood, but there are some great new features you’ll enjoy outside of the hood.

Major new features

• New Admin Dashboard: When you login to the admin section of your blog after upgrading, you’ll notice a fancy schmancy new dashboard that summarizes the information you care about in a single page.The other thing you’ll notice in the screenshot is the admin section received a face lift with a new more polished look and feel and many usability improvements.
• Improved Search: We’ve implemented a set of great search improvements. The biggest change is the work that Simone Chiaretta did integrating Lucene.NET, a .NET search engine, as our built-in search engine. Be sure to check out his tutorial on Lucene.NET. Also, when clicking through to Subtext from a search engine result, we’ll show related blog posts. Subtext also implements the OpenSearch API.

Core Changes

We’ve put in huge amounts of effort into code refactoring, bulking up our unit test coverage, bug fixes, and performance improvements. Here’s a sampling of some of the larger changes.

• Routing: We’ve replaced the custom regex based URL handling with ASP.NET Routing using custom routes based on the page routing work in ASP.NET 4. This took a lot of work, but will lead to better control over URLs in the long run.
• Dependency Injection: Subtext now uses Ninject, an open source Dependency Injection container, for its Inversion of Control (IoC) needs. This improves the extensibility of Subtext.
• Code Reorganization and Reduced Assemblies: A lot of work went into better organizing the code into a more sane and understandable structure. We also reduced the overall number of assemblies in an attempt to improve application startup times.
• Performance Optimizations: We made a boat load of code focused performance improvements as well as caching improvements to reduce the number of SQL queries per request.
• Skinning Improvements: This topic deserves its own blog post, but to summarize, skins are now fully self contained within a folder. Prior to this version, adding a new skin required adding a skin folder to the /Skins directory and then modifying a central configuration file. We’ve removed that second step by having each skin contain its own manifest, if needed. Most skins don’t need the manifest if they follow a set of skin conventions. For a list of Breaking changes, check out our wiki.

Upgrading

Because of all the changes and restructuring of files and directories, upgrading is not as straightforward as it has been in the past.

To help with all the necessary changes, we’ve written a tool that will attempt to upgrade your existing Subtext blog.

I’ve recorded a screencast that walks through how to upgrade a blog to Subtext 2.5 using this new tool.

Installation

Installation should be as easy and straightforward as always, especially if you install it using the Web Platform Installer (Note, it may take up to a week for the new version to show up in Web PI). If you’re deploying to a host that supports SQLExpress, we’ve included a freshly installed database in the App_Data folder.

To install, download the zip file here and follow the usual Subtext installation instructions.

More information

We’ll be updating our project website with more information about this release in the next few weeks and I’ll probably post a blog post here and there.

I’d like to thank the entire Subtext team for all their contributions. This release probably contains the most diversity of patches and commits of all our releases with lots of new people pitching in to help.

When we released ASP.NET MVC 2, we included a file in the MvcFutures package (download) called MvcDiagnostics.aspx. This single WebForms page can be dropped into any MVC site, and then viewed in your browser. It will give you diagnostic information…

As many of you have probably heard, the release candidate for Visual Studio 2010 was recently released containing immense performance improvements and tons of bug fixes.

Another thing that release contains is the release candidate for ASP.NET MVC 2. However, that release is not the latest release of ASP.NET MVC 2 as we recently released a second release candidate for ASP.NET MVC 2 in response to customer feedback.

I apologize for the confusion this may have caused, but we really felt it was important to have another release candidate for ASP.NET MVC to help verify that we were responding to feedback in the correct manner.

If you wish to have Visual Studio 2010 RC and ASP.NET MVC 2 RC 2 installed at the same time, it’s not a problem.

If you installed ASP.NET MVC 2 RC 2 Before installing VS 2010 RC

Believe it or not, you’re all set if you install them in this order.

When installing VS 2010 RC, the installation will detect that a newer version of the ASP.NET MVC runtime (aka the System.Web.Mvc assembly) is already installed and will not overwrite it with the older version included with VS 2010 RC.

Keep in mind that the project templates for VS 2010 will still be the slightly older ASP.NET MVC 2 RC project templates and not the RC 2 templates. Fortunately those templates haven’t changed too much between release candidates.

In this configuration, when you create a project using VS 2010 RC, even though the templates may be slightly older, the project will reference the newer System.Web.Mvc assembly.

If you are installing ASP.NET MVC 2 RC 2 After installing VS 2010 RC

In this case, there’s a tiny bit of work to do. The installer for ASP.NET MVC 2 RC 2 will block if an older version of the ASP.NET MVC 2 runtime is installed.

To remedy the situation, all you need to do is uninstall the ASP.NET MVC 2 runtime. In Add/Remove Programs dialog (also known as the Program and features dialog), this would be the entry named “Microsoft ASP.NET MVC 2”.

If you have an older version of MVC tooling/project templates for Visual Studio 2008 installed (named “Microsoft ASP.NET MVC 2 – Visual Studio 2008 Tools”), you’ll also need to uninstall that, but do not uninstall the MVC tooling for VS 2010.

At this point, you should only have Microsoft ASP.NET MVC 2 – Visual Studio Tools for VS 2010 installed. You may now run the installer for ASP.NET MVC 2 RC 2, which will put the runtime on your machine as well as tooling/project templates for VS 2008.

Hopefully this clears up some of the confusion and gets you going with VS 2010 RC and ASP.NET MVC 2 RC 2.

Today I’m pleased to announce the availability of Release Candidate 2 for ASP.NET MVC 2.

After receiving feedback from our last release candidate back in December, we decided it would be prudent to have one more release candidate that incorporated the feedback. You can read the release notes for everything that changed, there’s not a whole lot.

The biggest change in this release was described by Brad Wilson in his blog post on Input Validation vs. Model Validation in ASP.NET MVC. Also included in this release are an assortment of bug fixes and performance improvements.

The window to provide feedback on this release is going to be very short as we are closing in on the RTM. If you want to provide input into this release, please do take the bits for a spin as soon as possible. I’m pretty excited about this release as I can see the end of the tunnel fast approaching.

At this point, we’ll only be taking recall class bugs for ASP.NET MVC 2. All other bug reports will be filed against ASP.NET MVC 3. Sometime in the near future, I’ll start sharing some of our planning around that. How exciting!

Oh, and if you missed the link to the Download Details page at the beginning of this post, here it is again.

We also posted the source code and futures assembly on our Codeplex Site.

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

I just posted build 2.6.10.  There were also a few builds in between since I last blogged about 2.6, so this post describes some of those changes (full history here).

Fluent route value API

As you probably know, T4MVC uses a pattern where the route values are encapsulated using a pseudo-call to a controller action, e.g.

    Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID))

This adds the controller, the action and the method parameters to the route values in a convenient way with no hard coded strings.

But in some situation, you may need to add extra values to the route that don’t exist in the action method.  Now you can do it as follows:

Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID)
    .AddRouteValue("foo", 17))

You can add multiple values this way using a fluent approach, e.g.

Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID)
    .AddRouteValue("foo", 17)
    .AddRouteValue("bar", "abc"))

As an alternative for adding multiple values, you can write:

Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID)
    .AddRouteValues(new { foo = 17, bar = "abc"}))

Note that in some cases, you may want to omit the action method parameters from the route, possibly because they are meant to come from form data and not from the URL.  For those cases, you can always use the parameter-less override that T4MVC generates (that part is not new), e.g.

Html.ActionLink("Delete Dinner", MVC.Dinners.Delete()
    .AddRouteValues(new { foo = 17, bar = "abc"}))

The nice thing about this fluent approach is that it doesn’t require adding overloads to all the T4MVC helpers (e.g. Html.ActionLink is this case) to take in the extra route values.  Instead, it automatically applies to any method that uses the T4MVC pattern.

Shortcut to refer to controller actions from within the controller

Suppose you want to redirect to a different action in the same controller.  Normally, in MVC you write something like:

return RedirectToAction("Details", new { id = dinner.DinnerID });

With T4MVC, you’ve always been able to write:

return RedirectToAction(MVC.Dinners.Details(dinner.DinnerID));

And now you can simplify it a bit and write:

return RedirectToAction(Actions.Details(dinner.DinnerID));

So basically, ‘Actions’ is equivalent to MVC.Dinners when you’re within the Dinners controller.

Now some might be tempted to take it a step further and just write:

return RedirectToAction(Details(dinner.DinnerID));

But that would be horribly wrong, since you would end up actually calling your controller action directly, which is not what you want!  We’re only trying to make a pseudo call to it that captures the route values.

Small breaking change: Actions renamed to ActionNames

This is a result of the previous change.  Unfortunately, the token ‘Actions’ was already used as the way to get all the action names for a controller.  So I ended up renaming it to ActionNames, since Actions was the best name for the new feature above.

So if you’re currently using the pattern ‘MVC.Dinners.Action.Delete’ (to refer to the action name “Delete”), you’ll need to change it to MVC.Dinners.ActionNames.Delete.

Sorry for the little extra pain!

Generate full view paths to allow cross controller references

Previously, when you wrote something like MVC.Dinners.Views.Edit, it would evaluate to “Edit”.  This works fine as long as you are using it from the Dinners controller, which implies that this is the Dinners Edit view as opposed to another controller’s Edit view.

But in some cases, you may want to refer to another controller’s view, and just having the short name no longer works.  So T4MVC was changed to instead make MVC.Dinners.Views.Edit evaluate to the full "~/Views/Dinners/Edit.aspx", which removes all ambiguities.

As far as I know, it should not affect any scenarios that use it, as it never hurts to be more specific.  But let me know if you run into something…

Added way to get area name from both Area and Controller objects

T4MVC now makes the area name available, either from the Area and the Controller.  e.g. you can write MVC.MyArea.Name or MVC.MyArea.MyController.Area, both of which will evaluate to the area name (here “MyArea”).

I would like to thank Rob Conery for posing the question:

As the project’s portal states:

MVC Turbine is a plugin for ASP.NET MVC that has IoC baked in and auto-wires controllers, binders, view engines, http modules, etc. that reside within your application. Thus you worry more about what your application should do, rather than how it should do it.

Let’s see how this plays out for your application…

Plain Old MVC Application

If you create an MVC application by using File –> New, you get the full power of the MVC framework but your application is not yet setup to take full advantage of it.  Say you want to take full advantage the separation of concerns that MVC provides but you’re using poor man’s dependency injection (DI) to work around the dependencies for your controllers:

   1: [HandleError]

   2: public class HomeController : Controller {

   3:     public IMessageService MessageService { get; set; }

   4:  

   5:     public HomeController() : this(new MessageService()) {

   6:     }

   7:  

   8:     public HomeController(IMessageService service) {

   9:         MessageService = service;

  10:     }

  11:  

  12:     public ActionResult Index() {

  13:         ViewData["Message"] = MessageService.GetDefaultMessage();

  14:  

  15:         return View();

  16:     }

  17:  

  18:     public ActionResult About() {

  19:         return View();

  20:     }

  21: }

  22:  

  23: public interface IMessageService {

  24:     string GetDefaultMessage();

  25: }

  26:  

  27: public class MessageService : IMessageService {

  28:     public string GetDefaultMessage() {

  29:         return "Welcome to ASP.NET MVC!";

  30:     }

  31: }

Although there is nothing wrong with using poor man’s DI as you start your application, you’ll quickly realize that a manually wiring up all dependencies across your application can be a rather tedious task. However, if you remove the poor man injection, aka remove the default constructor that provides the implementation, you’ll get the following error:

This error is due to the fact that the DefaultControllerFactory that ships with the MVC framework, doesn’t support the resolution of dependencies for complex controllers. Not saying that it should, just stating the current implementation.

How do we fix this?

Fortunately, the MVC framework allows you to provide your own controller factory that can create controllers with complex needs. A sample implementation can be done like,

   1: // Note: For instructions on enabling IIS6 or IIS7 classic mode, 

   2: // visit http://go.microsoft.com/?LinkId=9394801

   3:  

   4: public class MvcApplication : HttpApplication {

   5:     public static void RegisterRoutes(RouteCollection routes) {

   6:         routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

   7:  

   8:         routes.MapRoute(

   9:             "Default", // Route name

  10:             "{controller}/{action}/{id}", // URL with parameters

  11:             new {controller = "Home", action = "Index", id = ""} // Parameter defaults

  12:             );

  13:     }

  14:  

  15:     protected void Application_Start() {

  16:         // Configure the runtime to use our controller factory.

  17:         var controllerFactory = new CustomControllerFactory();

  18:         ControllerBuilder.Current.SetControllerFactory(controllerFactory);

  19:  

  20:         RegisterRoutes(RouteTable.Routes);

  21:     }

  22: }

  23:  

  24: /// <summary>

  25: /// Our 'custom' controller factory

  26: /// </summary>

  27: public class CustomControllerFactory : DefaultControllerFactory {

  28:     protected override IController GetControllerInstance(Type controllerType) {

  29:         // Very simplistic, wire up the dependency here

  30:         if (controllerType == typeof (HomeController)) {

  31:             return new HomeController(new MessageService());

  32:         }

  33:  

  34:         // For all other controllers, have the default implementation

  35:         return base.GetControllerInstance(controllerType);

  36:     }

  37: }

The implementation, CustomControllerFactory, is pretty simple and not very usable for controllers that are not the HomeController. Also, you need know how the controller factory is wired into the runtime so the framework will know how to use it.  Although it’s not a lot of code, you’ll need to know how the MVC runtime works and interacts with the extensibility points.  Don’t get me wrong, if you’re learning MVC, this is a great way to get your hands deep into the code and really grok things.  If you’re a seasoned MVC developer, you’ve either done this several times, or have componentized this piece and re-use it across your applications.

Why MVC Turbine?

The whole purpose of MVC Turbine is to speed your MVC development by having the plug-in handle all churn of the runtime and allow you to focus on what your application needs to do, rather than how to do it.  Here’s a short list of what MVC Turbine does for you:

• Provides a facade for your IoC container of choice (currently StructureMap, Castle Windsor/MicroKernel, Unity and Ninject).
• Extensibility API to take advantage of the runtime.
• Registers all MVC types (controllers, view engines, etc.) with the container.
• Sets up the MVC extensibility points to use the registered components.
• A lot more features…

Taking the example above and making it run on top of MVC Turbine, the code changes as follows (the controller code remains the same):

   1: public class DefaultMvcApplication : TurbineApplication {

   2:     static DefaultMvcApplication() {

   3:         //Tell MVC Turbine to use Castle Windsor as the default container

   4:         ServiceLocatorManager.SetLocatorProvider(() => new WindsorServiceLocator());

   5:     }

   6: }

   7:  

   8: // Use this marker interface to provide service registrations to MVC Turbine.

   9: public class DomainServiceRegistration : IServiceRegistration {

  10:     public void Register(IServiceLocator locator) {

  11:         // Tell the runtime to use MessageService for any request of IMessageService.

  12:         locator.Register<IMessageService, MessageService>();

  13:     }

  14: }

All the plumbing needed to resolve dependencies is handled by the Turbine runtime by leveraging the underlying container. So if you need to add another dependency to your controller, say IFooService, all you need to do is add the dependency to your controller and then register the type within the IServiceRegistration implementation.

Where to go from here?

If you’re interested on what MVC Turbine can provide to your application besides dependency resolution for your controllers, check out the download page for feature demos and sample applications.  Also, check out these blog posts that go deeper into the MVC Turbine runtime:

• Injecting Your Favorite IoC Into MVC Turbine
• MVC Embedded Views with MVC Turbine
• Multiple View Engines with MVC Turbine
• MVC Application Extensibility with MVC Turbine

Happy coding!

The MVC Turbine bits are now compiled against ASP.NET MVC 2 Preview 2 Beta and Visual Studio 2010 and .NET Framework 4 Beta 2.  You can get the bits by going to the CodePlex site.

Please note that this the same feature release as MVC Turbine v2.0 RTM.  The following is compiled and upgraded to work with .NET4 in VS2010:

• Runtime binaries
• Feature Samples
• Nerd Dinner Sample
• Okonau Sample

From here on out, the main development will take place onVS2010 and MVC2 as I get things setup for v3 sometime first quarter of 2010.  Also I’m planning on releasing some bits against MVC2 on .NET3.5 SP1, hopefully I’ll get to it tonight.

Happy Coding!