Hey NHibernate, Don’t Mess With My Enums!

So I’ve been using Fluent NHibernate for a short while now. Initially I had to overcome some minor challenges, but since I got those out of the way it’s been pretty smooth sailing. One thing that stands out, which required more tinkering and timeshare than I would’ve liked is the way NHibernate handles the .NET enum type. Natively NHibernate allows you to save your enum’s value as a string or number property/column in the referencing object’s table. In other words, by default it doesn’t allow you to map your enum to its own separate table, and then let your objects refer to it through an association/foreign key. For NHibernate enums are primitive values, and not “entity objects” (logically speaking – ignoring the technical internal mechanics of .NET’s enum). I would argue that enums can be both a primitive string or number, or a more complex entity. Under certain circumstances an enum can be viewed as a simple “object” that consists of two properties:

  • An Id, represented by the enum member’s number value
  • And a name, represented by the enum member’s string name.

I’ve found that it’s very convenient to use the “entity object” version of enums for very simple, slow changing look-up data with a fair amount of business logic attached to it. For instance in a credit application app, you might only support 3 or 4 types of loans, but you know that over time app’s life, the company won’t add more than 2 or 3 new types of loans. Adding a loan type requires some additional work, and isn’t merely a matter of just inserting a new loan type into a look-up table. The reason is that a fair amount of the app’s business logic, mainly in the form of conditional logic statements, must also be adapted to accommodate the new loan type. From a coding perspective it’s very convenient to use enum types in these cases, because you can refer to the various options through DRY strong typed members, with a simultaneous string and number representation. So instead of

var loan = loanRepository.FindById(234);
var loanType = loanTypeRepository.FindById(123);

// ...

if (loan.Type == "PersonalLoan")
{
    // ...
}

rather do

var loan = loanRepository.FindById(234);

if (loan.Type == LoanType.Personal)
{
    //...
}

Okay, schweet, you get the point. Next logical question: How do you get NHibernate to treat your enums as objects with their own table, and not primitive values? To do this you have to create a generic class that can wrap your enum types, and then create a mapping for this enum  wrapper class. I call this class Reference:

public class Reference<TEnum>
{
    private TEnum enm;

    public Reference(TEnum enm)
    {
        this.enm = enm;
    }

    public Reference() {}

    public virtual int Id
    {
        get { return Convert.ToInt32(enm); }
        set { enm = (TEnum)Enum.Parse(typeof(TEnum), value.ToString(), true); }
    }

    public virtual string Name
    {
        get { return enm.ToString(); }
        set { enm = (TEnum)Enum.Parse(typeof(TEnum), value, true); }
    }

    public virtual TEnum Value
    {
        get { return enm; }
        set { enm = value; }
    }
}

The Reference class is pretty straight forward. All it does is translate the contained enum into an object with three properties:

  • Id – the integer value of the enum member.
  • Name – the string name of the enum member.
  • Value – the contained enum member.

You might wonder why I didn’t bother to restrict the allowed generic Types to enums. Well, it so happens that .NET generics doesn’t allow you to restrict generic type declarations to enums. It allows you to restrict generic types to structs, and all sort of other things, but not to enums. So you will never be able to get an exact generic restriction for the Reference class. So I thought, aag what the hell, if I can’t get an exact restriction, then what’s the point anyways? I’ll have to trust that whoever is using the code, knows what he’s doing.

Now, for example, instead of directly using the LoanTypes enum, the Loan class’s Type property will be a Reference object, with its generic type set to the LoanTypes enum:

public class Loan
{
    // ...
    public Reference<LoanType> Type { get; set; }
    // ...
}

This is not completely tidy, because to a degree the limitations of the data access infrastructure, i.e. NHibernate, force us to adopt a compromise solution that’s not necessary if we changed to something else. In other words things from the data infrastructure layers spills into the domain.

What’s left to do is (1) create a mapping for Reference<LoanType>, and (2) get NHibernate to use the right table name, i.e. LoanType, instead of Reference[LoanType]. Here the Fluent NHibernate mapping for Reference<LoanType>:

public class LoanTypeMap: ClassMap<Reference<LoanType>>
{
    public LoanTypeMap()
    {
        Table(typeof(LoanType).Name);
        Id(loanType => loanType.Id).GeneratedBy.Assigned();
        Map(loanType => loanType.Name);
    }
}

The above Fluent NHibernate mapping tells NHibernate to use whatever value property Id has for the primary key, and not generate one for it. You also have to explicitly specify the table’s name you’d like NHibernate to use, because you want to ignore “Reference” as part of the table name, and only use the enum type name.

And that’s it. You will now have a separate table called LoanType, with the foreign keys of other classes’ tables referencing the LoanType enum’s table. Just keep in mind that this solution might not always be feasible. For example it might not work too well when you write a multilingual application. Also should you want to get a pretty description for each enum’s member, for example “Personal Loan”, instead of “PersonalLoan” you’ll have to throw in some intelligent text parsing that split’s a text string before each uppercase character. Hopefully this post gave you another option to map your enum types with NHibernate.


REST Web Services with ServiceStack

Over the past month I ventured deep into the alternative side of the .NET web world. I took quite a few web frameworks for a test drive, including OpenRasta, Nancy, Kayak and ServiceStack. All of the aforementioned supports Mono, except OpenRasta, that has it on its road-map. While kicking the tires of each framework, some harder than others, I saw the extent of just how far .NET has grown beyond its Microsoft roots, and how spoiled .NET developers have become with a long list of viable alternative .NET solutions from the valley of open source.

ServiceStack really impressed me, with its solid mix of components that speak to the heart of any modern C# web application. From Redis NOSQL and lightweight relational database libraries, right through to an extremely simple REST and SOAP web service framework. As the name suggests, it is indeed a complete stack.

Anyways, enough with the marketing fluff, let’s pop the bonnet and get our hands dirty. What I’m going to show you isn’t anything advanced. Just a few basic steps to help you to get to like the ServiceStack web framework as much as I do. You can learn the same things I’ll be explaining here by investigating the very complete ServiceStack example applications, but I thought some extra tidbits I picked up working through some of them should make life even easier for you.

Some Background Info On REST

I’m going to show you how to build a REpresentation State Transfer (REST) web service with ServiceStack. RESTful web services declare resources that have a URI and can be accessed through HTTP methods, or verbs (GET, PUT, POST and DELETE), to our domain services and entities. This is different from SOAP web services that require you to expose methods RPC style, that are ignorant of the underlying HTTP methods and headers. To implement a REST resource and its HTTP-methods in ServiceStack requires the use of two classes, RestService and RestServiceAttribute.

Another feature of REST is that data resources are encoded in either XML or JSON. However, the latest trend is to encode objects in JSON for its brevity and smaller size, rather than its more clunky counterpart, XML. We will therefore follow suit and do the same. Okay, I think you’re ready now to write your first line of ServiceStack code.

Create a Web Service Host with AppHostBase

The first thing you have to do is specify how you’d like ServiceStack to run your web services. You can choose to either run your web services from Internet Information Services (IIS) or Apache, or from the embedded HTTP listener based web server. Both of these approaches require you to declare a class that inherits from AppHostBase:

public class AppHost: AppHostBase
{
    public AppHost()
        : base("Robots Web Service: It's alive!", typeof(RobotRestResource).Assembly) {}

    public override void Configure(Container container)
    {
        SetConfig(new EndpointHostConfig
        {
            GlobalResponseHeaders =
            {
                { "Access-Control-Allow-Origin", "*" },
                { "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
            },
        });
     }
 }

Class AppHost‘s default constructor makes a call to AppHostBase‘s constructor that takes 2 arguments. This first argument is the name of the web app, and the second argument tells ServiceStack to scan the Assembly where class RobotRestResource is defined, for REST web services and resources.

AppHostBase‘s Configure method must be overridden, even if it’s empty, otherwise you’ll get and exception. If you plan on making cross domain JavaScript calls from your web user interface (i.e. your web interface is written in JavaScript and hosted on a separate web site from your web services) to your REST resources, then adding the correct global response headers are very important. Together the two Access-Control-Allow headers tell browsers that do a pre-fetch OPTIONS request that their cross domain request will be allowed. I’m not going to explain the internals, but any Google search on this topic should yield sufficient info.

Now all that’s left to do is to initialize your custom web service host in Global.asax‘s Application_Start method:

public class Global : System.Web.HttpApplication
{
    protected void Application_Start(object sender, EventArgs e)
    {
        new AppHost().Init();
    }
}

The last thing you might be wondering about, before we move on, is the web.config of your ServiceStack web service. For reasons of brevity I’m not going to cover this, but please download ServiceStack’s examples and use one of their web.configs. The setup require to run ServiceStack from IIS is really minimal, and very easy to configure.

Define REST Resources with RestService

Now that we’ve created a host for our services, we’re ready to create some REST resources. In a very basic sense you could say a REST resource is like a Data Transfer Object (DTO) that provides a suitable external representation of your domain. Let’s create a resource that represents a robot:

using System.Collections.Generic;
using System.Runtime.Serialization;

[RestService("/robot", "GET,POST,PUT,OPTIONS")]
[DataContract]
public class RobotRestResource
{
[DataMember]
public string Name { get; set; }

[DataMember]
public double IntelligenceRating { get; set; }

[DataMember]
public bool IsATerminator { get; set; }

[DataMember]
public IList<string> Predecessors { get; set; }

public IList<Thought> Thoughts { get; set; }

}

The minimum requirement for a class to be recognized as a REST resource by ServiceStack, is that it must inherit from IRestResource, and have a RestServiceAttribute with a URL template, and that’s it. ServiceStack doesn’t force you to use the DataContractAttribute or DataMemberAttribute. The only reason I used it for the example is to demonstrate how to exclude a member from being serialized to JSON when it’s sent to the client. The Thoughts member will not be serialized and the web client will never know the value of this object. I had a situation where I wanted to have a member  on my resource for internal use in my application, but I didn’t want to send it to clients over the web service. In this situation you have to apply the DataContractAttribute to your resource’s class definition, and the DataMemberAttribute to each property you want to expose. And that’s it, nothing else is required to declare a REST resource ffor ServiceStack.

Provide a Service for Each Resource with RestServiceBase

Each resource you declare requires a corresponding service that implements the supported HTTP verb-methods:


public class RobotRestService: RestServiceBase<RobotRestResource>
{
    public override object OnPut(RobotRestResource robotRestResource)
    {
        // Do something here & return a
        // new RobotRestResource here,
        // or any other serializable
        // object, if you like.
    }

    public override object OnGet(RobotRestResource robotRestResource)
    {
        // Do some things here ...
        // Return the list of RobotRestResources
        // here, or any other serializable
        // object, if you like.

        return new []
        {
            new RobotRestResource(),
            new RobotRestResource()
        };
    }
}

In order for ServiceStack to assign a class as a service for a resource, you have to inherit from RestServiceBase,  specifying the resource class as the generic type. RestServiceBase provides virtual methods for each REST approved HTTP-verb: OnGet for GET, OnPut for PUT, OnPost for POST and OnDelete for DELETE. You can selectively override each one that your resource supports.

Each HTTP-verb method may return one of the following results:

