I just got back from the Umbraco Masterclass in Seattle. I'm now a Level 2 certified Umbraco developer. Yay! During the training, we covered everything from the basics (e.g. What's a doctype?) to some more advanced concepts involving the new and improved Umbraco API. The best part was that this training was conducted entirely on Umbraco 6.

What's new in Umbraco 6?

• PetaPoco ORM
• Content and Media APIs revamped
• MVC

PetaPoco

I wont go into a lot of detail on PetaPoco. This is mostly because we didn't go into detail during the training. The long story short is that PetaPoco is lightweight and fast. The introduction of PetaPoco into Umbraco's data layer has definitely helped Umbraco in the ways of consistency.

Umbraco API revamped

The good news is that Umbraco's Content and Media APIs have been revamped into something simple, coherent, and consistent. The bad news is that we have to wait for the other APIs to catch up. Here are a couple of examples:

New Content API:

var cs = Services.ContentServices;
var parentNodeId = UmbracoContext.PageId.Value;
var content = cs.CreateContent("Name", parentNodeId, "NodeTypeAlias");

content.SetValue("bodyText", model.Body);
content.SetValue("memberId", Member.CurrentMemberId());
content.SetValue("Synopsis", model.Synopsis);

cs.SaveAndPublish(content);

New Media API:

var ms = Services.MediaService;
var parentFolder = ms.GetById(1173);
var newFile = ms.CreateMedia(model.FileName, parentFolder.Id, "Image");

newFile.SetValue("umbracoFile", file);

ms.Save(attachedFile);

MVC

This is the big stuff (and probably the hardest to explain via blog entry). I'll try to keep it understandable.

First of all, you don't have to use MVC. There's a magic switch you flip in the webconfig, and no one will make you flip it.

Second, it is definitely possible to convert your existing Umbraco webform sites to MVC. It sounds to me like some packages will soon be released that can do most of this automatically.

How does MVC work in Umbraco?

In Umbraco MVC, we now have:

Views
Partial Views
Partial View Macro Files
Models
SurfaceControllers

Views

Views are easy. They perform the same function as Templates do in Umbraco webforms. They show up under the Settings->Templates folder right alongside the webform Masterpages. Once you flip the switch and move into MVC mode, you will be creating Views by default instead of Masterpages.

You can actually use masterpages concurrently with Views. They kind of get jumbled together in the Settings->Templates folder, and it seems that Umbraco can begin to have a lot of difficulty if you try to name your Views the same as your Masterpages. This renaming issue is especially relevant if you are converting an existing Umbraco webform site to MVC. It seems to me that it's more simple to just go with one or the other.

There are some definite syntactic differences between the Views and the Masterpages. The following two snippets of code would do the exact same thing:

<asp:Content ContentPlaceHolderId="BodyElement" runat="server">
  <asp:ContentPlaceHolder Id="BodyElement" runat="server" />
</asp:Content>

<asp:Content ContentPlaceHolderId="SidebarElement" runat="server">
   <umbraco:Macro Alias="Sidebar" runat="server"></umbraco:Macro>
</asp:Content>

@section BodyElement{
  @RenderSection("BodyElement")
}

@section SidebarElement{
  @Umbraco.RenderMacro("Sidebar")
}

Partial Views & Partial View Macro Files

The only difference between the Partial Views and the Partial View Macro Files is that the Partial View Macro Files can be wrapped in an Umbraco Macro and, thus, can have Macro Parameters passed to them.

Both of these are very similar to the old Razor Scripting Files.

Models

These are just regular Classes. Nothing super fancy. They just represent entities in the system.

SurfaceControllers

These are the heart of Umbraco MVC. SurfaceControllers are just MVC controllers that already have routes set up for them. They are the MVC replacement of a UserControl.

Instead of writing a UserControl to handle a particular piece of functionality on one of my pages, we could write a SurfaceController paired with some Models and Partial Views.

Imagine a scenario where you had a form to process. We might write a UserControl that displays this form and processes it. In that case, our Masterpage would have something like this:

<umbraco:Macro Alias="HandleForm" runat="server"></umbraco:Macro>

If we were to do this MVC style with SurfaceControllers, in our View, we might see this:

@Html.Action("RenderForm", "FormSurface")

Our SurfaceController would then render the "Form" partial view. The user could fill out the form (represented by a Model) and submit it back to the SurfaceController for processing. 

These SurfaceControllers are the really cool part to me. Imagine a UserControl where the brain is hidden inside of a DLL. It is never wrapped in an Umbraco Macro, but all of the views and partial views are exposed in the Umbraco back-end GUI. As an added bonus, you can tell, immediately, by looking at the @html.Action(...) which SurfaceController was being referenced and which method was executed.