Scott's Blog : ASP.NET

Authorizing Access via Attributes in ASP.NET MVC Without Magic Strings

srkirkland — Mon, 04 Jan 2010 19:08:42 GMT

Recently I developed a strategy which I think works well for authorizing access to user groups (Roles) without using the string names of those groups.

The problem I am trying to avoid is doing something like [Authorize(Roles=”AdminRole”)] on a controller or action since I know the role names can change & one typo can mess everything up.

Role Names

So first of all I usually have a static class which has the names & aliases for all roles in case they change:

public static class RoleNames

    public static readonly string Supervisor = "Supervisor";

    public static readonly string Admin = "StateOffice";

    public static readonly string ProjectAdmin = "ProjectAdmin";

    public static readonly string DelegateSupervisor = "Delegate";

This is pretty standard for me, but unfortunately I can’t just do [Authorize(Roles=RolesNames.Admin)] because attributes requires constant expressions. So as a solution I came up with the idea of creating a custom attribute which will tightly control access based on specific role criteria.

Creating a Custom Authorize Attribute

When creating the custom authorize attribute I inherit from AuthorizeAttribute since it already contains most of the logic I need. All I need to do is set the Roles property in the constructor to a comma delimited list of the authorized roles, and the authorize attribute base class will take care of the rest.

For example – to restrict access to just the admin role:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]

public class AdminOnlyAttribute : AuthorizeAttribute

    public AdminOnlyAttribute()

        Roles = RoleNames.Admin;

Or if you want to include the project admins as well:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]

public class AdminOnlyAttribute : AuthorizeAttribute

    public AdminOnlyAttribute()

        var authorizedRoles = new[] {RoleNames.Admin, RoleNames.ProjectAdmin};

        Roles = string.Join(",", authorizedRoles);

Usage

Then on your controller you restrict access like this

[AdminOnly]

public class AdminController : Controller{}

And it also works on an action

public class AdminController : Controller

    [AdminOnly]

    public ActionResult AdminOnlyAction()

        return View();

Enjoy!

Making ASP.NET MVC Actions be Transactional By Default

srkirkland — Mon, 16 Nov 2009 18:01:19 GMT

In an earlier post I talked about writing a Transaction attribute for MVC using NHibernate (though it isn’t really NHibernate specific). The basic idea is that when an action marked with [Transaction] is executing (OnActionExecuting) you begin a transaction, and some time later (I use OnActionExecuted, but Kazi Manzur Rashid makes a good argument for OnResultExecuted) you commit that transaction if there was no error, or rollback if there was an error.

With that in mind, the implementation details aren’t really important because my motivation in this post is to make every action transactional by default. Most of the actions on any real site will require retrieving, updating, saving or removing data so as a best practice I would like the user to have to specify if they choose not to use a transaction (maybe for a static about page).

What I’d Like to Accomplish

Given any action method (we’ll use Index), if there is no attribute it should execute in a Transaction:

public ActionResult Index()

    var data = //get data

    return View(data);

Now if we explicitly use a [Transaction] attribute it should still execute in a Transaction:

[Transaction]

public ActionResult Index()

    var data = //get data

    return View(data);

However, we can choose to use a self-defined [HandleTransactionManually] attribute which will Not Use a Transaction:

[HandleTransactionManually]

public ActionResult Index()

    var data = //get data

    return View(data);

The UseTransactionByDefaultAttribute and the SuperController

To enforce “global” rules like this it is necessary for all controllers to inherit from a custom controller I call the “SuperController”. This is a class I was using anyway for helper/common methods and I assume a lot of other people don’t inherit directly from the Controller class as well. The SuperController just inherits from System.Web.Mvc.Controller for the purposes of this post.

Now I am going to start by making a class attribute for the SuperController (or any controller really) which will cause us to use transactions by default. First I’ll show the implementation and then explain it:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]

public class UseTransactionsByDefaultAttribute : ActionFilterAttribute

    private IDbContext _dbContext;

    private bool _delegateTransactionSupport;

    public IDbContext DbContext

get

            if (_dbContext == null) _dbContext = SmartServiceLocator<IDbContext>.GetService();

            return _dbContext;

    public override void OnActionExecuting(ActionExecutingContext filterContext)

        _delegateTransactionSupport = ShouldDelegateTransactionSupport(filterContext);

        if (_delegateTransactionSupport) return;

        DbContext.BeginTransaction();

    public override void OnActionExecuted(ActionExecutedContext filterContext)

        if (_delegateTransactionSupport) return;

        if (DbContext.IsActive)

            if (filterContext.Exception == null)

                DbContext.CommitTransaction();

            else

                DbContext.RollbackTransaction();

    private static bool ShouldDelegateTransactionSupport(ActionExecutingContext context)

        var attrs = context.ActionDescriptor.GetCustomAttributes(typeof (TransactionalActionBaseAttribute), false);

        return attrs.Length > 0;

Explanation – So this is an action filter attribute of course, and it works only on classes. When the action executes (OnActionExecuting) I check to see if I should “delegate” the transaction support, and if so I’ll return and do nothing else. If I am not delegating transaction support, I’ll begin the transaction. The OnActionExecuted method does something similar and if we are not delegating it takes care of committing or doing the rollback depending on need.

The ShouldDelegateTransactionSupport is pretty interesting in that it check the custom attributes on the current action (using ActionDescriptor.GetCustomAttributes()) and if it sees any attributes that inherit from my custom TransactionalActionBaseAttribute class then it return true, meaning that we should delegate transaction support to the attributes.

This base class is pretty simple:

public class TransactionalActionBaseAttribute : ActionFilterAttribute

Handling Transactions Manually if Needed

If you want to override the default transaction then we need another attribute which will provide this support for us. Since we have seen that inheriting from TransactionalActionBaseAttribute means we are delegated responsibility for the transaction, we can just ask for responsibility and then do nothing with it, as below

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]

public class HandleTransactionManuallyAttribute : TransactionalActionBaseAttribute

Results – Show and Tell

Let’s see how this works for us.

Situation One – We don’t specify any transaction attribute and we get a transaction

public ActionResult Index()

    var data = //get data

    return View(data);

Situation Two – We specify a transaction attribute and we get the exact same result

[Transaction]

public ActionResult Index()

    var data = //get data

    return View(data);

Situation Three – We specify HandleTransactionManually and we get no transaction

[HandleTransactionManually]

public ActionResult Index()

    var data = //get data

    return View(data);

I’m a big fan of setting best practice defaults and default transactions are a good way to help get devs to use transactions as much as possible (which for many reasons is a good thing).

Enjoy!

Inserting Transactions into Telerik’s ASP.NET MVC Grid

srkirkland — Tue, 10 Nov 2009 17:55:54 GMT

Telerik recently released their Extensions for ASP.NET MVC which include several great controls, the most immediately useful of which is their Grid control. In the simple (and probably most common) cases the grid works by passing taking an enumerable list of objects (let’s say Northwind Orders for this example) and rendering this out as a table based on a fluent configuration. The benefit of passing in an enumerable list is that Telerik’s Grid will use its data engine and dynamically page, sort and filter your data on the server (aka: at the database), which is a huge win. However, by allowing the Grid to handle your actual database call you lose control of transactional support and you start using what Oren Eini refers to as “implicit transactions”. For more information on implicit transactions and why you shouldn’t use them see http://nhprof.com/Learn/Alert?name=DoNotUseImplicitTransactions.

Default Grid Behavior Implementation

Following the default example on Telerik’s site, we get a configuration similar to this:

[The Order Controller’s List() Method]

public ActionResult List()

    var orders = _orderRepository.Queryable; //Return IQueryable<Order>

    return View(orders);

[The List View]

<%= Html.Grid(Model)

    .Name("Orders")

    .Columns(col =>

            col.Add(order => order.OrderedBy.CompanyName);

            col.Add(order => order.ShipAddress);

            col.Add(order => order.OrderDate).Format("{0:d}");

})

    .Pageable(x=>x.PageSize(20))

    .Sortable()

%>

Default Grid Behavior Results

When you run this example, you get two nice queries – one which does a count of all orders for paging purposes and one which selects the correct 20 orders from the database (sorted correctly). You can see this in NHProf below:

This all looks pretty nice, but of course those alerts are because of implicit transactions. Let’s try adding a transaction attribute to our wrap our action in a transaction:

[Transaction]

public ActionResult List()

    var orders = _orderRepository.Queryable; //Return IQueryable<Order>

    return View(orders);

Running this again, we get the following:

Now we are getting a transaction but since we aren’t querying for the data until the action has returned the queries still take place outside of the transaction. Let’s try to fix that.

Transactional Options for the Grid