  1. Your IRestResource DTO object. This will send the object to the client in the specified format JSON, or XML.
  2. ServiceStack.Common.Web.HtmlResult, when you want to render the page on the server and send that to the client.
  3. ServiceStack.Common.Web.HttpResult, when you want to send a HTTP status to the client, for instance to redirect the client:
    var httpResult = new HttpResult(new object(), null, HttpStatusCode.Redirect);
    httpResult.Headers[HttpHeaders.Location] = "http://openlandscape.wordpress.com";
    return httpResult;
    

And that’s it. Launch your web site, and call the OnGet methof at /robot?format=json, or if you prefer XML /robot?format=xml. To debug your RESTful service API I can highly recommend the Poster Firefox plug-in. Poster allows you to manually construct HTTP commands and send them to the server.

You might be wondering what the purpose is of RobotRestResource that gets passed to each HTTP-verb method. Well, that is basically an aggregation of the posted form parameters and URL query string parameters. In other words if the submitted form has a corresponding field name to one of RobotRestResource’s properties, ServiceStack will automatically assign the parameter’s value to the supplied RobotRestResource. The same applies for query strings, the query strings ?Name=”TheTerminator”&IsATerminator=true: robotRestResource’s Name will be assigned the value of “TheTerminator” and IsATerminator will be true.

Using ServiceStack’s Built-In Web Service as a Service Host

The above discussion assumed that you’ll be hosting your ServiceStack service in IIS or with mod_mono in Apache. However, ServiceStack has another pretty cool option available, self hosting. That’s right, services can be independently hosted on their own and embedded in your application. This might be useful in scenarios where you don’t want to be dependent on IIS. I imagine something like a Windows service, or similar, that also serves as small web server to expose a web service API to clients, without the need for lengthy and complicated IIS setup procedures.

var appHost = new AppHost();
appHost.Init();
appHost.Start("http://localhost:82/");

To start the self hosted ServiceStack you configure your host as usual, and then call Start(…), passing the URL (with free port) where the web server will be accessed.

Why Use ServiceStack

For me one of the big reasons for choosing ServiceStack is that it has a solid library to build web services running on Mono. However, after using if for a while I found its easy setup and simple conventions very refreshing from the often confusing and cumbersome configuration of Windows Communication Foundation (WCF) web services.ServiceStack also does a much better job of RESTful services, than WCF’s current implementation. I know future versions of WCF will enable a more mature RESTful architecture, but for now it’s pretty much RPC hacked into REST. Another bonus was the complete set of example apps that were a great help to quickly get things working. So if you’re tired of WCF’s heavy configuration and you’re looking for something to quickly implement mature RESTful web services, then definitely give ServiceStack a try.


Fluent NHibernate on PostgreSQL

When you write your first Fluent NHibernate application with Mono/.NET based on the Getting started tutorial, you eventually discover that you require a few extra assembly-dll references not mentioned. For my Postgres (PostgreSQL) project my references are:

Fluent NHibernate References

I won’t go into the detail of the matter, other than to say that many of these don’t give you a very clear indication as to what exactly is missing.

To configure Fluent NHibernate to work with Postgres you will need the following:

var connectionStr = "Server=127.0.0.1;Port=5432;Database=the_db;User Id=user_name;Password=password;"
ISessionFactory sessionFactory = Fluently
 .Configure()
 .Database(PostgreSQLConfiguration.Standard.ConnectionString(connectionStr))
 .Mappings(m => m.FluentMappings.AddFromAssemblyOf<TypeOfFluentNHibernateMapping>())
 .ExposeConfiguration(BuildSchema)
 .BuildSessionFactory();

private static void BuildSchema(Configuration config)
 {
// This NHibernate tool takes a configuration (with mapping info in)
// and exports a database schema from it.
var dbSchemaExport = new SchemaExport(config);
//dbSchemaExport.Drop(false, true);
dbSchemaExport.Create(false, true);
 }

TypeOfFluentNHibernateMapping is a class that inherits from FluentNHibernate.Mapping.ClassMap<T>. This tells Fluent to load all ClassMappings from the assembly where this type is defined.

BuildSchema(…) creates the database’s schema based on the specified mapping configuration and recreates the tables and the rest of it in the database specified by the connection string. I included the call to the schema export’s drop method, because the code originates from my unit tests, where I drop & recreate the database on each test run.

So far I like Fluent NHibernate, and the only complaint I have so far is the way NHibernate (not Fluent) handles enums. It assumes you want to use the enum member’s string name. The way I like to store my enums, are to have a separate table for them.


Sexy Transactions In Spring.NET

Spring.NET really has tons of handy features you can put to work in your application. One of them is its transaction management, that provides an implementation agnostic abstraction for your application. The first question you’re probably asking yourself is, why do you need to abstract away your transaction technology? The short answer is there are various ways of using transactions and different transaction technologies: ADO.NET, Enterprise Services, System.Transactions, and the different transaction implementations for other database technologies like ORMs (NHibernate). I won’t go into the detail of these, suffice to say that choosing, using and changing a transaction technology can become a complicated affair, and that Spring.NET protects your application from these ugly details. I encourage you to take a deep dive into the official Spring.NET documentation, should you want to know more about the details behind this.

What I did was, write a helper class that makes it a little easier and cleaner to use Spring.NET’s transaction management:


/// <summary>
 /// Manages database transactions by wrapping executed
 /// methods in a transaction.
 /// </summary>
 public static class Transaction
 {
 /// <summary>
 /// Executes the specified method in a transaction.
 /// </summary>
 public static void Execute(Action method, bool commitChanges = true)
 {
 // Create a new transaction
 Instantiate.New<ITransactionOperations>().Execute(delegate(ITransactionStatus transaction)
 {
 // If changes should not be committed, make
 // sure we roll back once done
 if (!commitChanges) transaction.SetRollbackOnly();
 method();
 return null;
 });
 }
 }

/// <summary>
 /// Instantiates objects based on their name.
 /// </summary>
 public static class Instantiate
 {
 #region Fields

 private static IApplicationContext context;

 #endregion

 #region Get objects from ApplicationContext

 /// <summary>
 /// Retrieves the object with the specified name.
 /// </summary>
 /// <typeparam name="T">The type of object to return.
 /// <param name="name">The name of the object.</param>
 /// <returns>A newly created object with the type specified by the name, or a singleton object if so configured.</returns>
 public static T New<T>(string name)
 {
 return (T)Context.GetObject(name);
 }

 /// <summary>
 /// Retrieves the object of the specified type.
 /// </summary>
 public static T New<T>()
 {
 return (from obj in Context.GetObjectsOfType(typeof(T)).Values.Cast().ToList()
 select obj).FirstOrDefault();
 }

 /// <summary>
 /// Retrieves the object with the specified name, and constructor arguments.
 /// </summary>
 public static T New<T>(string name, object[] arguments)
 {
 return (T)Context.GetObject(name, arguments);
 }

 #endregion

 #region Private methods

 /// <summary>
 /// Gets the context.
 /// </summary>
 /// <value>The context.</value>
 private static IApplicationContext Context
 {
 get
 {
 if (context == null)
 {
 context = ContextRegistry.GetContext();
 }

 return context;
 }
 }

 #endregion
 }

Class Instantiate

The Instantiate class is a wrapper for Spring.NET’s IApplicationContext, with a few helper methods. It provides three overloads of the method New<T>, that instantiates new objects from the ApplicationContext configuration. The most important method is New<T> without any arguments. This method simply grabs the first instance of the requested Type it finds in the ApplicationContext. The other two variations allow you to instantiate a new object with a specific id.

With the help of the Instantiate class the Transaction class will obtain the specified transaction management from Spring’s ApplicationContext.

Class Transaction

This is where all the action really happens as far as database transactions go. The Transaction class has a single Execute method, that transparently wraps any block of code in a transaction. There are a small number of things you have to do to use Spring’s transaction management:

1. First get an instance of your chosen transaction implementation.

2. Call Execute with a delegate with an ITransactionStatus argument.

3. When you’re done, you have to return something, even if it’s null.

My goal is to remove the above 3 requirements, so I can just pass a block of code through to get it wrapped in a transaction. This is exactly what Execute achieves:


Transaction.Execute(() =>
 {
 // Get a FileTypeRepository
 var fileTypeRepository = Instantiate.New();

 // Add an object
fileTypeRepository.Add(fileType);

 // Save the changes to the database
 fileTypeRepository.SaveChanges();

});

Spring.NET provides 4 transaction implementations:

