Least-Concept-Method

Often when writing code a developer will use member overloading to provide an alternate convenient call interface on a class. Assuming the developer has at-least a passing interest in quality, they will try and stay DRY. To this end, one of the method overloads will contain the core 'work' for the member, whilst overloads will perform only simple tasks, and then hand-off to the core method to do the real work. But which overload is the best for the core?

I like to use a least-concept method for the core. By this I select a set of parameter(s) that are

1. Not native types, or simple constants.
2. Don't require the method to navigate deeply into the parameter(s) (one-level in is ideal).

Why not native types? 

Often I've seen code that uses a core method that extracts the most-basic, or native data from more complex objects, and implements the core with this. For example, say I have a CountLines() method that needs a file, the developer may go for the most basic CountLines(string fileName) style. This approach has the benefit of being flexible for the caller, but it sacrifices clarity. The next developer has to know that what I really mean is the full path to the file, not just its file name. You could argue the parameter is badly named (and I'd agree), but I still would prefer a stronger type. C# is a typed language, a better idea would be to leverage it. In this case I would go for a CountLines(FileInfo file) method.

Why not the most complex object as a parameter?

Sometimes you need to implement a method that takes a complex object, particularly when implementing an interface (plug-in), but the method only uses a small part of the complex object. Lets say you're implementing a RejectIfTooBusy(HttpApplication context) method. You want to reject if the current request is from a set of black-listed hosts. The context has the data you need via context.Request.Url.Host, but to reach this you need to check for nulls along the way. Rather than having this parameter conversion code in your main implementation, I prefer to pull out a core RejectIfTooBusy(Uri whoReqested) method, and have this overload called by the first. By separating out the core member, it becomes clearer that all I'm checking is the request url. It can also be useful to split a complex object, to highlight the bits that the method really uses.

Generic Split() extension

Recently I needed to break a set into multiple sub-sets, just like the String.Split() operation.
I couldn't find a simple answer; so a quick bit of code and now I have a simple generic Split<T>() extension you can use to split a collection similar to String.Split().

Code and ms tests found in the gist here: https://gist.github.com/3703440

My default browser is now IE9 :(

A monumental change for me.
I have just changed from chrome to IE9 as my default browser. I feel... kinda yucky.

Why? One simple but painful function: support for the file protocol e.g. file://server/share
In IE (and ffox I hear) it opens my local explorer, a very useful behaviour.
In Chrome.. it does nothing.
I spent a fair amount of time trying to find a work around, in the end... see title.

Quint with mstest

Recently I've been doing more complex JavaScript coding. As part of the process, I wanted a better approach for JavaScript unit tests. After a Google I've settled on using QUnit, from the jquery guys.

QUnit runs in browser, which I wanted, since I like to test on an actual browser JavaScript engine; its closer to what the user experiences. I also wanted to be able to run the tests the same way I run .net tests; in my IDE (vstudio), but out of the box quint can't do that.

There are approaches to use QUnit with a server, but these focus on CI; a good thing; but not what I was after.

So, with a little code, and some convention, I use a simple mstest base class to start a web server, open a page, run quint, return the result. I also use a small bit of JavaScript to get QUnit to call back to my test, reporting results.

See the gist: qunit + mstest; using simple in-proc webserver (https://gist.github.com/2784505)

With this, I now run the unit test in v studio, same as normal tests. Too easy.

IOC for objects loaded from orm

I like the idea of coding a Rich domain model, and then applying services to the model. Recently I was trying to get just a little closer to a rich domain, by resolving domain object dependencies during their creation via the ORM. I did find nhibernate supports this style, but alas I am currently constrained to use EF4.1 - code first.

The EF4.1 doco is.... Well there isn't any as best I can tell. For EF4 code first I've relied on blog entries, and perusing the API in object browser. In my quest for rich domain, I found no extension point in EF where I could manage entity proxy creation (pre or post load). I tried finding an override in the db context, no luck. I had some hopes there would be extensibility in te object tracker.. Nup :(.

So in the end I opted to wrap the EF model inside an IOC context aware class (spring.net), that way I coud at least get a post orm load IOC approach.
I've used a simple convention; when the ORM loads an entity, the entity full class name is used as a key in the IOC container. If it's found, the IOC is called, to resolve dependancies on the orm created object.

This approach is all I currently have, with ef4.1.
It works fine, for very simple situations, but since I've intercepted out side of the orm, I only get a shot at resolving dependencies on a top-level entity, not on any child objects that the ORMloads, which kind of makes the whole approach invalid, since I want my ORM to load a more complex entity model than just a set of top-level entities .

Add implied interface to a class.

Often... Well often enough, I need to use a .net framework class to implement a method. I almost always find that I want to use an interface on my class, so I can unit test it, and that the framework class provides no interface. This leads to me needing to define a interface, and implement it with a quick decorator around the framework class. Recently I was doing this with the Ping class when I decided to invest a little time looking for a better answer.

My first attempt was to use spring.net mix-ins, or introductions in AOP terms. That kinda worked, but since mixing require a class with the interface implementation, I still needed to write the decorator... not a whole lot better.

After more googling, turns out what I wanted is called duck-typing (who knew). And as with other problems, once you get the term, the googling is easy. I found a few different libraries that could help, I settled on impromptu.

It did take me a while to work out a good way of integrating with spring.net, i've used spring.net a fair bit, but haven't done a lot of extension work to date. Finally I settled on a custom factory object, it requires the target objec rand target interface, using that, it produces a ready to go decorator.
/emote "<-- nods and files away a new tool for the toolbox"

A quick sample class:

Multiple submit buttons with MVC 3.

I recently needed to create a MVC (MVC3) view with multiple submit buttons.
A quick look around with Google and I found a couple of approaches, but I thought to myself, there must be a cleaner way.

Up till now I've been using the simple approach of creating a controller action where the method takes an extra parameter to describe which action to take like:

Controller:
public class MyController
{
public ViewResult Index() { return View();}

public ViewResult DoSomething(string action, string someData)
{
if(action == "Action1") {}
else if(action == "Action2") {}
else {/*unknown action.*/ }
}
}

xhtml:
<form action="My/DoSomething>
<input name="someData"/>

<input type='submit' name='action' value='Action1' />
<input type='submit' name='action' value='Action2' />
</form>

What I wanted was to be able to define my Controller to have multiple Actions, one for each submit action on a Form, like this:

public class MyController
{
public ViewResult Index() {return View();}

public ViewResult Action1(string someData) {return View();}
public ViewResult Action2(string someData) {return View();}
}

But alas, with MVC I couldn't construct a Route that would do this; MVC routing always uses the Forms action attribute to decide which Controller method to call.

In the end the answer wasn't that hard. I just created a smarter IRouteHander, and applied it to the MVC default route.
The HTML for the form looks almost the same, though I remove the Action from the Form's action attribute, since the route handler will look after that.
xhtml:
<form action="My>
<input name="someData"/>

<input type='submit' name='action' value='Action1' />
<input type='submit' name='action' value='Action2' />
</form>


Now the methods on my controller don't need 'special' arguments, and the world is a better place :D
Here is the custom RouteHandler: