Scott's Blog

An xVal Provider For NHibernate Validator

2009-11-02T18:13:32Z

I wrote a post about a month ago about using xVal with NHibernate Validator 1.2 which solved a problem I was having upgrading the xVal ‘in-the-box’ provider to work with a newer version of NHibernate Validator. There was a caveat that my solution only worked for ValidatorMode.UseAttribute and I wouldn’t catch XML or Loquacious (or other?) validation. This seemed to work OK, but Fabio Maulo wrote a comment to that post saying NHV has metadata which should be the same no matter which validation mode was used.

So I decided to investigate how I could get the metadata without resorting to the NHibernate.Validator.Mappings validationMode specific engines (I was using ReflectionClassMapping, but there are others like XmlClassMapping).

I think I found the solution (at least, it does work…) in the ValidatorEngine’s GetClassValidator method. GetClassValidator takes in a System.Type and returns an IClassValidator for that Type. Once you have the class validator, you can get constraints for any member of that class by using GetMemberConstraints(memberName).

After getting the constraints you are onto the easy part, which is basically just mapping the rules into xVal rules and the code is much the same as before.

So without further ado, here is the new ValidatorRulesProvider implementation:

public class ValidatorRulesProvider : CachingRulesProvider

    private readonly RuleEmitterList<IRuleArgs> _ruleEmitters;

    public ValidatorRulesProvider()

        _ruleEmitters = new RuleEmitterList<IRuleArgs>();

        _ruleEmitters.AddSingle<LengthAttribute>(x => new StringLengthRule(x.Min, x.Max));

        _ruleEmitters.AddSingle<MinAttribute>(x => new RangeRule(x.Value, null));

        _ruleEmitters.AddSingle<MaxAttribute>(x => new RangeRule(null, x.Value));

        _ruleEmitters.AddSingle<RangeAttribute>(x => new RangeRule(x.Min, x.Max));

        _ruleEmitters.AddSingle<NotEmptyAttribute>(x => new RequiredRule());

        _ruleEmitters.AddSingle<NotNullNotEmptyAttribute>(x => new RequiredRule());

        _ruleEmitters.AddSingle<NotNullAttribute>(x => new RequiredRule());

        _ruleEmitters.AddSingle<PatternAttribute>(x => new RegularExpressionRule(x.Regex, x.Flags));

        _ruleEmitters.AddSingle<EmailAttribute>(x => new DataTypeRule(DataTypeRule.DataType.EmailAddress));

        _ruleEmitters.AddSingle<DigitsAttribute>(MakeDigitsRule);

    protected override RuleSet GetRulesFromTypeCore(Type type)

        var classMapping = new ValidatorEngine().GetClassValidator(type);

        var rules = from member in type.GetMembers()

                    where member.MemberType == MemberTypes.Field || member.MemberType == MemberTypes.Property

                    from constraint in classMapping.GetMemberConstraints(member.Name).OfType<IRuleArgs>()

                    // All NHibernate Validation validators attributes must implement this interface

                    from rule in ConvertToXValRules(constraint)

                    where rule != null

                    select new { MemberName = member.Name, Rule = rule };

        return new RuleSet(rules.ToLookup(x => x.MemberName, x => x.Rule));

    private IEnumerable<Rule> ConvertToXValRules(IRuleArgs ruleArgs)

        foreach (var rule in _ruleEmitters.EmitRules(ruleArgs))

            if (rule != null)

                rule.ErrorMessage = MessageIfSpecified(ruleArgs.Message);

                yield return rule;

    private static RegularExpressionRule MakeDigitsRule(DigitsAttribute att)

        if (att == null) throw new ArgumentNullException("att");

        string pattern;

        if (att.FractionalDigits < 1)

            pattern = string.Format(@"\d{{0,{0}}}", att.IntegerDigits);

        else

            pattern = string.Format(@"\d{{0,{0}}}(\.\d{{1,{1}}})?", att.IntegerDigits, att.FractionalDigits);

        return new RegularExpressionRule(pattern);

    private static string MessageIfSpecified(string message)

        // We don't want to display the default {validator.*} messages

        if ((message != null) && !message.StartsWith("{validator."))

            return message;

        return null;

Of course in the global.asax file you just need to hook xVal and this class together like so:

xVal.ActiveRuleProviders.Providers.Add(

    new NHibernateValidatorRulesProvider(

    ValidatorMode.UseAttribute));

If you aren’t using xVal I would highly recommend it, and if you are using ASP.NET MVC and not using xVal, what are you waiting for? They are a great match!

Enjoy!

Major Hack: Repository Tests With NHibernate And SQLite on a CI Server

2009-10-20T14:50:00Z

I recently setup my first continuous integration build server using JetBrains’ TeamCity product, and it couldn’t have been much simpler. However I kept running into an issue with my test projects whenever I was using NHibernate or SQLite (very useful or regression tests against an in-memory database).

The Problem

Everything would run correctly locally using MSTest, but when TeamCity ran the tests I would get the following error:

Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory,
NHibernate.ByteCode.Castle' during configuration of proxy factory
class.
Possible causes are:
- The NHibernate.Bytecode provider assembly was not deployed.
- The typeName used to initialize the 'proxyfactory.factory_class'
property of the session-factory section is not well formed.

Solution:
Confirm that your deployment folder contains one of the following
assemblies:

Of course I’ve seen this error before and I double checked that I had a reference to the NHibernate bytecode provider and that my NHibernate.config file was configured correctly. I thought maybe this was a x86 vs x64 issue, but that also did not seem to be the case.

Eventually running MSTest locally through the command line reproduced the error, and after I searched around for a while I found that NHibernate.ByteCode.Castle.dll was not be deployed into the specific TestProject\bin\Release\ folder (and neither was SQLite).

I made sure my test project had a reference to both DLLs, that is was set to copy local, and still they were not copied to my “deployment” directory.

The Reason

From what I could gather, msbuild was being ‘smart’ and optimizing my build such that the bytecode and SQLite DLLs were not being included since they were never directly referenced in code. This is because they are referenced only in the NHibernate.config file.

The Solution (aka Major Hack)

In order to get the proper DLLs included in the build I had to reference them somewhere in code, so I made a totally unreachable class that should never be instantiated, as follows:

/// <summary>

/// NOTE: This is a hack to make sure that the castle

/// and SQLLite assemblies are copied into the Test deployemnt directory

/// This class never gets called.

/// </summary>

public class ContinuousIntegrationDeploymentHack

    public ContinuousIntegrationDeploymentHack()

        new NHibernate.ByteCode.Castle.ProxyFactoryFactory();

        new System.Data.SQLite.SQLiteException();

        throw new Exception("This class should never be called or instantiated");

Adding this class anywhere into my test project does the trick – the castle bytecode and SQLite DLLs are now copied into the deployment directory and all tests run correctly.

The Future

I am sure the proper way to solve this was to use MSBuild or NAnt and copy the files correctly, but I am currently using the easy TeamCity sln2008 runner and thus there are no custom tasks that I can run.

Required Validator For NHibernate Validators

2009-10-15T17:46:51Z

I’ve recently switched from the Enterprise Library Validation Application Block to using NHibernate Validators. If you are not familiar with the NHibernate Validator project, they are part of the NHibernate Contrib project and offer Validation constraints, and validation runner, and tight integration with NHibernate (especially great if you use NHibernate to generate your DB).

One of the main reasons for my switch was integration with xVal (which EntLib Validation’s implementation prevents), and also to get some advanced but common validators like Email, Size, NotNullNotEmpty.

Anyway, I would recommend that you look at NHibernate Validator if you use NHibernate and are looking for a validation framework. However, this post is about writing a new validator that will integrate with NHibernate Validators – the Required validator.

Motivation for the Required Validator

Many of the varchar/nvarchar columns in my database are set to NotNull, and I also want to go a step further and make sure that they can’t be empty strings or just spaces.

There does exist a NotNull validator and a NotEmpty validator which work correctly on their own or combined, and there is a NotNullNotEmpty validator as well.

However, the NotNullNotEmpty validator only works on IEnumerable types, even though the NotNull and NotEmpty validator work on strings.

So What Can We Do?

First, and simplest, is to put both a NotNull and a NotEmpty validator on each string property. In my case, our team was already familiar with a required validator and I found they were confused when the NotNullNotEmpty validator didn’t combine the two.

Option 2 is to write your own validator, which I did with the Required validator.

Required Validator

In order to make a custom NHibernate Validtor with accompanying Attribute, you should write two classes.

The first is the validator class, which should implement IValidator (NHibernate.Validator.Engine.IValidator). This just defines one method, IsValid() which returns a bool. The whole implementation is as follows:

/// <summary>

/// Required Validator means the value can not be null or empty (or only spaces)

/// </summary>

public class RequiredValidator : IValidator

    public bool IsValid(object value, IConstraintValidatorContext constraintValidatorContext)

        if (value == null)

            return false;

        var check = value as string;

        if (check != null)

            return !string.Empty.Equals(check.Trim());

        var ev = value as IEnumerable;

        if (ev != null)

            return ev.GetEnumerator().MoveNext();

        return false;

Basically this first checks if the value is null – if it is we return that this object is not valid. After that we just copy the code from the NotEmpty validator and check to see if a trimmed version of the string is not equal to string.Empty. It also can check for empty Enumerables just like NotNullNotEmpty.

Required Attribute

The second class to write is an attribute which handles the parameters and message, and uses the ValidatorClass[] attribute to tell the validation runner which validator it executes.

[Serializable]

[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property)]

[ValidatorClass(typeof(RequiredValidator))]

public class RequiredAttribute : Attribute, IRuleArgs

    public string Message

        get { return _message; }

        set { _message = value; }

    private string _message = "{validator.notNullNotEmpty}"; //Use the not empty language by default

Usage

Of course you can use this just like any other NHibernate Validator and even side by side with existing validators:

[Length(50)]

[Required]

public virtual string FirstName { get; set; }

[Length(50)]

[Required]

public virtual string LastName { get; set; }

Integration with xVal

Integration with xVal just takes one more line inside the validation rules provider (see my post on using xVal with NHibernate Validator)

ruleEmitters.AddSingle<RequiredAttribute>(x=>new RequiredRule());

Conclusion

We now have a Required Validator that we can use in our project, and it even integrates with xVal. Now this was a really simple change, but I’ll write soon about some more complex custom validators which might prove helpful.

Common Web.Config transformations with Visual Studio 2010

2009-10-13T16:23:00Z

I’ve been playing with Visual Studio 2010 Beta a little and one of my favorite new features (and there are many) is the new web.config transformation feature.

Web.config transformations are setup so there is one configuration “delta” for each build configuration that you have (default are Debug and Release). When you build your solution (as a package, when you publish, etc) your original web.config is transformed according to the settings in your web.debug.config file (assuming the debug configuration).

There are plenty of blogs and msdn references out there for you to look at but I thought I’d write a quick post that would get you up to date on how to do the some common web.config transformations.

First, A Tiny Iota (That guy was great!) of XDT Review

As it pertains to web.config replacements, you need to know that every XML element can have two xdt attributes: xdt:Tranform and xdt:Locator

Transform: What you want to do with the XML element
- You might want to Replace it, set an attribute (SetAttribute), remove an attribute (RemoveAttribute), etc.
Locator: Where is the element that needs transformation?
- You probably want to transform an element that matches (Match) a specific attribute value

Case 1: Replacing all AppSettings

This is the overkill case where you just want to replace an entire section of the web.config. In this case I will replace all AppSettings in the web.config will new settings in web.release.config. This is my baseline web.config appSettings:

<appSettings>

  <add key="KeyA" value="ValA"/>

  <add key="KeyB" value="ValB"/>

</appSettings>

Now in my web.release.config file, I am going to create a appSettings section except I will include the attribute xdt:Transform=”Replace” since I want to just replace the entire element. I did not have to use xdt:Locator because there is nothing to locate – I just want to wipe the slate clean and replace everything.

<appSettings xdt:Transform="Replace">

  <add key="ProdKeyA" value="ProdValA"/>

  <add key="ProdKeyB" value="ProdValB"/>

  <add key="ProdKeyC" value="ProdValC"/>

</appSettings>

Note that in the web.release.config file my appSettings section has three keys instead of two, and the keys aren’t even the same. Now let’s look at the generated web.config file what happens when we publish:

<appSettings>

  <add key="ProdKeyA" value="ProdValA"/>

  <add key="ProdKeyB" value="ProdValB"/>

  <add key="ProdKeyC" value="ProdValC"/>

</appSettings>

Just as we expected – the web.config appSettings were completely replaced by the values in web.release config. That was easy!

Case 2: Replacing a specific AppSetting’s value

Ok, so case 1 was the nuclear option, what about doing something a little more practical? Let’s go back to our original AppSettings web.config example:

<appSettings>

  <add key="KeyA" value="ValA"/>

  <add key="KeyB" value="ValB"/>

</appSettings>

Let’s say that we just want to replace KeyB’s value to something more suited for a production environment. This time we get to use both xdt:Transform and xdt:Locator.

Our strategy will be to define (in web.release.config) an appSettings section that has just the replacements we want to make. It will initially look like this:

<appSettings>

  <add key="KeyB" value="ProdValA" />

</appSettings>

Now we want to add in the transforms so that we replace any appSetting that matches this key (KeyB).

<appSettings>

  <add key="KeyB" value="ProdValA" xdt:Transform="Replace" xdt:Locator="Match(key)" />

</appSettings>

Once we publish our resulting web.config file looks like this:

<appSettings>

  <add key="KeyA" value="ValA"/>

  <add key="KeyB" value="ProdValA"/>

</appSettings>

Perfect – We replaced KeyB but left KeyA (and any other keys if they were to exist) alone.

Case 3: Replace Compilation Debug=”true”

This is a simple one because Microsoft gives it to us out of the box – but I’ll reproduce it here anyway because it illustrates a common scenario and shows that there are more transforms then just Replace:

<system.web>

  <compilation xdt:Transform="RemoveAttributes(debug)" />

</system.web>

There are also ways to SetAttributes, Remove elements, Insert elements, and much more

To Infinity – And Beyond

We have obviously just scratched the surface, but for now that’s as deep as I need to go. Until next time, you can look at the MSDN reference for Web.Config transformations at http://msdn.microsoft.com/en-us/library/dd465326%28VS.100%29.aspx.

Enjoy!

MVCContrib FluentHTML Select Lists and NHibernate

2009-10-08T13:59:42Z

When using ASP.NET MVC you will eventually want to do a select (drop down) or even a multiple select list, and your first though might be to use <%= Html.DropDownList %>. Unfortunately you will soon notice that ASP.NET MVC always looks for a match between the name of the dropdown and a property on the model, and if it finds a match, it OVERRIDES the selected value(s) of the select list. Now of course not being able to reliably set the selected value(s) is a major problem – if you Google this you will get a ton of results and most people solve the issue by just changing the name of the Html.DropDownList(“name”) to something that doesn’t match a model property.

Of course we can put this into the “hack” or “workaround” category, and I don’t like doing that on my nice shiny MVC project. However, the biggest problem is if you are doing advanced model binding (I have my own impl, but as an example look at SharpArchitecture), changing the name of the drop down will break model binding and model state errors.

So – how do we use drop down lists and maintain our control over naming and selected items? Enter MVCContrib’s FluentHTML:

MVCContrib FluentHTML Select and MultiSelect

Once you copy the MVCContrib.FluentHTML DLL into your project and resolve the namespace, you get a whole bunch of nice Html helpers right on the base View Data Container. We want to look at the Select and MultiSelect options, which you would use as follows:

<%= this.MultiSelect("User.Projects").Options(Model.Projects) %>

Now moving past the default case, you’ll want to choose which properties to bind and maybe which values are selected. The following is how I attempted to do this at first:

<%= this.MultiSelect("User.Projects")
    .Options(new MultiSelectList(Model.Projects, "ID", "Name", 
                Model.User.Projects.Select(a=>a.ID)))%>

There is also another option which involves calling .Selected() instead of putting the selected values directly in the MultiSelectList ctor.

<%= this.MultiSelect("User.Projects")
    .Options(new MultiSelectList(Model.Projects, "ID", "Name"))
    .Selected(Model.User.Projects.Select(a=>a.ID)) %>

The Problem

When using NHibernate, or likely any other ORM, you run into a subtle problem. Occasionally you will get the following errors when binding MultiSelect (note this problem also happens using the Select):

Object does not match target type.

Exception Details: System.Reflection.TargetException: Object does not match target type.

It takes a lot of debugging, but you eventually discover that this only occurs when binding to proxied instances. So for this example, I had NHibernate get me a list of all Projects and since lazy-load was set to true (the default), some of these came back as proxies. When trying to get the ID value of these proxies, you get the exception thrown from within System.Reflection.

The Solution

The solution here is to use an overload of Options() to put the valueField and textField into the method call and NOT into the constructor of a SelectList/MultiSelectList. You can either use strings of selectors, as you can see below:

<%= this.MultiSelect("User.Projects")
    .Options(Model.Projects, "ID", "Name")
    .Selected(Model.User.Projects.Select(a=>a.ID)) %>

<%= this.MultiSelect("User.Projects")
    .Options(Model.Projects, a=>a.ID, a=>a.Name)
    .Selected(Model.User.Projects.Select(a=>a.ID)) %>

Now, there is no reflection errors. Enjoy!

Using xVal with NHibernate Validator 1.2

2009-09-29T17:45:00Z