The general idea for wrapping the grid’s query in a transaction is that you have to open the transaction before the grid executes its render and close the transaction after it is done. Extension methods could be a candidate here, but Render() returns void so you can’t do a commit, and regardless, for the basic grid example you don’t call render directly anyway. Another option would be to wrap the grid in a using(transactionScope){…} method similar to using(Html.BeginForm()){…} but this seems excessive. Or you could simply make html helpers which would begin/end transactions, but I would hate to have that in my view (I don’t think that’s the view’s responsibility).

So, with that in mind, I set off to see if I could hook into the render method and wrap it in a transaction manually. After pouring through the Telerik source code (the extensions are on Codeplex here) I learned a few things. First, calling Html.Telerik() causes some fairly intense control initialization code which I wouldn’t want to rewrite. Second, calling Html.Telerik().Grid() returns an instance of GridBuilder<T>. Finally, GridBuilder<T> has virtual methods which allow overriding and give me the hook I need to add in transactional support.

Creating the CustomGridBuilder<T> class

To create my custom grid builder I’ll just subclass GridBuilder<T> and add a single method – Transactional(). In the interest of space Transactional() will return a GridBuilder<T> instance so it must be called as the first method after Grid(). The full implementation is below:

public class CustomGridBuilder<T> : GridBuilder<T> where T : class

    protected bool UseTransaction { get; set; }

    public CustomGridBuilder(Grid<T> component) : base(component)

        UseTransaction = false;

    public GridBuilder<T> Transactional()

        UseTransaction = true;

        return this;

    public override void Render()

        if (UseTransaction)

            using (var ts = new TransactionScope())

                base.Render();

                ts.CommitTransaction();

        else

            base.Render();

The big points here are that transactions are optional by default (in case you want to use custom binding, json, anonymous types, etc), and calling Transactional() sets the UseTransaction bool to true. This causes the render method to be wrapped in a transaction scope if necessary.

Now we need a way to return our CustomGridBuilder<T> instead of GridBuilder<T>, so we’ll create some HtmlHelperExtensions. You can create one for each overload of Html.Telerik().Grid() if you want, but for this example I’m only going to override the IEnumerable<T> option.

public static class HtmlHelperExtensions

    public static CustomGridBuilder<T> Grid<T>(this HtmlHelper htmlHelper, IEnumerable<T> dataModel) where T : class

        var builder = htmlHelper.Telerik().Grid(dataModel);

        return new CustomGridBuilder<T>(builder);

Notice here we initialize the Grid by calling the Telerik() initialization method. This way if Telerik updates the initialization logic in future releases or even the GridBuilder logic we shouldn’t have to make any code changes at all.

We are almost done – let’s take a look at what those two classes have bought us.

Results!

Since we have an HtmlHelper called Grid<T> which takes an IEnumerable<T>, let’s use it to create the grid. This code is very similar to the code we started with, adding one significant difference.

<%= Html.Grid(Model)

    .Transactional() //New method adding transactional support

    .Name("Orders")

    .Columns(col =>

            col.Add(order => order.OrderedBy.CompanyName);

            col.Add(order => order.ShipAddress);

            col.Add(order => order.OrderDate).Format("{0:d}");

})

    .Pageable()

    .Sortable()

%>

Of course here you can see the first method is Transactional(), and that returns a GridBuilder<T> so we can chain on any of Telerik’s methods without affecting functionality (and staying safe from future API changes).

Let’s run this example one more time (without changing) the controller at all.

Now that is some nice transactional SQL :)

Enjoy!

An xVal Provider For NHibernate Validator

srkirkland — Mon, 02 Nov 2009 18:13:32 GMT

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

srkirkland — Tue, 20 Oct 2009 14:50:00 GMT

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

srkirkland — Thu, 15 Oct 2009 17:46:51 GMT

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

srkirkland — Tue, 13 Oct 2009 16:23:00 GMT

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

srkirkland — Thu, 08 Oct 2009 13:59:42 GMT

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

srkirkland — Tue, 29 Sep 2009 17:45:00 GMT

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!

Visual Studio 2008 with TFS Explorer broken with SP1

srkirkland — Tue, 22 Sep 2009 14:47:00 GMT

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

srkirkland — Mon, 21 Sep 2009 20:49:00 GMT

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

srkirkland — Thu, 17 Sep 2009 17:41:00 GMT

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)

srkirkland — Tue, 15 Sep 2009 16:58:00 GMT

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)

srkirkland — Thu, 10 Sep 2009 20:39:00 GMT

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()

srkirkland — Tue, 08 Sep 2009 18:49:57 GMT

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.