Sampy's Blog

Yeah, I'm a nerd

2009-03-12T14:28:23.007

Bards are artists first and foremost, and they practice magic just as they practice song, drama, or poetry. They have a clear sense of how people perceive reality, so they master charm magic and some illusions. Sagas of great heroes are part of a bard's repertoire, and most bards follow the example of many fables and become skilled in a variety of fields. A bard's artistic ability, knowledge of lore, and arcane might are widely respected, particularly among the world's rulers.

Art and magic share a sublime beauty, and, as a bard, you seek the place where the two meet. You might be a naturally talented wanderer who casts impressive spells almost instinctively, a student of a bardic college who learned ordered systems of magic and epic poetry, a warrior skald who mixes skill at arms with thundering music, a dashing performer known for putting on a good show even for your enemies, or a perfectionist who seeks the consummate formula that blends art and magic into a higher force.

A steady rhythm beats in the back of your mind as you brandish your sword. Your eyes and ears pick up the motion of the villains that surround you, and one glance tells you everything you need to know to defeat them. You whistle three staccato notes, letting your allies know the symphony of battle is about to begin.

D&D Home Page - What Class Are You? - Build A Character - D&D Compendium

My one Alt.Net Seattle Session

2009-03-09T19:54:52.75

Oxite Retrospective 2 from Alex Hung on Vimeo.

The Oxite Architecture: Good, Bad, and Meh Part 2

2009-02-19T21:45:48.973

In Part 1 of this series, I covered how we added DI to our code with the Unity container. There have been plenty of samples out there that did this though. For Part 2, I thought I’d share something we did that I hadn’t seen before: Action Filters without Attributes.

Action Filters Classic

ASP.NET MVC out of the box supports the idea of an Action Filter. ScottGu had a post detailing Action Filters way back during Preview 4 and Phil Haack has a good filter overview as well. Go read those real quick because they’re great descriptions of how filters work and my blog follows the DRSGAPH principle (Don’t Repeat Scott Guthrie and Phil Haack).

Filters allow you to hook up incidental actions to a request with out forcing the code of your controller to do them. Need to do a security check? Use a filter. Want to cache the output? Use a filter. Want to have area based themes? Use a filter. At first glance, it seemed like a great way to make your controller code nice and clean. But while it keeps your methods fit and trim, the space above the signature can become crowded fast:
[Authorize(“Admin”)] 
[Theme] 
[Cache(CacheTime.Short)] 
[AdminSideBar] 
public List<Post> GetDrafts(Area area)
{ 
//real work 
}
You’ve pulled it out of the code (yay!) but your controller still has to know about all those extra things it needs to do (boo).

The ControllerActionInvoker

If you look at the View layer of ASP.Net MVC, you can see that it has the primary view and partial views to handle other parts of the rendering. At first glance, it looks like there isn’t a similar pattern in the controller layer. We considered building our own layer where we would provide our own RouteHandler and ran our own sub-controllers before calling out to the stock MVC controller but this seemed like a lot of work. Then while reading Phil Haack’s post about handling result formats based on a URL parameter, I found the ControllerActionInvoker class and the GetFilters method and the solution became clear. (We also did something very similar to what Phil is doing in that post at first before moving it into filters)

The ControllerActionInvoker is set on each controller when it is created. We’ve already taken over the creation of controllers to enable dependency injection so adding a little more magic there is easy. For those following along in the code, open up OxiteControllerActionInvoker.cs in the Infrastructure folder of the Oxite.MVC project. I’ll give you a second.

The GetFilters method takes information about the currently executing controller action, the ControllerContext and the ActionDescriptor, and returns a FilterInfo object which contains 4 ordered lists of filters to run as part of executing the actual action method. If you look up at the constructor, you’ll see that an IActionFilterRegistry is passed in. This interface is how you can dynamically assign filters based on give criteria. The Add method takes a list of criteria to satisfy and a type to create from the container if all the criteria are met. Now the execution of filters is disconnected from the attributes on the controller class itself. Your controller definitions now shrink and your code is much cleaner.

The Registry and Criteria

The registry itself is quite simple: for each Add call, make a record storing the criteria and type. When asked for the filters, pass the context to each record and if it passes, add it to all the filter lists that it implements. The record simply checks each criteria and returns true if the list is empty or if they all pass. The real magic is in the criteria.