  • Spring.Data.Core.AdoPlatformTransactionManager - local ADO.NET based transactions
  • Spring.Data.Core.ServiceDomainPlatformTransactionManager - distributed transaction manager from Enterprise Services
  • Spring.Data.Core.TxScopeTransactionManager - local/distributed transaction manager from System.Transactions.
  • Spring.Data.NHibernate.HibernateTransactionManager - local transaction manager for use with NHibernate or mixed ADO.NET/NHibernate data access operations.

To configure your transaction manager for the ApplicationContext you need:


<objects xmlns="http://www.springframework.net">
 <object id="transactionManager"
 type="Spring.Data.Core.TxScopeTransactionManager, Spring.Data" />
 <object id="transactionTemplate"
 type="Spring.Transaction.Support.TransactionTemplate, Spring.Data"
 autowire="constructor" />
</objects>

Spring.NET’ provides a TransactionTemplate that handles all the necessary transaction logic and resources like commits, rollbacks, and errors. It frees you from getting involved with low level transaction management details, and provides all transaction management out of the box. If you desire you can directly access a transaction manager, through an IPlatformTransactionManager interface, to manage the details of your transaction process.

TransactionTemplate implements the ITransactionOperations interface. It has a constructor that requires a IPlatformTransactionManager instance. All transaction managers implement the IPlatformTransactionManager interface. This means TransactionTemplate contains the specified transaction manager. The required transaction manager is provided to the TransactionTemplate through autowiring of the constructor’s parameters. The autowiring searches through the objects and returns the first configured object that implements the IPlatformTransactionManager interface, which is transactionManager in  our case.

Object transactionManager is an instance of TxScopeTransactionManager, that is in turn based on System.Transactions.

Transaction.Execute has a second optional parameter, commitChanges. The commitChanges argument defaults to true, so the transaction manager will always attempt to commit changes. I use it when I test my application, and I want all test data to be rolled back.

Based on the fact that it commitChanges is an optional parameter, you’ve probably figured out by now that I recompiled Spring.NET to run on .NET 4.

The example IFileTypeRepository is actually based on Entity Framework 4 with Plain Old CLR/C# Objects (POCO). Just in case you were wondering if Spring.NET’s transaction management works with Entity Framework.


An Impersonation Aspect With Spring.NET AOP

One of the most useful features of Spring.NET is its Aspect Oriented Programming (AOP). Object Orientation (OO) decomposes an application into a hierarchy of entities linked through references. AOP on the other hand, decomposes an application into ‘service layers’ (referred to as aspects or cross cutting concerns in AOP lingo). This allows us to transfer infrastructure code out of our core business logic and entities. AOP has some really confusing jargon, like advice, weaving, crosscutting concern, joinpoint, pointcut, etc. To get a grip of these basic building blocks of AOP I refer you to Spring’s excellent documentation that will get you started in no time.

This post is for those of you that covered the basic concepts and terms of AOP, and Spring.NET AOP in particular, but are still struggling a bit to put it all together. I’ll give an overview of how all the different parts of AOP come together, and then follow it up with a working example.

Transparently Wrapping Infrastructure Around Objects

Even after going over the fundamentals of AOP can one still be confused. So let’s start of with two very simplified diagrams that contrast OO against AOP. These diagrams are not ment to be technically accurate, just demonstrate the very high level concept of AOP.

Figure 1

The frist diagram of figure 1 shows how all of OO’s operating logic is contained within an object’s methods. In OO the object (or class) is the main construct that distills data (properties) and tasks (methods) into a type of entity. Each class has several methods, and in turn each method consists of business and infrastructure logic. Before we move on, I’d just like to mention that it’s not a case of AOP vs OO, and which one is the better than the other. AOP complements OO, and improves the quality and adaptability of OO.

OO works wonderfully when we only consider data, methods, and statements directly related to the bigger concept they collectively represent. But when we take things like logging, caching, security, and transactions into concideration we get this uneasy feeling that we are adding code that do not have any direct relation to the logical entity. Traditionally we would combine this infrastructure code with our business logic. This results in dirty business logic code, that becomes more complex, confusing, and less maintainable as we increase its coupling with infrastructure code. Not only this, but let’s say you quickly wanted to cache the results of several methods, without modifying each object’s method? You would have to go and manually duplicate the same code in each method were you want to perform the caching. That’s a lot of hard coding labor, and even harder maintenance should you want to change the way you do things.

Along comes AOP that allow you to move the infrastructure code out of our object’s methods into aspects that has specific roles with tasks. So you’ll have an aspect that provides security around methods, and another logging method execution. Our object’s business logic does not have to know anything about the infrastructure code in which it’s embedded. The infrastructure code is dynamically injected before or after a method executes. That is what the second diagram of figure 2 demonstrates: We have our object, and dynamically we specify when, and how infrastructure aspects intercept incoming and outgoing method calls. The result is that we are left with pure business logic code in the object’s methods, which are themselves transparently wrapped in the necessary infrastructure code.

Interfaces And Proxies

Spring.NET’s AOP framework uses proxies and interfaces to transparently wrap objects in aspects. An AOP proxy is an object that intercepts calls to, and results from, our actual business entity objects. The proxy has the exact same public members as our business entity object. When we request an object that we want to wrap in aspects, we actually request its proxy. In our configuration we will tell the proxy which object provides the actual implementation:


<objects xmlns="http://www.springframework.net">

    <object id="crmService" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
<property name="proxyInterfaces" value="Shinobido.GhostBlade.Customers.ICRMService" />
<property name="target">

<object type="Shinobido.GhostBlade.Customers.CRMService, Shinobido.GhostBlade">
<property name="Url" value="http://localhost:2491/CRMService.asmx" />
<property name="UseDefaultCredentials" value="true" />

</object>
         </property>
<property name="interceptorNames">
	<list>
                 <value>impersonationAspect</value>

</list>
        </property>

</object>

     <!-- Interception AOP Begin -->

<object id="impersonationAspect" type="Spring.Aop.Support.DefaultPointcutAdvisor, Spring.Aop">
<property name="Pointcut">

<object id="regexPointcut" type="Spring.Aop.Support.SdkRegularExpressionMethodPointcut, Spring.Aop">
<property name="patterns">
	<list>

<value>.*</value>

</list>
                  </property>
               </object>
       </property>
<property name="Advice" ref="impersonationAdvice" />

</object>