This will be a quick and dirty post about how to get xVal 1.0 (http://xval.codeplex.com/) to work with the new NHibernate Validator 1.2beta (http://nhforge.org/media/p/7.aspx).

The problem is that xVal 1.0 ships with a NHibernate Validator (NHVal) Ruleset Provider which does not compile against the 1.2beta DLLs because of some API changes. Meanwhile, S#arp Architecture uses NHVal 1.2 so using those Dlls is a requirement for me.

In the process of rewriting the NHVal ruleset provider I stripped out all XML rule definition support, so for my code to work you must be using NHVal attributes.

With those disclaimers, here is the code:

public class NHibernateValidatorRulesProvider : CachingRulesProvider

    private readonly ValidatorMode configMode;

    private readonly RuleEmitterList<IRuleArgs> ruleEmitters = new RuleEmitterList<IRuleArgs>();

    public NHibernateValidatorRulesProvider(ValidatorMode configMode)

        this.configMode = configMode;

        ruleEmitters.AddSingle<LengthAttribute>(x => new StringLengthRule(x.Min, x.Max));

        ruleEmitters.AddSingle<MinAttribute>(x => new RangeRule(x.Value, null));

        ruleEmitters.AddSingle<MaxAttribute>(x => new RangeRule(null, x.Value));

        ruleEmitters.AddSingle<RangeAttribute>(x => new RangeRule(x.Min, x.Max));

        ruleEmitters.AddSingle<NotEmptyAttribute>(x => new RequiredRule());

        ruleEmitters.AddSingle<NotNullNotEmptyAttribute>(x => new RequiredRule());

        ruleEmitters.AddSingle<PatternAttribute>(x => new RegularExpressionRule(x.Regex, x.Flags));

        ruleEmitters.AddSingle<EmailAttribute>(x => new DataTypeRule(DataTypeRule.DataType.EmailAddress));

        ruleEmitters.AddSingle<DigitsAttribute>(MakeDigitsRule);

    protected override RuleSet GetRulesFromTypeCore(Type type)

        var classMapping = ClassMappingFactory.GetClassMapping(type, configMode);

        var rules = from member in type.GetMembers()

                    where member.MemberType == MemberTypes.Field || member.MemberType == MemberTypes.Property

                    from att in classMapping.GetMemberAttributes(member).OfType<IRuleArgs>()

                    // All NHibernate Validation validators attributes must implement this interface

                    from rule in ConvertToXValRules(att)

                    where rule != null

                    select new {MemberName = member.Name, Rule = rule};

        return new RuleSet(rules.ToLookup(x => x.MemberName, x => x.Rule));

    private IEnumerable<Rule> ConvertToXValRules(IRuleArgs att)

        foreach (var rule in ruleEmitters.EmitRules(att))

            if (rule != null)

                rule.ErrorMessage = MessageIfSpecified(att.Message);

                yield return rule;

    private string MessageIfSpecified(string message)

        // We don't want to display the default {validator.*} messages

        if ((message != null) && !message.StartsWith("{validator."))

            return message;

        return null;

    private RegularExpressionRule MakeDigitsRule(DigitsAttribute att)

        if (att == null) throw new ArgumentNullException("att");

        string pattern;

        if (att.FractionalDigits < 1)

            pattern = string.Format(@"\d{{0,{0}}}", att.IntegerDigits);

        else

            pattern = string.Format(@"\d{{0,{0}}}(\.\d{{1,{1}}})?", att.IntegerDigits, att.FractionalDigits);

        return new RegularExpressionRule(pattern);

    private static class ClassMappingFactory

        public static IClassMapping GetClassMapping(Type type, ValidatorMode mode)

            const IClassMapping result = null;

            switch (mode)

                case ValidatorMode.UseAttribute:

                    break;

                default:

                    throw new NotImplementedException("Only attributes are supported");

            return result ?? new ReflectionClassMapping(type);

Now in the global.asax file, you just need to hook xVal and this class together like so:

xVal.ActiveRuleProviders.Providers.Add(

                new NHibernateValidatorRulesProvider(

                    ValidatorMode.UseAttribute));

Enjoy!

Save Your Codeplex Repository Credentials

2009-09-24T22:57:00Z

I recently setup my first project ever in CodePlex and naturally I am very excited about its tight integration with TFS since my group uses TFS internally for source control as well. Connecting to CodePlex through the Visual Studio Team Explorer is very easy, you just use one of the tfs0x.codeplex.com servers as your target, and then give them a variation of your username and password to connect.

The prompt for your password will come up every time you open VS, and there is no option to save your credentials. I like security as much as the next guy, but after a while this becomes tedious and it was proving to be a stumbling block to adoption among some team members.

How To Store Your Credentials

The solution I came up with was to use the Windows credential manager to save my CodePlex credentials. Here are the steps:

Find the credential manager (Control Panel –> User Accounts –> Credential Manager)
Click on “Add a Windows credential”
Enter your codeplex login information (see the picture below)
Click Ok

The next time you open up any project on that codeplex TFS server, your credentials will automatically be passed!

Enjoy

Visual Studio 2008 with TFS Explorer broken with SP1

2009-09-22T14:47:00Z

When working in on a fresh Visual Studio 2008 SP1 install I needed to use TFS (as always) so I installed the TFS Team Explorer client from the TFS disk and I kept getting the following error whenever trying to view/edit Work Items:

Could not load type 'Microsoft.TeamFoundaton.WorkItemTracking.Client.WorkItemTypeDeniedOrNotExistException' from assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client, Version=9.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

After trying several fixes on different boxes, I think it is really a simple versioning problem, where VS SP1 upgrades some TFS dlls and then the old TFS client get installed and can’t load the correct dlls.

I have not tested this, but I bet if you install TFS Team Explorer before you install VS SP1 then things will work out OK.

If You Have This Problem

It seems the solution is simple to reinstall VS 2008 SP1 and it will fix up the dlls. Don’t worry too much about the install time, it is much faster to repair SP1 then install in fresh the first time.

I Hope this helps.

Base Class Object Equality for NHibernate Objects

2009-09-21T20:49:00Z

In any project where you use an ORM you often have all of your domain classes inherit from a common base class. Among other things, your base class often contains your identity property. Mine has a protected IdT (this is the Id type) field called id, and a public getter called ID.

   1: protected IdT id;

2:

   3: public virtual IdT ID

   4: {

   5:     get { return id; }

   6: }

One important and complex question is how to handle equality of two domain objects. This becomes very important for caching, using HashSets, and more.

Before I share my solution I will mention that there are many implementations of base class equality out there, with S#arp Architecture’s standing out in my mind as a great though complex (maybe enterprise-level is a better word) variation.

Defining Equality

My idea of equality is that the base class will do its best to define equality that will work for most domain objects, but if a subclass would like to override Equals() then they are more than welcome.

Overall I would like domain object equality to use the following general criteria:

Two domain objects are equal if they are the same object (by reference).

If they are not the same object, one cannot be null, and they must be castable to each other [This one is tricky since we can’t use type equality because one might be a proxy type].

If the above criteria validate, then the Ids of the two objects must match but be non-default [So two transient object are always non-equal, and a persisted object can never equal a transient object].

Testing Equality Assumptions

Before I implement equals, I’ll write tests which verify all of my assumptions.

   1: [TestClass]

   2: public class EqualityTests

   3: {

   4:     [TestMethod]

   5:     public void EqualsWithTwoNullObjectsReturnsTrue()

   6:     {

   7:         const SimpleDomainObject obj1 = null;

   8:         const SimpleDomainObject obj2 = null;

9:

  10:         var equality = Equals(obj1, obj2);

11:

  12:         Assert.AreEqual(true, equality);

  13:     }

14:

  15:     [TestMethod]

  16:     public void EqualsWithNullObjectReturnsFalse()

  17:     {

  18:         const SimpleDomainObject obj1 = null;

  19:         var obj2 = new SimpleDomainObject();

20:

  21:         var equality = Equals(obj1, obj2);

22:

  23:         Assert.AreEqual(false, equality);

  24:     }

25:

  26:     [TestMethod]

  27:     public void EqualsWithTransientObjectsReturnsFalse()

  28:     {

  29:         var obj1 = new SimpleDomainObject();

  30:         var obj2 = new SimpleDomainObject();

31:

  32:         var equality = Equals(obj1, obj2);

33:

  34:         Assert.AreEqual(false, equality);

  35:     }

36:

  37:     [TestMethod]

  38:     public void EqualsWithOneTransientObjectReturnsFalse()

  39:     {

  40:         var obj1 = new SimpleDomainObject();

  41:         var obj2 = new SimpleDomainObject();

42:

  43:         obj1.SetId(1);

44:

  45:         var equality = Equals(obj1, obj2);

46:

  47:         Assert.AreEqual(false, equality);

  48:     }

49:

  50:     [TestMethod]

  51:     public void EqualsWithDifferentIdsReturnsFalse()

  52:     {

  53:         var obj1 = new SimpleDomainObject();

  54:         var obj2 = new SimpleDomainObject();

55:

  56:         obj1.SetId(1);

  57:         obj2.SetId(2);

58:

  59:         var equality = Equals(obj1, obj2);

60:

  61:         Assert.AreEqual(false, equality);

  62:     }

63:

  64:     [TestMethod]

  65:     public void EqualsWithSameIdsReturnsTrue()

  66:     {

  67:         var obj1 = new SimpleDomainObject();

  68:         var obj2 = new SimpleDomainObject();

69:

  70:         obj1.SetId(1);

  71:         obj2.SetId(1);

72:

  73:         var equality = Equals(obj1, obj2);

74:

  75:         Assert.AreEqual(true, equality);

  76:     }

77:

  78:     [TestMethod]

  79:     public void EqualsWithSameIdsInSubclassReturnsTrue()

  80:     {

  81:         var obj1 = new SimpleDomainObject();

  82:         var obj2 = new SubSimpleDomainObject();

83:

  84:         obj1.SetId(1);

  85:         obj2.SetId(1);

86:

  87:         var equality = Equals(obj1, obj2);

88:

  89:         Assert.AreEqual(true, equality);

  90:     }

91:

  92:     [TestMethod]

  93:     public void EqualsWithDifferentIdsInDisparateClassesReturnsFalse()

  94:     {

  95:         var obj1 = new SimpleDomainObject();

  96:         var obj2 = new OtherSimpleDomainObject();

97:

  98:         obj1.SetId(1);

  99:         obj2.SetId(2);

 100:

 101:         var equality = Equals(obj1, obj2);

 102:

 103:         Assert.AreEqual(false, equality);

 104:     }

 105:

 106:     [TestMethod]

 107:     public void EqualsWithSameIdsInDisparateClassesReturnsFalse()

 108:     {

 109:         var obj1 = new SimpleDomainObject();

 110:         var obj2 = new OtherSimpleDomainObject();

 111:

 112:         obj1.SetId(1);

 113:         obj2.SetId(1);

 114:

 115:         var equality = Equals(obj1, obj2);

 116:

 117:         Assert.AreEqual(false, equality);

 118:     }

 119: }

 120:

 121: public class SimpleDomainObject : DomainObject<SimpleDomainObject,int>

 122: {

 123:     public void SetId(int ident)

 124:     {

 125:         id = ident;

 126:     }

 127: }

 128:

 129: public class SubSimpleDomainObject : SimpleDomainObject{}

 130:

 131: public class OtherSimpleDomainObject : DomainObject<OtherSimpleDomainObject,int>

 132: {

 133:     public void SetId(int ident)

 134:     {

 135:         id = ident;

 136:     }

 137: }

This is a lot of code but if you look at each test by itself you’ll see that if all the tests pass I will have equality implemented correctly, or at least correctly as far as I defined it above.

If you run the tests now you will see that the tests fail when you are trying to test equality as two objects having the same Ids. Let’s implement an Equals() method and see what we can come up with.

Implementing Equals

This implementation is based off of an existing DomainObject<T,IdT> base class that is similar to the one proposed in the NHibernate Best Practices article.

   1: public override bool Equals(object other)

   2: {

   3:     if (ReferenceEquals(this, other)) return true;

4:

   5:     if (other == null || other is T == false) return false; //is returns true if other is castable to T

6:

   7:     return Equals(other as DomainObject<T, IdT>);

   8: }

9:

  10: private bool Equals(DomainObject<T, IdT> other)

  11: {

  12:     if (ReferenceEquals(null, other)) return false;

13:

  14:     //Domain objects are equal if their ids are equal and non-default

  15:     if (Equals(id, default(IdT))) return false;

16:

  17:     return Equals(id, other.id);

  18: }

Now if we run the tests we get all greens!

Getting the HashCode

Whenever you override Equals(), it is recommended that you override GetHashCode(). In our case this is pretty easy, since we just want to use the id’s HashCode (or the base HashCode if id is null/default).

UPDATE: Modified GetHashCode() to include the base class’ hash code so we get less collisions between disparate classes.

   1: public override int GetHashCode()

   2: {

   3:     return Equals(id, default(IdT)) ? base.GetHashCode() : (base.GetHashCode() * 31) + id.GetHashCode();

   4: }

   1: public override int GetHashCode()

   2: {

   3:     return Equals(id, default(IdT)) ? base.GetHashCode() : id.GetHashCode();

   4: }

Enjoy!

A UrlHelper Extension For Creating Absolute Action Paths in ASP.NET MVC

2009-09-17T17:41:00Z

ASP.NET MVC comes with a UrlHelper class in the System.Web.Mvc.Controller.Url namespace, which you can access through the Url property of any controller. This provides some handy methods to get the url of an action or route, among other things. For example, Url.Action(“About”, “Home”) will return the string “/Home/About”, which is the relative url of the About action on the Home controller.

I recently had a need to generate an absolute Url (to put in an email), so I wrote a quick extension method to the UrlHelper class that I thought might be useful to someone else. The code is as follows:

   1: public static class UrlExtensions

   2: {

   3:     public static string AbsoluteAction(this UrlHelper url, string action, string controller, object routeValues)

   4:     {

   5:         Uri requestUrl = url.RequestContext.HttpContext.Request.Url;

6:

   7:         string absoluteAction = string.Format("{0}{1}",

   8:                                               requestUrl.GetLeftPart(UriPartial.Authority),

   9:                                               url.Action(action, controller, routeValues));

10:

  11:         return absoluteAction;

  12:     }

  13: }

Basically is takes the same values as Url.Action (or at least one of the Url.Action signatures) and adds the “left part” of the authority (see the MSDN Library GetLeftPart Docs).

So if you write the following code:

   1: Url.AbsoluteAction("Edit", "Users", new {id="username"});

You should get something like the following result if you are running it locally:

http://localhost:50717/Users/Edit/username

Enjoy!

Simple auditing using an NHibernate IInterceptor (Part 4)

2009-09-15T16:58:00Z

This is the fourth and final post of a multi-part post series on writing simple auditing functionality for an ASP.NET application using NHibernate. The requirement was that every object modification event in the system should be logged by username and date. Specifically I don’t need to know exactly which properties were changed (just that a user was updated by whom at what time), but if you do need to save the changed properties there are plenty of hooks to do that.

I’ll update this post with links to the next parts when they become available

Part 1
Part 2
Part 3
Part 4 (you are here)

Hooking up the NHibernate IInterceptor

Now that we have written our IInterceptor, implemented as the AuditInterceptor class, we need to tell NHibernate to use it. This part will vary depending on how NHibernate is exposed to your application, but the basic idea is that when you open a session (using OpenSession() on your NHibernate session factory) you will pass along the interceptor as a parameter. If you have no interceptor, you can just call OpenSession().

Extending the NHibernate Session Manager

Our session manager class follows loosely with the thread-safe, lazy singleton patterned NHibernateSessionManager described in the NHibernate Best Practices Article. Adding hooks for a persistent interceptor was pretty easy – first I wrote a method for registering an interceptor:

   1: /// <summary>

   2: /// Allows you to set the interceptor which will be used in all subsequent sessions

   3: /// </summary>

   4: public void RegisterInterceptor(IInterceptor interceptor)

   5: {

   6:     Check.Require(interceptor != null, "interceptor may not be null");

7:

   8:     _registeredInterceptor = interceptor;

   9: }

This just sets a local static IInterceptor property called _registeredInterceptor. This is used whenever opening a session, as follows:

   1: /// <summary>

   2: /// Shortcut which just calls into the GetSession overload with the current registered interceptor.

   3: /// If no interceptor has been registered, it will be null

   4: /// </summary>

   5: public ISession GetSession()

   6: {

   7:     return GetSession(_registeredInterceptor);

   8: }

9:

  10: /// <summary>

  11: /// Gets a session with or without an interceptor.  This method is not called directly; instead,

  12: /// it gets invoked from GetSession.

  13: /// </summary>

  14: private ISession GetSession(IInterceptor interceptor)

  15: {

  16:     ISession session = ThreadSession;

17:

  18:     if (session == null)

  19:     {

  20:         session = interceptor != null ? sessionFactory.OpenSession(interceptor) : sessionFactory.OpenSession();

21:

  22:         ThreadSession = session;

  23:     }

24:

  25:     Check.Ensure(session != null, "session was null");

26:

  27:     return session;

  28: }

So once the IInterceptor is registered, all future calls to GetSession() will open a session using that interceptor (of course you could null it out again later, though I am not sure why you would want to).

Registering the Interceptor

On Application_Start in the global.asax file I call into the NHibernateSessionManager’s RegisterInterceptor method (seen above). The interceptor I want to register will be resolved by Castle Windsor through IoC/DI.

   1: //Configure the audit interceptor

   2: NHibernateSessionManager.Instance.RegisterInterceptor(windsorContainer.Resolve<IInterceptor>());

To tell Castle Windsor to use the AuditInterceptor, we add the following line to the IoC container registration:

   1: container.AddComponent("auditInterceptor", typeof (NHibernate.IInterceptor), typeof (AuditInterceptor));

And we are done – The interceptor has now been written, tested, and integrated into the NHibernate pipeline. Now we get to try it out.

Trying It Out

We are going to add a new “project” instance to our database. Basically in the code ASP.NET MVC creates a new Project instance with a Name property set, and makes sure it is Active by default. The code is kind of beside the point but I’ll post it anyway just make clear how transparent this interceptor is:

   1: [AcceptPost]

   2: public ActionResult CreateProject(Project newProject)

   3: {

   4:     CreateEntity<Project, int>(newProject, "Project");

5:

   6:     return this.RedirectToAction(a => a.Projects());

   7: }

8:

   9: private void CreateEntity<T, IdT>(T entity, string type) where T : DomainObject<T, IdT>

  10: {

  11:     var lookupEntity = entity as LookupObject<T, IdT>; // If this is a lookup entity we want to make sure isActive is true

12:

  13:     if (lookupEntity != null) lookupEntity.IsActive = true;

14:

  15:     ValidationHelper<T>.Validate(entity, ModelState);

16:

  17:     if (!ModelState.IsValid)

  18:     {

  19:         return;

  20:     }

21:

  22:     //Add the new entity

  23:     Repository.OfType<T>().EnsurePersistent(entity);

  24: }

Let’s see (using NH Profiler) what happened to the database:

Perfect! We have two Insert Into statements wrapped in a transaction. The first statement saves the Project (I didn’t show it, but it is a simple Insert Into Projects with name = “NewProject”), and then second statement saves the audit record. You can see in the Details tab below that the record shows a Project was created by ‘srkirkland’ and saves the exact time of the action.

An update an delete look pretty much the same – here’s a quick screenshot of an update record being audited:

Ok – everything looks good. In the last four posts we have created a fully transparent auditing solution for recording all create/update/delete actions without our application. Pretty powerful stuff!

Simple auditing using an NHibernate IInterceptor (Part 3)

2009-09-10T20:39:00Z

This is the third post of a multi-part post series on writing simple auditing functionality for an ASP.NET application using NHibernate. The requirement was that every object modification event in the system should be logged by username and date. Specifically I don’t need to know exactly which properties were changed (just that a user was updated by whom at what time), but if you do need to save the changed properties there are plenty of hooks to do that.

I’ll update this post with links to the next parts when they become available

Part 1
Part 2
Part 3 (you are here)
……
Part N

The AuditObjectModification Method

In Part 2 we wrote a bunch of tests for the AuditObjectModification method in the AuditInterceptor.cs class. This method currently just throws a NotImplementedException:

   1: public void AuditObjectModification(object entity, object id, AuditActionType auditActionType)

   2: {

   3:     throw new NotImplementedException();

   4: }

I won’t go through each test individually (just the first one as an example), but when writing this iteratively you might want to go through each test and get them to pass one at a time.

Satisfying the First Test

Let’s start making by sure that the first test – AuditObjectModificationSouldNotSaveAuditEntity – can pass by making sure we don’t save audit objects:

   1: public void AuditObjectModification(object entity, object id, AuditActionType auditActionType)

   2: {

   3:     if (entity is Audit) return;

   4: }

And after running the tests:

And now the first test passes!

Implementing the Rest

All that is left is to create an instance of the Audit class, fill out some properties, and save it. My implementation is below:

   1: public void AuditObjectModification(object entity, object id, AuditActionType auditActionType)

   2: {

   3:     if (entity is Audit) return;

4:

   5:     var audit = new Audit

   6:     {

   7:         AuditDate = DateTime.Now,

   8:         ObjectName = entity.GetType().Name,

   9:         ObjectId = id == null ? null : id.ToString(),

  10:         Username = UserAuth.CurrentUserName

  11:     };

12:

  13:     audit.SetActionCode(auditActionType);

14:

  15:     AuditRepository.EnsurePersistent(audit);

  16: }

Now we rerun the tests:

Now that’s what I like to see!

Calling the AuditObjectModification method

No we need to call our newly implemented method from the empty overrides of the AuditInterceptor method:

   1: public override void OnDelete(object entity, object id, object[] state, string[] propertyNames, NHibernate.Type.IType[] types)

   2: {

   3:     AuditObjectModification(entity, id, AuditActionType.Delete);

4:

   5:     base.OnDelete(entity, id, state, propertyNames, types);

   6: }

7:

   8: public override bool OnSave(object entity, object id, object[] state, string[] propertyNames, NHibernate.Type.IType[] types)

   9: {

  10:     AuditObjectModification(entity, id, AuditActionType.Create);

11:

  12:     return base.OnSave(entity, id, state, propertyNames, types);

  13: }

14:

  15: public override bool OnFlushDirty(object entity, object id, object[] currentState, object[] previousState, string[] propertyNames, NHibernate.Type.IType[] types)

  16: {

  17:     AuditObjectModification(entity, id, AuditActionType.Update);

18:

  19:     return base.OnFlushDirty(entity, id, currentState, previousState, propertyNames, types);

  20: }

And we are now finished with our Audit Interceptor!

Next time we’ll hook the interceptor into NHibernate and look at the fruits of our labor.

Using jQuery Ajax methods in ASP.NET MVC: $.get() and $.getJSON() vs. $.post()

2009-09-08T18:49:57Z

I’m currently working on a project that uses ASP.NET MVC and jQuery to do some Ajax magic, and I ran into a minor (but maybe not obvious) issue when using $.post() against an MVC action that returns a JsonResult.

The core issue is that calling $.get or $.post does not by default treat the returned data as Json, which $.getJSON does. [Also, there is no $.postJSON]

First, let’s setup a little test case using a simple get request.

Calling An Action From jQuery – $.getJSON

   1: function DoAjaxCall() {

   2:     var url = '<%= Url.Action("AjaxTest", "Lookup") %>';

3:

   4:     $.getJSON(url,

   5:         null,

   6:         function(data) {

   7:             alert(data.name);

   8:         }

   9:     );

  10: }

Our JavaScript here simple calls $.getJSON(), passing along the action url and expecting back some data with a name property. The action is implemented as follows:

   1: public ActionResult AjaxTest()

   2: {

   3:     var data = new { name = "TestName"};

4:

   5:     return Json(data);

   6: }

When we run this, we get the expected result, a little popup that says “TestName”.

Calling the Action using $.post

Let’s make a few changes so that we are posting data to the action and expecting back Json. The JavaScript changes slightly, with $.getJSON turning into $.post.

   1: function DoAjaxCall() {

   2:     var url = '<%= Url.Action("AjaxTest", "Lookup") %>';

3:

   4:     $.post(url,

   5:         null,

   6:         function(data) {

   7:             alert(data.name);

   8:         }

   9:     );

  10: }

All we need to do to the action method is to add an attribute so that it will restrict itself to accepting post requests.

   1: [AcceptPost]

   2: public ActionResult AjaxTest()

   3: {

   4:     var data = new { name = "TestName"};

5:

   6:     return Json(data);

   7: }

Note that [AcceptPost] is the same thing as [AcceptVerbs(HttpVerbs.Post)]. It can be found in MVC Contrib.

When we run this example, we get a post to the correct method, but our alert box shows only ‘undefined’.

A trip into FireBug shows that our response was the following: {"name":"TestName"}

Everything looks good there, but the problem is obviously that $.post is not interpreting the return value as JSON. If you debug into the $.post callback you see that the value of the data parameter is this: "{\"name\":\"TestName\"}".

So it appears the result was stringified. The fix is to specify the type of data to be returned to the callback function as the fourth parameter to $.post(). Possible values are: "xml", "html", "script", "json", "jsonp", or "text".

Let’s try specifying the type parameter and setting it to ‘json’:

   1: function DoAjaxCall() {

   2:     var url = '<%= Url.Action("AjaxTest", "Lookup") %>';

3:

   4:     $.post(url,

   5:         null,

   6:         function(data) {

   7:             alert(data.name);

   8:         },

   9:         'json'

  10:     );

  11: }

Success! If we look at the POST response it is the same as before, but now we get the proper alert message to display “TestName”. If we debug through with firebug we see data is now an object with a single property of name (that has the value “TestName”).

What I learned

jQuery’s $.get and $.post do not natively parse the result as JSON. $.get has a helper called $.getJSON which will do the job for you, though you can achieve the same result by using $.get and passing the string ‘json’ as the fourth “type” parameter. Since there is no $.postJSON, if you are doing a jQuery ajax post and expecting a JsonResult, you must always pass ‘json’ as the fourth parameter to $.post.

Simple Auditing Using an NHibernate IInterceptor (Part 2)

2009-09-08T16:20:00Z

This is the second post of a multi-part post series on writing simple auditing functionality for an ASP.NET application using NHibernate. The requirement was that every object modification event in the system should be logged by username and date. Specifically I don’t need to know exactly which properties were changed (just that a user was updated by whom at what time), but if you do need to save the changed properties there are plenty of hooks to do that.

I’ll update this post with links to the next parts when they become available

Part 1
Part 2 (you are here)
……
Part N

The Audit Interceptor Class

In order to create an Interceptor and hook into the NHibernate entity lifecycle, you have a few options. You can implement IInterceptor (NHibernate.IInterceptory) directly but I believe it is considered best practice instead to derive your class from EmptyInterceptor since the IInterceptor interface can (and will) change between versions.

   1: public class AuditInterceptor : EmptyInterceptor { }

From this empty AuditInterceptor class you can override a number of methods from the EmptyInterceptor base class. We want to hook into create/update/delete events. Create and Delete are easy to find – you just override the OnSave() and OnDelete() methods. For updates you want the OnFlushDirty() method, which makes sense once you think about it.

So now our class looks like this:

   1: public class AuditInterceptor : EmptyInterceptor

   2: {

   3:     public override bool OnSave(object entity, object id, object[] state, string[] propertyNames, NHibernate.Type.IType[] types)

   4:     {

   5:         return base.OnSave(entity, id, state, propertyNames, types);

   6:     }

7:

   8:     public override bool OnFlushDirty(object entity, object id, object[] currentState, object[] previousState, string[] propertyNames, NHibernate.Type.IType[] types)

   9:     {

  10:         return base.OnFlushDirty(entity, id, currentState, previousState, propertyNames, types);

  11:     }

12:

  13:     public override void OnDelete(object entity, object id, object[] state, string[] propertyNames, NHibernate.Type.IType[] types)

  14:     {

  15:         base.OnDelete(entity, id, state, propertyNames, types);

  16:     }

  17: }

Now we’ll create a general method for auditing object modifications that each of the above methods will call:

   1: public void AuditObjectModification(object entity, object id, AuditActionType auditActionType)

   2: {

   3:     throw new NotImplementedException();

   4: }

So now you have the methods exposed – time to test for our expected behaviors.

Testing The Audit Interceptor

The Audit Interceptor has a constructor that takes two arguments: IUserAuth, which is a wrapper around the User.Identity.Name context, and IRepository<Audit> which provides strongly typed access into the NHibernate repository. These arguments (dependencies) are injected using Castle Windsor in production, but while testing will will provide stubs of them directly.

   1: public AuditInterceptor AuditInterceptor { get; set; }

2:

   3: public IUserAuth UserAuth { get; set; }

   4: public IRepository<Audit> AuditRepository { get; set; }

5:

   6: public AuditInterceptorTests()

   7: {

   8:     UserAuth = MockRepository.GenerateStub<IUserAuth>();

   9:     AuditRepository = MockRepository.GenerateStub<IRepository<Audit>>();

10:

  11:     AuditInterceptor = new AuditInterceptor(UserAuth, AuditRepository);

  12: }

Using Rhino Mocks to stub out the IUserAuth and IRepository<Audit> we can now begin testing the audit interceptor.

Tests:

*AuditObjectModificationSouldNotSaveAuditEntity – First we’ll test that the AuditObjectModification method will not save an audit object. If we did then it would create an infinite loop of self auditing and I’d rather not crash the web server. Basically we will just pass an audit object and make sure that the save method (repository.EnsurePersistent()) was not called.

   1: [TestMethod]

   2: public void AuditObjectModificationSouldNotSaveAuditEntity()

   3: {

   4:     AuditInterceptor.UserAuth.Expect(a => a.CurrentUserName).Return("currentUser");

5:

   6:     AuditInterceptor.AuditObjectModification(new Audit(), null, AuditActionType.Update);

7:

   8:     AuditRepository.AssertWasNotCalled(a => a.EnsurePersistent(Arg<Audit>.Is.Anything));

   9: }

*AuditObjectModificationSavesTheCurrentUser – Next we want to make sure that the current user is saved along with an audit entry.

   1: [TestMethod]

   2: public void AuditObjectModificationSavesTheCurrentUser()

   3: {

   4:     Audit audit = null;

5:

   6:     AuditInterceptor.UserAuth.Expect(a => a.CurrentUserName).Return("currentUser");

7:

   8:     AuditRepository

   9:         .Expect(a => a.EnsurePersistent(Arg<Audit>.Is.Anything))

  10:         .WhenCalled(a => audit = (Audit)a.Arguments.First());

11:

  12:     AuditInterceptor.AuditObjectModification(new object(), null, AuditActionType.Update);

13:

  14:     Assert.AreEqual("currentUser", audit.Username);

  15: }

*AuditObjectModificationLeavesObjectIdNull – Continuing along this path we now want the audit method to be able to handle null ids since newly created objects will not yet have ids.

   1: [TestMethod]

   2: public void AuditObjectModificationLeavesObjectIdNull()

   3: {

   4:     Audit audit = null;

5:

   6:     AuditInterceptor.UserAuth.Expect(a => a.CurrentUserName).Return("currentUser");

7:

   8:     AuditRepository

   9:         .Expect(a => a.EnsurePersistent(Arg<Audit>.Is.Anything))

  10:         .WhenCalled(a => audit = (Audit)a.Arguments.First());

11:

  12:     AuditInterceptor.AuditObjectModification(new object(), null, AuditActionType.Update);

13:

  14:     Assert.IsNull(audit.ObjectId);

  15: }

*AuditObjectModificationSetsObjectName – Now I want to make sure that the object passed in has its type saved in the audit class’s ObjectName property.

   1: [TestMethod]

   2: public void AuditObjectModificationSetsObjectName()

   3: {

   4:     var sampleObject = new RouteConfigurator();

5:

   6:     Audit audit = null;

7:

   8:     AuditInterceptor.UserAuth.Expect(a => a.CurrentUserName).Return("currentUser");

9:

  10:     AuditRepository

  11:         .Expect(a => a.EnsurePersistent(Arg<Audit>.Is.Anything))

  12:         .WhenCalled(a => audit = (Audit)a.Arguments.First());

13:

  14:     AuditInterceptor.AuditObjectModification(sampleObject, null, AuditActionType.Update);

15:

  16:     Assert.AreEqual("RouteConfigurator", audit.ObjectName);

  17: }

*AuditObjectModificationCallsEnsurePersistant – The last test will just make sure that when everything goes ok, a new audit instance will be saved.

   1: [TestMethod]

   2: public void AuditObjectModificationCallsEnsurePersistant()

   3: {

   4:     AuditInterceptor.UserAuth.Expect(a => a.CurrentUserName).Return("currentUser");

5:

   6:     AuditRepository.Expect(a => a.EnsurePersistent(Arg<Audit>.Is.Anything));

7:

   8:     AuditInterceptor.AuditObjectModification(new object(), null, AuditActionType.Update);

9:

  10:     AuditRepository.AssertWasCalled(a=>a.EnsurePersistent(Arg<Audit>.Is.Anything));

  11: }

Results

Of course since the AuditObjectModification method just throws a NotImplementedException(), all of these tests are going to currently fail.

So the next step is to implement AuditObjectModification() and get all of the tests to turn green. We’ll work on that next time!