What I do want to share is a set of extension methods that (for me) made using LINQ-to-SQL just a little bit nicer. The title is indeed descriptive…these are “sugar” added to LINQ-to-SQL and don’t fundamentally improve how it works, just how the programmer works with the library. I’m sure developers using LINQ-to-SQL have created scads of other such saccarine extensions to the framework…if you have some I’d be interested in hearing about them.

So here’s my LinqToSqlExtensions class:

public static class LinqToSqlExtensions {
 
    public static TEntity GetById<TEntity>(this Table<TEntity> @this, int id)
        where TEntity : class {
        return @this.SingleOrDefault(x => ((IIdentified)x).ID == id);
    }
 
    public static TEntity Upsert<TEntity>(this Table<TEntity> @this, int id)
        where TEntity : class, new() {
 
        var entity = @this.SingleOrDefault(x => ((IIdentified)x).ID == id);
 
        if (entity == null) {
            entity = new TEntity();
            @this.InsertOnSubmit(entity);
        }
 
        if (entity is IAuditable)
            ((IAuditable) entity).ModifiedDate = DateTime.Now;
        return entity;
    }
 
    public static TEntity Upsert<TEntity>(this Table<TEntity> @this, Func<TEntity, bool> predicate)
        where TEntity : class, new() {
 
        var entity = @this.SingleOrDefault(predicate);
 
        if (entity == null) {
            entity = new TEntity();
            @this.InsertOnSubmit(entity);
        }
 
        if (entity is IAuditable)
            ((IAuditable) entity).ModifiedDate = DateTime.Now;
 
        return entity;
    }
 
    public static void Delete<TEntity>(this Table<TEntity> @this, TEntity entity)
        where TEntity : class {
        @this.DeleteOnSubmit(entity);
    }
 
    public static void DeleteById<TEntity>(this Table<TEntity> @this, int id)
        where TEntity : class {
        var entity = @this.GetById(id);
        @this.Delete(entity);
    }
 
    public static void DeleteAll<TEntity>(this Table<TEntity> @this, 
        IEnumerable<TEntity> entities) where TEntity : class {
        entities.ToList().ForEach(e => @this.Delete(e));
    }
 
    public static void CommitChanges(this DataContext @this, RepositoryContext context) {
 
        var changeSet = @this.GetChangeSet();
 
        for (var i = 0; i < changeSet.Inserts.Count; i++)
            if (changeSet.Inserts[i] is IAuditable) UpdateAuditProperties((IAuditable) changeSet.Inserts[i], context, true);
 
        for (var i = 0; i < changeSet.Updates.Count; i++)
            if (changeSet.Updates[i] is IAuditable) UpdateAuditProperties((IAuditable) changeSet.Updates[i], context, false);
 
        @this.SubmitChanges();
    }
 
    private static void UpdateAuditProperties<TEntity>(TEntity entity, RepositoryContext context, 
        bool isInsert) where TEntity : IAuditable {
 
        entity.ModifiedDate = DateTime.Now;
        entity.ModifiedBy = context.UserID;
 
        if (isInsert) {
            entity.CreatedDate = DateTime.Now;
            entity.CreatedBy = context.UserID;
        }
    }
}

Here’s a rundown of the methods it creates and how to use them:

GetById
Simple enough, allows you to avoid using the LINQ syntax to find an element by it’s identifier.

var thing = DataContext.Things.GetById(3);

Upsert
This is probably the most convenient addition. It simply checks to see whether the object exists (by it’s ID) if so it returns it if not it creates a new one and returns that. It just avoids a lot of query-for-an-object-and-if-its-null-create-a-new-one-and-insert-it code.

var thing = DataContext.Things.Upsert(2);
var anotherThing = DataContext.Things.Upsert(x => x.Name == "That Thing");

Delete and DeleteById
Pretty obvious…

DataContext.Things.Delete(thing);
DataContext.Things.DeleteById(3);

CommitChanges
This is just a replacement for SubmitChanges that allows us to update some audit columns automagically.

Some of this magic is provided via a set of partial classes on those that LINQ-to-SQL generates that applies some additional interfaces to those classes. So, I have a Partials.cs file that contains the following:

public interface IAuditable {
    public DateTime CreatedDate { get; set; }
    public DateTime UpdatedDate { get; set; }
    public int CreatedBy { get; set; }
    public int UpdatedBy { get; set; }
}
 
public interface IIdentified {
    public int ID { get; set; }
}
 