     <object id="impersonationAdvice" type="Shinobido.GhostBlade.Security.ImpersonationAdvice, Shinobido.GhostBlade" />

     <object id="Shinobido.GhostBlade.Security.IIdentityProvider"
                    type="Shinobido.GhostBlade.Security.HttpContextIdentityProvider, Shinobido.GhostBlade" />

</objects>

public interface ICRMService
{
    CustomerInformation GetCustomerById( int id ) ;
}

public class CRMService: System.Web.Services.Protocols.SoapHttpClientProtocol, ICRMService
{
    public CustomerInformation GetCustomerById( int id )
    {
            object[] results = this.Invoke( "GetCustomerById", new object[] { id } );
            return ( CustomerInformation )results[0];
    }
}

Figure 2

From the above example we can infer a number of things:

  1. ProxyFactoryObject is going to intercept calls to our target object, CRMService. In Spring.NET there are several proxying strategies to choose from like inheritance or composition (interface) based, autoproxies, and so forth. Here we’re using a GUID-based composition ProxyFactoryObject. When you instantiate this proxy through Spring.NET’s object factory, you’ll notice that the object’s type is actually a runtime generated object of a type like “CompositionAopProxy_4f054a8f2cd349479fe1673d4427aca3″ that implements ICRMService.
  2. ProxyInterfaces expose the members that will be visible to client code and intercepted by the proxy through interface ICRMService. In other words aspects will only be applied to members specified by this interface. Any members specified by this interface will automatically receive advice based on their pointcuts.
  3. Target specifies the business entity object that we’re going to wrap.
  4. InterceptorNames specify that the aspect impersonationAspect must be applied to method requests and outputs.
  5. impersonationAspect‘s Pointcut uses a regualr expression that selects all members of the given class to receive impersonationAdvice.

In point 1 I mentioned composition vs inheritance based AOP proxies. We are using a composition based proxy, because the proxy never inherits from our target object, CRMService. A composition based proxy has a private field called m_targetSourceWrapper of type Spring.Aop.Framework.StaticTargetSourceWrapper that stores the actual business entity class we’re redirecting to. An inheritance based proxy inherits from the target object.

Writing A Custom Impersonation MethodInterceptor

Spring.NET provides a number of out-of-the-box aspects for caching, logging, transactions, and exceptions. What we’re going to do is write custom ‘around advice’, called a MethodInterceptor. Remember, Advice are objects that perform the actual work. So logging advice will actually write to the log file. Pointcuts tell the proxy when to pass control to the specified advice. You get four types of advice:

  • Before a target method executes.
  • After a target method executes.
  • Before and after (around) a method executes.
  • When a target method throws an unhandled exception.

The AOP advice we’re going to write, will impersonate the current thread with a WindowsIdentity obtained from an identity provider. This is used when an application runs under a Windows service account, but selected methods need to be called with the current user’s identity, instead of the service account’s. The IIdentityProvider is dynamically injected, and retrieves the WindowsIdentity from the applicable context. For instance when you’re impersonating the current thread in a web application, you need to implement a HTTP IIdentityProvider, that gets the current user’s WindowsIdentity from the HttpContext.

In our specific scenario we are applying impersonationAdvice to all methods (.*) of the ICRMService, implemented by CRMService. In a nutshell, we are impersonating all our calls to CRMService.

Control is passed to an IMethodInterceptor before a target method is entered, and after it returns:

 public class ImpersonationAdvice : IMethodInterceptor
 {   
 #region IMethodInterceptor Members

 public object Invoke( IMethodInvocation invocation )
 {
     using ( IdentityImpersonator.Begin( ObjectManager.New<IIdentityProvider>().Provide() ) )
     {         
         return invocation.Proceed();
     }
 }

 #endregion
 }

ImpersonationAdvice implements IMethodInterceptor. You can almost say that Invoke will replace the target method it’s wrapping. To execute the actual target method, you need to call Proceed() on the supplied IMethodInvocation argument.

Here’s the code for our implementation of IIdentityProvider, IdentityImpersonator, and ObjectManager:

internal class HttpContextIdentityProvider : IIdentityProvider
{
    #region IIdentityProvider Members

    /// <summary>
    /// Provides the identity of the current user.
    /// </summary>
    /// <returns></returns>
    public WindowsIdentity Provide()
    {
        return (WindowsIdentity) HttpContext.Current.User.Identity;
     }

     #endregion
}

public sealed class IdentityImpersonator : IDisposable
{
    #region Globals

    private WindowsImpersonationContext ctx;
    private bool disposed;

    #endregion

    #region Construction       

    /// <summary>
    /// Initializes a new instance of the <see cref="IdentityImpersonator"/> class.
    /// </summary>
    private IdentityImpersonator()
    {
        // Static Construction in Begin().
    }

    #endregion

    #region Public Members

    /// <summary>
    /// Begins this instance.
    /// </summary>
    /// <returns></returns>
    public static IdentityImpersonator Begin(WindowsIdentity identity)
    {
        var impersonator = new IdentityImpersonator {ctx = identity.Impersonate()};
        return impersonator;
    }

    /// <summary>
    /// Undoes this instance.
    /// </summary>
    public void Undo()
    {
        if (ctx != null)
        {
            ctx.Undo();
        }
    }

    #endregion

    #region IDisposable Members

    /// <summary>
    /// Releases unmanaged and - optionally - managed resources
    /// </summary>
    public void Dispose()
    {
        if (!disposed)
        {
            Undo();
            GC.SuppressFinalize(this);
            disposed = true;
        }
    }

    #endregion
}

/// <summary>
/// Instantiates objects based on their name, and provides
/// a standard set of configured utility objects.
/// </summary>
public static class ObjectManager
{
    private static IApplicationContext context;

    /// <summary>
    /// Instantiates a default object with an id/name
    /// that is the same as the class's full name.
    /// </summary>
    public static T New<T>()
    {
        return New<T>(typeof(T).FullName);
    }

    /// <summary>
    /// Instantiates the object with the specified name.
    /// </summary>
    /// <typeparam name="T">The type of object to return.</typeparam>
    ///<param name="name">The name of the object.</param>
    /// <returns>A newly created object with the type specified by the name, or a singleton object if so configured.
    /// </returns>
    public static T New<T>(string name)
    {
        return (T)Context.GetObject(name);
    }

    /// <summary>
    /// Instantiates the object with the specified name, and constructor arguments.
    /// </summary>
    public static T New<T>(string name, object[] arguments)
    {
        return (T)Context.GetObject( name, arguments);
    }