We define two criteria for our use. The DataFormatCriteria matches requests that have a dataFormat field in their RouteData that is equal to the value passed at constructor time. We use this criteria to perform custom work for the RSS and ATOM feeds as well as JSON data. In fact, in the RSS and ATOM cases, the filters that run replace the result of the action method with a special FeedResult. Since those filters only run when the user requests one of those data formats, those filters don’t need to do any tests of state; if they’re running, that means they should replace the result.

The second criteria is the ControllerActionCriteria. This criteria is used to match a specific method on a controller. Open up OxiteApplication.cs in the root of Oxite.MVC and scroll to the registerActionFilters method to see it in action. We take an Expression<Func<T,object>> where T is the controller type. We parse this expression to determine which method on the controller you’re referring to. You can provide multiple methods to match and the criteria will return true is any one of them matches. We mostly use this criteria for our filters that add model objects that are used by our sidebar elements. This data is usually semi-related to the main controller action but isn’t directly involved with the main action of the controller. A good example is our archive sidebar.

We’re still working on how to expose the registry to addon authors but once we do, you can define any sort of criteria you like for your custom filters. You can even reuse our criteria if you like. The only real draw back I see is that there’s currently no way to remove filters or replace filters with your own code. Depending on the need, this is something we can take a look at as we iterate on the addon system.

Subcontrollers?

The core code uses filters for a variety of uses. We add things to the model object for the views to use(SiteInfoActionFilter, LocalizationActionFilter), control authorization (AuthorizationFilter), and even set parameters for the controller method (UserActionFilter, PageSizeActionFilter). IActionFilters can make quite a few changes to both the input and the output of the controller method. In fact, you can cover a lot of what people have been wanting to do with subcontrollers just through creative use of filters.

Now I’m not saying that you can cover everything or that this is the best way to introduce a subcontroller concept but it is a way to introduce more composition based behavior into your system. It can get complicated fast but I think it’s at a good level for us.

Now and the Future

If you like the way we decoupled filters from the controller attributes, steal it for your app. The big piece you need is the OxiteActionInvoker’s override of GetFilters and OxiteControllerFactory’s line where it sets the ActionInvoker property of the newly created controller to OxiteActionInvoker obtained via DI. You can take the registry too if you like. For that you’ll need ActionFilterRegistry, ActionFilterRecord, and IActionFilterCriteria. You can bring along IActionFilterRegistry if you want a more abstract way to use the registry.

As far as interacting with Oxite, we’re going to expose the registry to addons once we have a clear plugin story. Hopefully by then I will have switched it over to the fluent interface it had when I first designed it on my whiteboard. Here’s a sample of that:
IActionFilterRegistry registry = new ActionFilterRegistry();
registry.For<PostController>(p => p.Item())
        .AndFor<PostController>(p => p.List())
        .WithDataFormat("RSS")
        .Add<FooFilter>()
        .AndFor<PostController>(p => p.ListByTag())
        .Add<BarFilter>();
I want to make it jQuery-esque in it’s concept of specifying a set, acting, narrowing the set, then acting again. We’ll see how it shapes up but I do want it to be better than it is now. If you have any thoughts or suggestions on what it should look like, comment below and let me know.

Next time I’ll talk more about something that I don’t like about the code: Oxite Model Objects and their identity crisis.

The Oxite Architecture: Good, Bad, and Meh Part 1

2009-02-20T17:03:34.503

Part 2 now available.

For those of you that have been following the trials and tribulations of the Oxite Blog Engine, you probably know Erik, Duncan, and Nathan but you may not know me.

Hi, I’m Mike “Sampy” Sampson. I’m probably the closest thing to an architect we have on our team.

What I want to do here and in the future is talk about the choices we made in Oxite’s new design. There are plenty of things that we did that are really cool and plenty that I don’t like and want to revisit. Oxite’s not perfect and probably never will be but I’d like to have discussion about not only why we did the things that we did but how we can do them better.

How we got here

We were working on the launch of the new VisitMix.com and the MVC framework was out in preview form. The first thing almost all of us thought when looking at it was “awesome, total control over markup!” We dove in with both feet and built the new VisitMix.com and deployed it. The First Great Refactor (FGR) occurred during this time and the project structure you see today was born. The Second Great Refactor (SGR) occurred after we shipped and what was once just VisitMix became Oxite. We shipped and stuff went crazy. While there was a lot of positive press, there were plenty of valid architectural complaints about the way things work. On New Year’s Eve, The Third Great Refactor (TGR) began.