partial class Thing : IIdentified, IAuditable { }
public class OtherThing : IIdentified { }
public class LastThing : IAuditable { }

As long as your generated class (and it’s related table) have properties of the same names as the IAuditable and IIdentified interfaces the LINQ-to-SQL extension methods can update them appropriately and in the background. I could have accomplished much of this by just inheriting a new DataContext and adding some additional functionality, but doing it this way you can add these methods to even a closed assembly.

Bring in the DLR
The DLR is implemented as a set of plain old DLL’s on top of the .NET Framework version 3.5…contrary to popular belief, you do not have to be running VS2010 or .NET 4 to use it.  Simply go to the CodePlex page for the DLR (http://dlr.codeplex.com), grab the source, and compile it.  There are solution files for VS2008 and VS2010.

For my purposes I used IronPython as the scripting language but IronRuby is available in the download as well.  To use the DLR your project will need to reference the following assemblies:

• Microsoft.Dynamic.dll
• Microsoft.Scripting.Core.dll
• Microsoft.Scripting.dll

In order to use IronPython, you will also need to reference these:

• IronPython.dll
• IronPython.Modules.dll
• Microsoft.Scripting.ExtensionAttribute.dll

Register the Languages
Now that your project contains all the references it needs it’s time to set up the little bit of code needed to host the DLR.  First you’ll need to add a few things to your configuration file (App.config or Web.config depending on your project type…this works equally well with either).  Just add the following to the node of your config file:

<section name="microsoft.scripting" 
	type="Microsoft.Scripting.Hosting.Configuration.Section, Microsoft.Scripting, 
		Version=0.9.6.20, Culture=neutral, PublicKeyToken=null" 
	requirePermission="false" />

And add the following somewhere in the root node:

<microsoft.scripting>
    <languages>
        <language names="IronPython;Python;py" 
			extensions=".py" displayName="IronPython 2.6" 
			type="IronPython.Runtime.PythonContext, IronPython, 
				Version=2.6.10920.0, Culture=neutral, PublicKeyToken=null" />
    </languages>
</microsoft.scripting>

This basically just tells the runtime what languages to register, what versions of those languages, and some info about file extensions, etc.

Bring in PostSharp
Now I’m going to skip over to PostSharp for a minute. If you’re not familiar with PostSharp you should run over to the website (http://www.postsharp.org) and check it out before continuing. In short, it’s an AOP (Aspect Oriented Programming) library for .NET that allows easy injection of cross-cutting concerns through an application primarily via attributes. The 10sec. version of how it works is this…it injects code in a post-compilation step. This sounds scary, but it’s not. In fact, this allows it to be extremely fast at runtime even if a small penalty is paid at compile-time.

In order to get PostSharp setup, it’s a simple download and install. If you don’t want to install it on your machine, you can simply bin deploy it but it does require a tweak to your .proj file to get the post-compilation to work. If you want to go that route, you can find instructions here. At this point you will either follow those instructions or if you’ve installed directly, just include the following assemblies in your project:

• PostSharp.Laos.dll
• PostSharp.Public.dll

The ScriptHook Attribute
PostSharp’s primary way of injecting an aspect is through attributes. In our case we’re going to inherit from the OnMethodBoundaryAspect attribute in the PostSharp.Laos namespace. This attribute exposes four virtual methods that allow injection of code at different points in the execution of a method:

• OnEntry
• OnExit
• OnException
• OnSuccess

Each of these methods accept a MethodExecutionEventArgs as an argument that provides access (including arguments) to the method on which the attribute is applied. Here’s the ScriptHook attribute:

[Serializable]
public class ScriptHookAttribute : OnMethodBoundaryAspect {
 
    private readonly ScriptEventTypes _scriptEventType;
 
    public ScriptEventAttribute(ScriptEventTypes scriptEventType) {
        _scriptEventType = scriptEventType;
    }
 
    public override void OnSuccess(MethodExecutionEventArgs eventArgs) {
        var args = eventArgs.GetReadOnlyArgumentArray();
        ScriptRunner.ExecuteEvent(_scriptEventType, args);
    }
}

For now, ignore the ScriptRunner reference, but notice that I’ve created an enum (ScriptEventTypes) that distinguishes different “types” of scripts to be run, by types, I mean different usages. At some point you can switch on the type of event that’s occurring and change which scripts are loaded or how they are handled, etc. You would use the attribute like this:

[ScriptHook(ScriptEventTypes.ThingSaved)]
public void SaveThing(Thing t) { }
 
[ScriptHook(ScriptEventTypes.ThingDeleted)]
public void DeleteThing(Thing t) { }

The ScriptRunner
At this point we’ve got the DLR available and we have the PostSharp attribute that’s injecting our hooks. Now we need something to execute our scripts. Enter the ScriptRunner:

public static class ScriptRunner {
 
    public static void ExecuteEvent(ScriptEventTypes scriptEventType, object[] eventContext) {
 
    IScriptEvent scriptEvent = null;
 
    switch (scriptEventType) {
        case ScriptEventTypes.ThingSaved:
	    scriptEvent = new ThingSavedScriptEvent();
	    break;
	case ScriptEventTypes.ThingDeleted:
	    scriptEvent = new ThingDeletedScriptEvent;
	    break;
	}
 
	if (scriptEvent != null) {
            try {
                scriptEvent.ExecuteScripts(eventContext);
            } catch {
                throw new ScriptExecutionExecption();
            }
        }
    }
}

The runner is just a simple static class with a single ExecuteEvent method…it’s so simple in fact that it speaks for itself. The one thing to note is the eventContext argument to the ExecuteEvent method. If you look back at the ScriptHook attribute you can see that is’ passing an object array from the MethodExecutionEventArgs instance. This object array contains all the arguments to the executing method. So for SaveThing() or DeleteThing() for example the eventContext array contains the instance of Thing that was passed.

The IScriptEvent Classes
Lastly, we need something to actually grab the scripts and execute them in something like the context of the executing method. So that’s where our example ThingSavedScriptEvent and ThingDeletedScriptEvent come in to play. Here’s an example:

public class ThingSavedScriptEvent : IScriptEvent {
 
    private readonly ScriptRuntime _scriptRuntime;
    private readonly IThingRepository _thingRepo;
 
    public ProjectCreatedScriptEvent() {
        _thingRepo = new ThingRepository();
        _scriptRuntime = ScriptRuntime.CreateFromConfiguration();
    }
 
    public void ExecuteScripts(object[] contextValues) {
 
        var thing = (Thing)contextValues.SingleOrDefault(x => x is Thing);
 
		var scriptScope = _scriptRuntime.CreateScope();
        scriptScope.SetVariable("thingRepo", _thingRepo);
        scriptScope.SetVariable("thing", thing);
 
        var script = GetScript();
 
        var scriptEngine = _scriptRuntime.GetEngine("IronPython");
        scriptEngine.Execute(script, scriptScope);
    }
 
    private static string GetScript() {
 
        var script = string.Empty;
        try {
            code = File.ReadAllText(HttpContext.Current.Server.MapPath(
                ConfigSettings.ProjectTemplateStorePath + "ThingSaved.py"));
        } catch (FileNotFoundException) { }
        return script;
    }
}

The ScriptRuntime class is where the DLR magic happens. We create an instance of it and then ask it for an engine that can execute IronPython scripts. ScriptScope is a class used for constructing the scope that the script will have available to it. Here for example we’re “passing” the ‘thingRepo’ and ‘thing’ variables into the script via the ScriptScope. Lastly, we get the engine from the ScriptRuntime, pass it both the ScriptScope and the literal text of the script. And that’s that…pretty easy eh?

Before really describing the workflow of the pattern, here are the basic components of our implementation:

The ITestScope Interface

public interface ITestScope {
    void SetupScope();
    void TeardownScope();
}

These two methods (SetupScope and TeardownScope) are where we move all of the test setup and cleanup logic. Any state that needs to be maintained between setup and teardown (i.e. needs to be available to the test itself) can be stored in public properties or fields on the class implementing ITestScope.

The TestBase Class

public abstract class TestBase {
    public abstract void ScopeSetup();
    public abstract void ScopeTeardown();
}

Requiring that all test classes inherit from TestBase insures that at least developers will be considering the setup and cleanup of their tests. The TestBase.ScopeSetup method would include instantiating and calling the TestScope.SetupScope methods for any scopes that are needed in the test class…likewise for teardown.

The TestFactory Class

public static class TestFactory {
    public static TRepository GetRepository<TRepository>() where TRepository : class {}
    public static TController GetController<TController>() where TController : Controller {}
}

This isn’t directly related to the scope pattern, but it’s invaluable as a point where you can use a DI container in the test project. All repository or controllers (or other resources) can be obtained from here.

An Example

So here’s an example test class that might use this pattern.

public class CustomerTestScope : ITestScope {
 
	private ICustomerRepository _customerRepo;
 
	public Customer TestCustomer { get; private set; }
 
	public CustomerTestScope(ICustomerRepository customerRepo) {
		_customerRepo = customerRepo;
	}
 
	public void SetupScope() {
		TestCustomer = _customerRepo.Create();
                // Other complex test setup logic
	}
 
	public void TeardownScope() {
		_customerRepo.Delete(TestCustomer);
                // The reverse of the complex setup logic
	}
}
 
[TestClass]
public class CustomerRepositoryTests : TestBase {
 
	private CustomerTestScope _customerScope;
	private ICustomerRepository _customerRepo;
 
	[TestInitialize]
	public override void ScopeSetup() {
 
		_customerRepo = TestFactory.GetRepository<ICustomerRepository>();
 
		_customerScope = new CustomerTestScope(_customerRepo);
		_customerScope.SetupScope();
	}
 
	[TestMethod]
	public void SaveCustomer_ShouldRenameCustomer_WhenNewNameGiven() {
 
		_customerScope.TestCustomer.Name = "New Name";
		_customerRepo.Save(_customerScope.TestCustomer);
 
		var customer = _customerRepo.GetById(_customerScope.TestCustomer.ID);
 
		Assert.IsTrue(customer.Name == "New Name", 
			"SaveCustomer failed to update customer name.");
	}
 
	[TestCleanup]
	public override void ScopeTeardown() {
		_customerScope.TeardownScope();
	}
}

If additional scopes were needed then they could simple be added to the test class. For example, if a ProductTestScope was also needed then it would be initialized just like the CustomerTestScope and torn down appropriately.

Dependencies between scopes would be supplied via constructor parameters. This does imply that the SetupScope methods be called in sequence and TeardownScope be called in reverse order.

That’s the pattern, pretty simple but now the logic for creating these setup conditions can be offloaded and reused in a simple way and we’ve made it easy to clean up that test data after the tests complete.

The basic premise of Sinatra is that every method defines a route, and a route (URL + Verb) invokes a single method. Ruby, being a dynamic language, makes this extremely easy. Like I said I’m no Ruby guru but the built-in introspection of the language makes it easier to build a DSL that can describe these route methods.

Martin, isn’t at all a port of Sinatra. Rather it’s inspired by the lightweight nature of Sinatra and it’s general pattern. Martin relies on the new System.Web.Routing namespace in .NET 3.5 SP1 and will eventually ship with a DSL that will encapsulate defining your RouteTable. Because it doesn’t have any external dependencies and really doesn’t need any templates it can plug into any ASP.NET or ASP.NET MVC project and live along side just fine*.

In Martin, the first step to creating a new action is defining it with the Config API. At this point it’s excruciatingly simple.

In Global.asax:

protected void Application_Start(object sender, EventArgs e) {
    Config.AddAction<DateAction>("Show/CurrentDate");
}

What this does is maps the URL: http://domain.com/Show/CurrentDate to the DateAction.Get() method. Behind the scenes there is a factory class that’s constructing instances of DateAction, calling the Get() method, and then responding with the result to the request pipeline.

The DateAction class looks like this:

public class DateAction : ActionBase {
    public override IResponse Get() {
        return Text(string.Format("The current date is {0}.", DateTime.Now));
    }
}

There are four methods on ActionBase that can be overridden: Get(), Post(), Put(), and Delete(). Each method (obviously) corresponds to an HTTP Verb and only requests using that verb will invoke the appropriate method. So, the same URL pattern can be mapped to two different methods provided that the request uses different verbs.

The ActionBase class provides a way to get access to any RouteData or Request items that might be part of the request. Using the ValueOf(String key) method you can find for example an ID that’s tacked on to the URL or a piece of data from the querystring or form collection.

~~

For now the project is in a very early stage, no real sample, no real documentation. However, it’s so simple that reading through the handful of classes that make up the project is almost all the documentation you’ll need. If you get a chance, poke around and let me know what you think…if you want to help make it better just let me know and I’ll get you commit rights to the Google Code repo.

Source at: http://code.google.com/p/martin-framework/

* In the case of integration with ASP.NET MVC the routes defined by Martin and those your application might need could conflict so care must be taken to insure there are no collisions.

If you’re working with ASP.NET MVC (or god help you ASP Classic) you’ll likely be annoyed by the way server blocks are formatted in Visual Studio. In particular closing curly braces seem to throw the formatting engine a real curve-ball. For example, you type something like this:

<% } %>

But after slapping return, you ultimately get this lovely thing:

<%
       }
     %>