    /// <summary>
    /// Gets the context.
    /// </summary>
    /// <value>The context.</value>
    internal static IApplicationContext Context
    {
        get
        {
            if (context == null)
            {
                lock ( ContextRegistry.SyncRoot )
                {
                    context = ContextRegistry.GetContext();
                }
             }

             return context;
         }
    }
}

ObjectManager serves as the object factory that wraps Spring.NET’s ApplicationContext with some additional functionality. Specifically in this scenario, ObjectManager instantiates our proxied objects.

The important tasks are performed by IdentityImpersonator. HttpContextIdentityProvider supplies IdentityImpersonator.Begin(…) with the current user’s WindowsIdentity from HttpContext.Current.User, which in turn calls WindowsIdentity.Impersonate(). To stop impersonating the current thread, you need to call WindowsIdentity.Undo(). The Dispose method stops the impersonation, so that you need to put code that you want to impersonate, in a using {…} clause. GC.SuppressFinalize(…) tells the garbage collector to ignore IdentityImpersonator‘s finalize method, since we already cleaned up the object when it was Disposed.

Usage and Conclusion

So, to impersonate a call to CRMService becomes a completely transparent process. You don’t need to duplicate IdentityImpersonator.Begin() every time you want to impersonate the current thread. The methods that need impersonation is dynamically selected from one place, impersonationAspect’s Pointcut, and the impersonation work is also performed from one place, in ImpersonationAdvice:

var crmService = ObjectManager.New<ICRMService>( "crmService" );
crmService.GetCustomerById( 1 );<

This should clearly demonstrate the power of AOP: Injecting all that functionality into GetCustomerById(…), without adding a single line of code to it, and we can change it all without making any code changes!


Integrating The Spring.NET Validation Framework And ASP .NET MVC

I recently completed a very successful project for a client using ASP .NET MVC, Spring.NET and jQuery. One of the technical requirements of the solution was that we wanted to have an advanced validation mechanism that would allow us to move all our validation rules out of theUI layer, and business logic, and into a dynamically configurable rule engine. Spring.NET’s validation framework is ideally suited for this challenging task.

Spring.NET’s validation framework is based on a hierarchy of validation groups, conditions, and actions. I refer those unfimiliiar with Spring.NET’s validation framework, to their well composed documentation.

What I’ll propose here is a way to integrate Spring.NET’s validation with ASP MVC, and some issues you might encounter alng the way.

Spring.NET Validation Is From Mars, and ASP MVC Is From Venus

Okay, so you’ve covered the validation framework’s documentation. You can create new validation rules, pass through an object (in the MVC space this would be the model), and get back a boolean result to tell you whether the object passed (true) or failed (false). As I’ve mentioned this process is made very clear in the help documentation of the validation framework, so I’m going to jump straight into the juicy complexities.

Spring.NET’s validation rules apply themselves directly to a POCO’s (Plain Old C# Object) schema. For instance, say I’ve got a class Customer that I pass through as the validationContext, and I wanted to validate his CellPhone ContactNumber (Customer.ContactNumbers.CellPhone), the validation rule might look something like this:

<v:regex when="ContactNumbers.CellPhone != null and ContactNumbers.CellPhone != ''"
test="ContactNumbers.CellPhone">

When we’re talking about MVC, our Customer will serve as the model sent to a ViewPage by a Controller action.

ASP’s Controller all have a ViewData.ModelState.AddModelError(…), that takes in a key, and an error message. To get MVC to highlight the input element, the key must match its name. To get MVC to automatically bind the HTML control to a model property, the name of the control in turn should be the same as the path to the Property that provides its value. For example, say I want ASP MVC to automatically display his CellPhone number, then I’d use “Customer.ContactNumbers.CellPhone” as the input control’s name. To flag this control as an error source, I’ll use a key with the exact same name.

<%= Html.TextBox( "Customer.ContactNumbers.HomeDialCode" )%>
-
<%= Html.TextBox( "Customer.ContactNumbers.HomePhone" )%>
<%= Html.ValidationMessage( "Customer.ContactNumbers.HomeDialCode" )%>
<%= Html.ValidationMessage( "Customer.ContactNumbers.HomePhone" )%>

The important point is that the naming convention of the ViewPage’s HTML controls, is based on the model’s schema or graph, and so are the validation rules. The trick is then to relate a Spring.NET validation error (and specifically the error message) to the current node in the schema to which it’s being applied.

Spring.NET’s message or ErrorMessageAction has the concept of “providers“. A provider is just a fancy name for an IDictionary<string,IList> of key-values, where the provider name serves as the key, and the list is a list of ErrorMessages. The idea is that each provider name relates to a Spring validation web server control, that will display it’s error. For ASP MVC we’d rather like to generate the correct ModelError key, so MVC can automatically take care of displaying the error message in its own way.

So at this point we have 3 tasks that we need to complete to successfully integrate ASP MVC and Spring.NET Validation:

1. Tell each Spring.NET validation rule where in the object graph it’s currently executing.
2. Generate the correct error key from the validation rule’s location or context.
3. Convert the validation error to a ModelError and add it to the Controller’s ModelState.

Validation Rules: “I Know What I’m Doing, But Not Where I’m Doing It!”

One of the problems of Spring.NET’s validation rules are that they do not know where in the schema they’re executing. Put a another way, they do not know the path that lead to the current rule being executed – henceforth being referred to as their context. Why is this important? It is important because, as explained previously, the MVC’s input field names and error keys are based on the full path of underlying model-object property.

The most straightforward way to provide this contextual information for a validation rule is to embed it directly inside its definition, probably using a custom IValidationAction:

<v:regex id="homeDialCodeValidator" when="HomeDialCode != null and HomeDialCode != ''" test="HomeDialCode">
<v:property name="Expression" value="[0-9]{3}"/>
  <v:action type="Shinobido.GhostBlade.Validation.ModelValidationAction, Shinobido.GhostBlade.Core">
    <v:property name="CurrentError">
      <object id="homeDialCodeError" type="Shinobido.GhostBlade.Validation.ModelError, Shinobido.GhostBlade">
<property name="Key" value="Customer.ContactNumbers.HomeDialCode" />
<property name="Message" value="3 numbers expected." />
      </object>
    </v:property>
  </v:action>
</v:regex>

The problem with the aforementioned approach is that it reduces the re-usability of validation rules. For instance, lets say we have the following classes:

public class ContactNumbers
{
    public string HomeDialCode { get; set; }
    public string HomePhone { get; set; }
}

public class Customer
{
    public string Name { get; set; }
    public ContactNumbers ContactNumbers { get; set; }
    public Spouse Spouse { get; set; }
    public NextOfKin NextOfKin { get; set; }
}

public class Spouse
{
    public ContactNumbers ContactNumbers { get; set; }
}

public class NextOfKin
{
    public ContactNumbers ContactNumbers { get; set; }
}

Ideally we want to create one contactNumbersValidator rule-group, that can be referenced from other validators, wherever ContactNumbers need to be validated:

<v:ref name="contactNumbersValidator" context="Spouse.ContactNumbers" />

The problem with specifying the context information or error key, in the rule, as that it only caters for a single context. For instance, in the above example we would like to validate ContactNumbers from three different contexts: Customer.ContactNumbers, Customer.Spouse.ContactNumbers, and Customer.NextOfKin.ContactNumbers. All three will use the same validation rule, but from different contexts or schema paths. If we specify a context of Customer.ContactNumbers.HomeDialCode, then we are unable to accommodate any other path, such as those for NextOfKin and Spouse.

What we can infer from this exercise is that we need to specify a rule’s context outside of the rule, in a parent group or rule. A validation rule itself cannot contain the context, because it does not know from where it’s referenced. So how do we set the rule’s current context, from its parent?

One of the ValidatorGroup‘s overloads for the Validate(…) method, has an input argument called contextParams of type IDictionary. The significance of this argument is that we can write and read values to it – programmatically and from the config file. This allows us to make variables available to validation groups, validators or actions.

So how do we set a variable from the rule configuration? For this we use the “#variableName” syntax of Spring.NET’s expression language. When Spring.NET encounters the following command “#SomeVariable=’SomeValue‘” a new entry is made in the contextParams dictionary with a key name of “SomeVariable” and value of “SomeValue”.

What we’re going to do is write a magic little custom class that allow us to navigate up and down the object graph, as validation rules are evaluated:

public class ObjectContext
{
    private IList<string> contextPath = new List<string>();
    private string finalContext;
    private readonly StringBuilder pathBuilder = new StringBuilder();

    public bool StepIn( params string[] path )
    {
        for ( var i = 0; path != null && i < path.Length; ++i )
        {
            contextPath.Add( path[i] );
        }
        return true;
     }

    public bool FinalStepIn( params string[] path )
    {
        for ( var i = 0; path != null && i < path.Length; ++i )
        {
            if ( i == path.Length - 1 )
            {
                finalContext = path[i];
            }
            else
            {
                contextPath.Add( path[i] );
            }
        }
        return true;
    }

    public bool StepOut( params string[] path )
    {
        // Reverse list so we can start deleting from index 0
        var reversedContextPath = contextPath.Reverse().ToList();
        for ( var i = 0; i < reversedContextPath.Count(); ++i )
        {
            // Just remove the same number of items in "path"
            // from "contextPath"
            reversedContextPath.RemoveRange( 0, path.Length );
        }

        // Revert back to original order and assign back to "contextPath"
        reversedContextPath.Reverse();
        contextPath = reversedContextPath;

        return true;
    }

    public string ContextPath
    {
        get
        {
            if ( pathBuilder.Length > 0 ) pathBuilder.Remove( 0, pathBuilder.Length );

            for ( var i = 0; i < contextPath.Count; ++i )
            {
                pathBuilder.Append( contextPath[i] );

                // If don't have a leaf node, and this is the last
                // intermediate/branch node, then do not add a "."
                if ( string.IsNullOrEmpty( finalContext ) &&
                     i == contextPath.Count - 1 )
                {
                    continue;
                }

                pathBuilder.Append( "." );
            }
            pathBuilder.Append( finalContext );
            return pathBuilder.ToString();
        }
     }
 }

Let’s first explain some of the logic behind ObjectContext. When it comes to object schemas or graphs we can distinguish between three types of contexts: the root context, several intermediate sub contexts, and a final leaf context (containing the “test” expression). The root context serves as the starting point for the evaluation path, and is similar to MVC’s concept of a binding prefix. Sub contexts refer to those that navigate from the root down to a final leaf context. A leaf context is a validation rule end-point, that does not have any children, and contains the actual “test” expression.

ObjectContext has three methods StepIn, FinalStepIn, and StepOut. StepIn allows us to step into a child context, like when we move from Customer into Spouse. FinalStepIn is used when we move from a parent context into a final leaf context, like we’d do if we moved from ContactNumbers to HomePhone. Lastly we have StepOut, that takes us from a child context back up to a parent one, such as when we move back from Spouse to Customer.

All we need to do now, is add a new instance of ObjectContext to contextParams and call the relevant methods as we move through the object graph’s nodes. I wrote a ValidatorGroup extension method to automatically add a new ObjectContext instance to contextParams:

public static class ValidatorGroupExtensions
{
    public static bool Validate( this ValidatorGroup validatorGroup, object validationContext, IValidationErrors errors, bool hasContext )
    {
        var contextParams = hasContext ? new Dictionary<string,object> { { "ObjectContext", new ObjectContext() } } : new Dictionary<string,object>();
        return validatorGroup.Validate( validationContext, contextParams, errors );
    }
}

At this point it should be clear how to add a new instance of ObjectContext to contextParams. What we haven’t discussed is how we’re going to retrieve our ObjectContext instance from contextParams, and invoke one of its methods in the validation configuration. The answer to this question lies in the fact that Spring.NET’s IExpression interface allows multiple independent commands to be executed in the same expression. What’s also important is that we realize that the validation configuration schema’s “when” and “test” attributes are actually IExpression properties. Therefore we can use any of the validation framework’s attributes/properties that is an IExpression to use variables from contextParams:

<v:group id="customerValidator" when="#ObjectContext.StepIn( 'Customer' )">

    <v:condition when="#ObjectContext.FinalStepIn( 'Name' )" test="Name != null and Name != ''" />

    <v:group when="( #ObjectContext.StepIn( 'Spouse', 'ContactNumbers' ); Employer != null )">
        <v:ref name="contactNumbersValidator" context="Spouse.ContactNumbers" />
    </v:group>

    <v:group when="( #ObjectContext.StepOut( 'Spouse', 'ContactNumbers' ); #ObjectContext.StepIn( 'ContactNumbers' ) )">
        <v:ref name="contactNumbersValidator" context="ContactNumbers" />
    </v:group>
</v:group>

<!-- contactNumbersValidator -->
<v:group id="contactNumbersValidator">

    <!-- CellPhone validator -->
    <v:regex when="( #ObjectContext.FinalStepIn( 'CellPhone' ); CellPhone != null and CellPhone != '' )" test="CellPhone">
        <v:property name="Expression" value="[0-9]{10}"/>
        <v:action type="Shinobido.GhostBlade.ErrorMessageContextAction, Shinobido.GhostBlade">
            <v:property name="Message" value="Unexpected format for cellphone number." />
        </v:action>
    </v:regex>

</v:group>

The first “when” validation statement on the group element tells Spring.NET to fetch the value of the DictionaryEntry with key “ObjectContext”. To execute multiple commands in a single IExpression we place the entire expression in brackets, and separate the each sub-expression with a semi-colon. When multiple statements are specified like this, Spring.NET always returns the last statement’s value. This is why our navigation methods all return true: So that the groups are executed by default, relieving us from the burden to add a last additional expression that returns true.

The next step is to create a custom IValidationAction that inherits from BaseValidationAction, that will store our validation rule’s error message, and build the current context’s full path info:

public class ErrorMessageContextAction: BaseValidationAction
{
    /// <summary>
    /// Gets or sets the error message.
    /// </summary>
    public string Message { get; set; }

    protected override void OnInvalid( object validationContext, IDictionary contextParams, IValidationErrors errors )
    {
        var objContext = contextParams["ObjectContext"] as ObjectContext;

        if ( objContext == null ) return;

        var error = new ErrorMessage( null, Message );
        errors.AddError( objContext.ContextPath, error );
     }
 }

BaseValidationAction provides two virtual methods OnInvalid and OnValid, that are called when a rule fails or passes. ErrorMessageContextAction has one property called Message, that is set to the actual error message we wish to display. Our override of OnInvalid uses ObjectContext.ContextPath to build the full path of the current context. This full path will be used as our ‘provider’. ASP MVC’s built-in error message handling magic fulfills the role of validation errors renderer using this ‘provider’.

The last piece of the puzzle is a custom IValidationErrors implementation that will add validation errors to a MVC Controller’s ViewData.ModelState:

public class ModelStateErrors: IValidationErrors
{
    ModelStateDictionary modelState;

    public ModelStateErrors( ModelStateDictionary modelState )
    {
        this.modelState = modelState;
    }

    public void AddError( string provider, ErrorMessage message )
    {
        if ( message != null &&
             message.Parameters != null &&
             message.Parameters.Length > 0 &&
             message.Parameters[0] != null &&
             message.Parameters[0] is string )
        {
            modelState.AddModelError( provider, message.Parameters[0].ToString() );
        }
    }

    public void MergeErrors( ValidationErrors errorsToMerge )
    {
        throw new System.NotImplementedException();
    }

    public IList GetErrors( string provider )
    {
        var modelStateDict = modelState[provider];
        return modelStateDict == null ? null : modelStateDict.Errors;
    }

    public IList GetResolvedErrors(string provider, IMessageSource messageSource)
    {
        throw new System.NotImplementedException();
    }

    public bool IsEmpty
    {
        get { return modelState.Count == 0; }
    }

    public IList Providers
    {
        get
        {
            return modelState.Keys.ToList();
        }
    }
}

Class ModelStateErrors internally wraps a ViewData‘s ModelStateDictionary, and automatically adds Spring.NET validation errors to it. The provider name is used as the key for AddModelError, because this is the ‘bucket’ that we’d like to sink the message to. The ErrorMessage‘s first parameter is expected to be the message text.

Usage and Conclusion

An important point to remember when specifying the context in Spring’s validation configuration, is to always provide a complete path from the current node to a final leaf node. It is important to StepIn and StepOut of contexts in-sync with the validation rules. If a context is skipped, our we don’t StepOut of a previous one, we will not get the correct path. When you get the wrong context, check that you’ve SteppedOut as many times as you’ve SteppedIn, to bring you back to the current node or level. Also check that you’ve specified the correct context names when you StepInto a context.

All we need to do is make sure our context navigation correctly follows our validation rules. Apart from this we don’t really need to do anything else to get Spring.NET to add its validation errors and messages to ViewData’s ModelState:

1. Import the namespace where the ValidatorGroupExtensions is defined:

using Shinobido.GhostBlade.Extensions;

2. Get the desired ValidatorGroup from Spring.NET’s objects configuration.
3. Call ValidatorGroup.Validate with ModelStateErrors as the IValidationErrors implementation, and hasContext as true.

Just obtain the desired ValidatorGroup from the objects configuration, ModelStateErrors as the IValidationErrors implementation in a Controller’s Action method:

public partial class CustomerController: Controller
{
    public ActionResult EditPersonalAssessment( int id )
    {
        var customer = ObjectManager.New<ICustomer>();
        customer.ContactNumbers = new ContactNumbers
                                  {
                                      CellPhone = "djsk"
                                  };
        customer.Spouse = new Spouse
                          {
                              ContactNumbers = new ContactNumbers
                                               {
                                                   CellPhone = "kasjd"
                                               }
                          };
        var validator = ObjectManager.New<ValidatorGroup>( "customerValidator" );
        var result = validator.Validate( sampleObj, new ModelStateErrors( ViewData.ModelState ), true );
    }
}

From the final usage we observe that it’s a pretty neat way of integrating Spring.NET’s Validation Framework with ASP .NET MVC’s ModelState and error handling magic. The only part that’s a bit weird is the way we specify the context in Spring.NET’s validation configuration. It abuses the IExpression attributes a little in a way that they weren’t originally designed for. But I believe this is a small price to pay to gain the huge benefit of automatic integration of Spring.NET’s Validation Framework and ASP MVC’s validation and error handling and display.

In the next Spring.NET post I’ll be covering how to use Spring.NET’s Aspect Oriented Programming (AOP) to create an impersonation aspect. Happy Springing until then!


The Only C# .NET Singleton You’ll Ever Need

My colleague, Riaan Hanekom from NGenerics fame, showed me his perfect code for a singleton in C# .NET (version 2 and later). This generic class can create a singleton for any non-static class that has a default constructor.

This program is licensed under the Microsoft Permissive License (Ms-PL).  You should
have received a copy of the license along with the source code.  If not, an online copy
of the license can be found at http://www.codeplex.com/NGenerics/Project/License.aspx.
*/
public static class Singleton<T> where T:new()
{
private static readonly T instance = new T();
public static T Instance
{
get
{
return instance;
}
}
}
So simple, yet so complete…

Follow

Get every new post delivered to your Inbox.