A quick aside - Our philosophy

I’m a TDD guy at heart. I write my tests first and keep the code as simple as possible. The rest of my team isn’t like that and I’m okay with that. I bet you can probably figure out which features I coded in this latest release based on their test coverage. I’m working on becoming a DDD guy but I’m not there yet and I wasn’t when we designed the new Oxite. I’ve got plenty of patterns under my belt and I love reading lots of blogs and books about the subject but I’m not perfect. I got us on SCRUM a few years back and I’m still the ScrumMaster to this day.

I’m not telling you this to get you to hate on Erik, Duncan, or Nathan but rather to make sure you know that going in and keep your expectations realistic. We’re a team of people who approach things differently and that has an impact on how we code. I think we write better code because of it. We always strive to find a balance between getting things done fast and getting them done well and we’re always learning better ways to do that.

Dependency Injection – The Good and The Bad

One of the first big things I did was introduce the Unity to the code. This ended up being pretty easy as I was doing a pretty lame imitation of DI in the code previously. Before I would define a constructor that took all the dependencies and another that was parameterless that would pass in all the concrete types. This was pretty simple in the VisitMix.com days but got more complicated with the provider model added in the FGR and the SGR. To add Unity, I did what a lot of the samples you see out there for MVC did: I defined a custom ControllerFactory and replaced the default on in the App_Start event. After that I just deleted the default constructors and added all those types to the container via config and DI was up and running.

The container setup has become a bit more complicated since then but rather than walk you thru all the steps of how it evolved (which I’d be happy to later if there’s interest), here’s how it works now and why we do what we do. For those following along in the code, open up ContainerFactory.cs in the Oxite.MVC project root.

GetOxiteContainer() sets up our default container for use both in the web site as well as WCF. Like most bootstrapper classes, it registers a list of known types with the container. We put a few statics in there like RouteTable.Routes and HostingEnvironment.VirtualPathProvider so that we can easily replace them in test scenarios. The first funky thing you’ll notice is that we register all the connection strings from the web.config file as strings with names. We do this so that you can specify a connection string by name in the config file when you pass it to the OxiteDataContext rather than having to have the connection string in two places in your web.config.

The other funky thing we do is use a child container. We load a container with all our default items then create a child container and register the values from web.config into it. This allows a crude form of plugins where you register your own implementation of one of these interfaces and we pick it up. This isn’t our long-term plan for plugins but it does get you in the door for right now.

Finally, we register the container with itself for classes that need to create object dynamically (ControllerFactory being the best example). I’m not a fan of static service locators. I prefer to have a single bootstrapping point and then navigate the object graph rather than anyone snagging the locator and grabbing objects. This way classes that need the container to create objects must be explicit in their request for the container and said container can be more easily replaced in test scenarios.

I like what DI has done for our code. It’s nice not to have to worry about how an object gets it’s dependencies and I think it speeds up the creation and editing of new classes. The way we register connection strings and other static objects like the current Site still feel a bit off but I don’t see a clear way to fix them at the moment. I also don’t like the amount of registration that I have to do in the ContainerFactory that seems automatable. I’ve toyed with the idea of writing some simple auto-discovery rules for Unity that map IPostService to PostService and the like but that seems like a lot of tricky code for something that simply reduces configuration. I’d love to hear your thoughts on how we use DI and ways we can improve.

More to follow

In the interest of getting things started, I’ll stop here for now. Next up I plan to talk about the way we used Action Filters like peer controllers while at the same time providing a way to use them with out attributing your controller methods.

Until then!

WCF Works!

2009-02-13T19:53:56.473

Yay!

I can post from Live Writer now!

Another morning, another update!

2009-02-11T19:06:53.837

This post should show up properly in the archive list!

Updated with the latest code

2009-02-11T19:00:07.993

I can't seem to get the archive list to show up in the sidebar so that's what I'm investigating now.
EDIT: Turns out it had to do with setting the State on entries created with the web interface. Live Writer was doing it right though.

Practicing what I code

2009-02-07T00:11:12.85

Now that we're getting close to our next release, I figured that I would move over to the new hotness. Expect more to follow.