Thanks Visual Studio!

So how do we fix this. Well, you’d like it if hitting Ctrl+K+D took care of this for you, but apparently that ignores server blocks. Next you’ll hunt and peck your way through the mounds of Visual Studio options in Tools > Options…but that search will ultimately prove fruitless. Finally, you’ll turn to the humble macro…I know macro can be a dirty word but in this case it’s really your only option.

Here’s how this goes:

1. Mouse over to Tools > Macros > Macro IDE
2. Notice that Visual Studio macros are in Visual Basic…really? I know…but go with it.
3. Right-click ‘My Macros’
4. Choose ‘Add New Item’
5. Choose ‘Module’ in the dialog
6. Enter the following method in the newly created Module:

Public Module FormatCurrentFile
 
    Sub FixServerBlocks()
        Dim selection As TextSelection = DTE.ActiveDocument.Selection
        Dim fixed As String = "<% } %>"
        Dim regex As String = "\<\%:Wh*\}:Wh*\%\>"
        While selection.FindPattern(regex, vsFindOptions.vsFindOptionsRegularExpression)
            selection.ReplacePattern(regex, fixed, vsFindOptions.vsFindOptionsRegularExpression)
        End While
    End Sub
 
End Module

Now you can go through Tools > Options > Keyboard and map a key command to this macro…I chose Ctrl+K+C for example since it’s close to the other magic formatting keys that you’ll want to run right before the macro. There you have it.

Thanks to some help from StackOverflow.com for this solution: http://stackoverflow.com/questions/720042

Using the SqlMethods.Like() method, you can do the following:

var keyword = "Marshmal";
var things = from thing in db.Things
                     where SqlMethods.Like(thing.Name, keyword)
                     select thing;

And if you want to search the start, middle, or end of your string, just tack on the ‘%’ as you would in any normal SQL statement:

var keyword = "mallow";
var things = from thing in db.Things
                     where SqlMethods.Like(thing.Name, "%" + keyword)
                     select thing;

And there you have it…an easy way to find your marshmallows.

Anyway, one of the features I needed was search…and not just any search, a very dynamic search.  The application is an inventory tracking system and it allows a user to set up different kinds of items and create a unique list of properties that each of those items can have.  For example you might create an item of type 'Widget' with two properties 'Size' and 'Color'.  Another type might be 'Bobble' and it has properties 'Width', 'Volume', and 'Friction Coefficient'.  So in order to search for these types I'm forced to dynamically construct a search screen.

This dynamic search screen is where the issue comes in.  Because I'm searching an indiscriminate number of properties and I don't know at compile time what those properties are, I need to execute some type of dynamic query.  Those of you who are familiar with LINQ will know that this is easier said than done.  It's not like I can just construct a SQL statement at runtime and then pass it to the database for execution.  Enter the System.Linq.Dynamic namespace.

I found this blog post by ScottGu on the exact subject.  (The post is labeled Part 1 but I haven't been able to find a Part 2 anywhere…if you find it let me know.)  His post will point you to where you can download the source for the System.Linq.Dynamic assembly which you'll need to build and include in your project.  I did see mentioned that this is part of .NET 3.5 SP1, however I was unable to find it on my system.

Once you have the library referenced it becomes quite a bit simpler to generate a query at runtime.  The library parses an expression syntax that's pretty simple.  The primary use for generating queries at runtime is going to be setting up WHERE conditions; you can however create an entire query dynamically if you need to.  Here's an example of a LINQ query as it would be written at design time:

var items = (from InventoryItem item in db.InventoryItem
             where item.Category.ID = 7
             select item).ToList<InventoryItem>();

This is a pretty innocuous query and doesn't really warrent being turned into a dynamic query but for example's sake, here's how you'd write it:

var items = db.InventoryItem.Where("Category.ID = @0", 7).ToList<InventoryItem>();

It's really that simple.  After you include System.Linq.Dynamic in your using statements a new overload of the Where method is available.  This new version of Where takes a string predicate (the where statement) and an array of objects that are parameters for the query string.

Because you don't have the benefit of type safety within the query string, you'll have to be careful with your syntax.  For example, when using a property of a property (item.Category.ID in the above example) you have to remember to use the names you've assigned to entities in your model not the names in the underlying data source.

There are other ways to create a query dynamically including using ObjectQuery<T>, or building up predicates in a pseudo-recursive way as in this post from the C# 3.0 in a Nutshell guys.  However, I find the dynamic query method here to be easy to understand and very powerful.