Eric Hauser’s Blog

In part 1, I discussed what Castle ActiveRecord does when starting up and ways you can modify the model after is has been generated.  Another useful trick is to add custom attributes to your model that can be inspected while ActiveRecord is inspecting its model.  To this you need to create a class that implements Castle.ActiveRecord.Framework.Internal.IModelBuilderExtension and register it with the ActiveRecordStarter.

For my example, let’s assume that we want to implement soft deletes using ActiveRecord.  The NHibernate FAQ has a great blog entry on how to make NHibernate mark a entity as deleted as opposed to deleting it from the database.  Assuming you are using their model of marking your entities as ISoftDeleteable, here are two things we can do to extend this model:

1. If session.Get(id) is called on soft deleted record, null is returned.
2. If a collection contains a record that has been soft deleted, that record will not show up when the collection is loaded.

I am not entirely sure that these two features are something that you want to necessarily do, however, they are good examples for what I am trying to show.  The reason I say that is because I am not sure you want entities showing up sometimes and not other times, i.e. a soft deleted model would show up for a custom query unless someone checks the Deleted flag, how do soft deletes work across entity graphs, should we allow both ends of a bidirectional relationship to be soft deleteable, etc.  So, I have kept this example limited too two easy features, but remember to think about this a little more before actually implementing it.  So on to the example, the first thing we need to is to add a custom model builder to inspect our model:

   1: public class SoftDeleteModelBuilderExtension : IModelBuilderExtension

   2: {

   3:  

   4:     public static IDictionary<Type, SoftDeleteModel> SoftDeleteModels = new Dictionary<Type, SoftDeleteModel>();

   5:  

   6:     #region IModelBuilderExtension Members

   7:  

   8:     public void ProcessBelongsTo(System.Reflection.PropertyInfo pi, BelongsToModel belongsToModel, ActiveRecordModel model)

   9:     {

  10:     }

  11:  

  12:     public void ProcessClass(Type type, ActiveRecordModel model)

  13:     {

  14:         GetModel(type, model);

  15:     }

  16:  

  17:     public void ProcessField(System.Reflection.FieldInfo fi, ActiveRecordModel model)

  18:     {

  19:     }

  20:  

  21:     public void ProcessHasAndBelongsToMany(System.Reflection.PropertyInfo pi, HasAndBelongsToManyModel hasAndBelongManyModel, ActiveRecordModel model)

  22:     {

  23:         if (!IsSoftModel(hasAndBelongManyModel.HasManyAtt.MapType)) return;

  24:         var softDeleteModel = GetModel(model.Type, model);

  25:         softDeleteModel.HasAndBelongsToMany.Add(hasAndBelongManyModel);

  26:     }

  27:  

  28:     public void ProcessHasMany(System.Reflection.PropertyInfo pi, HasManyModel hasManyModel, ActiveRecordModel model)

  29:     {

  30:         if (!IsSoftModel(hasManyModel.HasManyAtt.MapType)) return;

  31:         var softDeleteModel = GetModel(model.Type, model);

  32:         softDeleteModel.HasMany.Add(hasManyModel);

  33:     }

  34:  

  35:     public void ProcessHasManyToAny(System.Reflection.PropertyInfo pi, HasManyToAnyModel hasManyModel, ActiveRecordModel model)

  36:     {

  37:         if (!IsSoftModel(hasManyModel.HasManyToAnyAtt.MapType)) return;

  38:         var softDeleteModel = GetModel(model.Type, model);

  39:         softDeleteModel.ManyToAny.Add(hasManyModel);

  40:     }

  41:  

  42:     public void ProcessProperty(System.Reflection.PropertyInfo pi, ActiveRecordModel model)

  43:     {

  44:     }

  45:  

  46:     private static bool IsSoftModel(Type type)

  47:     {

  48:         return (typeof(ISoftDeleteable).IsAssignableFrom(type));

  49:     }

  50:  

  51:     private static SoftDeleteModel GetModel(Type type, ActiveRecordModel model)

  52:     {

  53:         SoftDeleteModel softDeleteModel;

  54:         SoftDeleteModels.TryGetValue(type, out softDeleteModel);

  55:  

  56:         if (softDeleteModel == null)

  57:         {

  58:             softDeleteModel = new SoftDeleteModel {Type = type, ActiveRecordModel = model};

  59:             if (IsSoftModel(type))

  60:                 softDeleteModel.SoftDeleteable = true;

  61:             SoftDeleteModels[type] = softDeleteModel;

  62:         }

  63:         return softDeleteModel;

  64:     }

  65:  

  66:     #endregion

  67: }

   1: public class SoftDeleteModel

   2: {

   3:     /// <summary>

   4:     /// Gets or sets the type.

   5:     /// </summary>

   6:     /// <value>The type.</value>

   7:     public Type Type { get; set; }

   8:  

   9:     /// <summary>

  10:     /// Gets or sets a value indicating whether the model is soft deleteable.

  11:     /// </summary>

  12:     /// <value><c>true</c> if soft deleteable; otherwise, <c>false</c>.</value>

  13:     public bool SoftDeleteable { get; set; }

  14:  

  15:     /// <summary>

  16:     /// Gets or sets the active record model for this type.

  17:     /// </summary>

  18:     /// <value>The active record model.</value>

  19:     public ActiveRecordModel ActiveRecordModel { get; set; }

  20:  

  21:     private readonly HashSet<HasManyModel> _hasMany = new HashSet<HasManyModel>();

  22:  

  23:     /// <summary>

  24:     /// Gets the has many relationships to a soft deleted type.

  25:     /// </summary>

  26:     /// <value>The has many.</value>

  27:     public HashSet<HasManyModel> HasMany

  28:     {

  29:         get { return _hasMany; }

  30:     }

  31:  

  32:     private readonly HashSet<HasAndBelongsToManyModel> _hasAndBelongsToMany = new HashSet<HasAndBelongsToManyModel>();

  33:  

  34:     /// <summary>

  35:     /// Gets the has and belongs to many relationships to a soft deleted type.

  36:     /// </summary>

  37:     /// <value>The has and belongs to many.</value>

  38:     public HashSet<HasAndBelongsToManyModel> HasAndBelongsToMany

  39:     {

  40:         get { return _hasAndBelongsToMany; }

  41:     }

  42:  

  43:     private readonly HashSet<HasManyToAnyModel> _manyToAny = new HashSet<HasManyToAnyModel>();

  44:  

  45:     /// <summary>

  46:     /// Gets the many to any relations that belong to a soft deleted type.

  47:     /// </summary>

  48:     /// <value>The many to any.</value>

  49:     public HashSet<HasManyToAnyModel> ManyToAny

  50:     {

  51:         get { return _manyToAny; }

  52:     }

  53: }

As you can see, as the models as being inspected, we are building up a model of class that are soft deleted and classes that have collections of classes that are soft deleted.  To add our custom model inspector to ActiveRecord simply do the following line before calling ActiveRecordStarter.Initialize():

   1: ActiveRecordStarter.RegisterExtension(new SoftDeleteModelBuilderExtension());

Now, that we have our soft delete model we need to remove any of the collections that are mapped to ISoftDeleteable entities.  We are going to add these collections back later though.  To remove these collections, we need to write a model visitor that I discussed in Part 1:

   1: public class SoftRelationshipsRemovalVisitor : AbstractDepthFirstVisitor

   2: {

   3:     private readonly HashSet<ActiveRecordModel> _visited = new HashSet<ActiveRecordModel>();

   4:  

   5:     /// <summary>

   6:     /// Visits the model.

   7:     /// </summary>

   8:     /// <param name="model">The model.</param>

   9:     public override void VisitModel(ActiveRecordModel model)

  10:     {

  11:         if (!_visited.Contains(model))

  12:             _visited.Add(model);

  13:         else

  14:             return;

  15:  

  16:         if (SoftDeleteModelBuilderExtension.SoftDeleteModels.ContainsKey(model.Type))

  17:         {

  18:             var softDeleteModel = SoftDeleteModelBuilderExtension.SoftDeleteModels[model.Type];

  19:  

  20:             foreach (var hasMany in softDeleteModel.HasMany)

  21:                 model.HasMany.Remove(hasMany);

  22:  

  23:             foreach (var hasAndBelongsToManyModel in softDeleteModel.HasAndBelongsToMany)

  24:                 model.HasAndBelongsToMany.Remove(hasAndBelongsToManyModel);

  25:  

  26:             foreach (var manyToAny in softDeleteModel.ManyToAny)

  27:                 model.HasManyToAny.Remove(manyToAny);

  28:         }

  29:     }

  30: }

And to register the visitor:

   1: ModelsDelegate validated = null;

   2: validated = delegate(ActiveRecordModelCollection models, IConfigurationSource source)

   3: {

   4:     ActiveRecordStarter.ModelsValidated -= validated;

   5:     foreach (ActiveRecordModel model in models)

   6:     {

   7:         model.Accept(new SoftRelationshipsRemovalVisitor());

   8:     }

   9: };

  10: ActiveRecordStarter.ModelsValidated += validated;

Now when our entities are generated by ActiveRecord, they will no longer have mapped collections that go to ISoftDeleteable entities.  Now that they are gone what next?  In Part 3,  I will examine how to add back the collections we removed so that they take into account the soft deleted entities. At the end of this series, I will post the full source code for the solution.

Sometimes I find the need to inject dependencies from the container into a type that is not registered as a component. It does not come up very often, but mainly it is something that I need when writing tests and it does not make sense to register my object with the container.  Turns out this is pretty easy with Windsor:

   1: public static class IKernelExtensions

   2: {

   3:  

   4:     public static T Autowire<T>(this IKernel kernel)

   5:     {

   6:         ComponentModel component = kernel.ComponentModelBuilder.BuildModel(typeof(T).FullName, typeof(T), typeof(T), null);

   7:         var activator = kernel.CreateComponentActivator(component);

   8:         return (T)activator.Create(CreationContext.Empty);

   9:     }

  10:  

  11: }

  12:  

  13: [TestClass]

  14: public class IKernelExtensionsTests 

  15: {

  16:     [TestMethod, ExpectedException(typeof(ComponentNotFoundException)]

  17:     public void Autowire_creates_an_object_with_adding_to_container()

  18:     {

  19:         var kernel = new DefaultKernel();

  20:         kernel.AddComponent("test", typeof(IServiceInterface), typeof(ServiceInferface));

  21:         var someService = kernel.Autowire<SomeService>();

  22:         Assert.IsNotNull(someService.ServiceInterface);

  23:         kernel.Resolve<SomeService>();

  24:         Assert.Fail();

  25:     }

  26:  

  27:     [TestMethod, ExpectedException(typeof(ComponentNotFoundException))]

  28:     public void Autowire_creates_an_object_with_adding_to_container_using_constructur()

  29:     {

  30:         var kernel = new DefaultKernel();

  31:         kernel.AddComponent("test", typeof(IServiceInterface), typeof(ServiceInferface));

  32:         var someService = kernel.Autowire<SomeServiceCtorInjection>();

  33:         Assert.IsNotNull(someService.ServiceInterface);

  34:         kernel.Resolve<SomeServiceCtorInjection>();

  35:         Assert.Fail();

  36:     }

  37:  

  38:     public class SomeService

  39:     {

  40:         public IServiceInterface ServiceInterface { get; set; }

  41:     }

  42:  

  43:     public class SomeServiceCtorInjection

  44:     {

  45:         public SomeServiceCtorInjection(IServiceInterface serviceInterface)

  46:         {

  47:             ServiceInterface = serviceInterface;

  48:         }

  49:  

  50:         public IServiceInterface ServiceInterface { get; private set; }

  51:     }

  52:  

  53:     public interface IServiceInterface

  54:     {

  55:     }

  56:  

  57:     public class ServiceInferface : IServiceInterface

  58:     {    

  59:     }

  60: }

Before you can do anything exciting, it is important to understand what exactly Castle ActiveRecord does when starting up. Specifically, what happens when you can ActiveRecordStarter#Initialize():

1. Inspects supplied types or assemblies looking for ActiveRecord attributes.
2. Creates an in memory model of the attributes (Castle.ActiveRecord.Framework.Internal.ActiveRecordModelBuilder)
3. Uses the visitor pattern to connect the model for things like many-to-many relationships (Castle.ActiveRecord.Framework.Internal.GraphConnectorVisitor)
4. Verifies that the model is valid (Castle.ActiveRecord.Framework.Internal.SemanticVerifierVisitor)
5. Generates NHibernate XML mappings for the model (Castle.ActiveRecord.Framework.Internal.XmlGenerationVisitor)
6. Initializes NHibernate with the generated mappings

ActiveRecordStarter provides a few events that you can attach to modify the model, ModelsCreated and ModelsValidated (I originally found out about this extension point when reviewing the code for Ayende’s Rhino Security).  What are some of the things you can do with these events?  The project I am working on uses SQL Server schemas to separate different groups of tables. So all of our table mappings look like: [ActiveRecord("`TableName`", "`SchemaName`", Lazy = True)].   We have a number of unit tests for our database classes that we want to run with SQLite so they can run on our build server with no external dependencies. SQLite does not support schemas though, so we can use ActiveRecordStarter to modify our model:

   1: AppSettingsSection nhibernateSection = ConfigurationManager.GetSection("nhibernate") as AppSettingsSection;

   2: if (nhibernateSection != null && nhibernateSection.Settings["dialect"].Equals("NHibernate.Dialect.SQLiteDialect"))

   3: {

   4:     ModelsDelegate validated = null;

   5:     validated = delegate(ActiveRecordModelCollection models, IConfigurationSource source)

   6:                     {

   7:                         ActiveRecordStarter.ModelsValidated -= validated;

   8:                         foreach (ActiveRecordModel model in models)

   9:                         {

  10:                             model.Accept(new ChangeSchemaVisitor());

  11:                         }

  12:                     };

  13:     ActiveRecordStarter.ModelsValidated += validated;

  14: }

  15: ActiveRecordStarter.Initialize();

  16:  

  17: ...

  18:  

  19: internal class ChangeSchemaVisitor : AbstractDepthFirstVisitor

  20: {

  21:     public override void VisitModel(ActiveRecordModel model)

  22:     {

  23:         var schema = model.ActiveRecordAtt.Schema;

  24:         model.ActiveRecordAtt.Table = schema + "_" + model.ActiveRecordAtt.Table;

  25:         model.ActiveRecordAtt.Schema = null;

  26:         base.VisitModel(model);

  27:     }

  28:  

  29:     public override void VisitHasAndBelongsToMany(HasAndBelongsToManyModel model)

  30:     {

  31:         var schema = model.HasManyAtt.Schema;

  32:         model.HasManyAtt.Table = schema + "_" + model.HasManyAtt.Table;

  33:         model.HasManyAtt.Schema = null;

  34:     }

  35: }

This is just a simple example, but there are a lot of problems you can solve be using the model visitors. Rhino Security uses this pattern to add caching to all the mappings, add schemas to models, and replaces interfaces in the model with actual entities.

At work, we use Zutubi Pulse as a build server across the enterprise.  Since the majority of the applications we build are not written in .NET, Pulse is a good choice.  Seems to do a lot of things well, has a nice user interface, and has some advanced features.  I wish we used something that was a little more .NET friendly (like TeamCity), but with a little work I was able to have some success at making it feel that way.

Since it supports external executables for building projects, we just use batch scripts to build our .NET projects.  This works fine except that when a build fails, Pulse does not capture the reason why in its UI, instead you have to drill into the console output to find the cause.  I dug into Pulse’s documentation and found out that it has a post processor that meets this need.  The post processor will parse the log output and capture any errors and warnings.  All that is needed is a regular expression to capture the error and warning lines.  Here is why I use for MSBuild:

   1: <regex.pp name="compiler.processor">

   2:     <pattern category="error" expression="^(.*)\\\.cs\\\(\\\d+,\\\d+\\\): error(.*)\$"/>

   3:     <pattern category="warning" expression="^(.*)Microsoft.Common.targets : warning(.*)\$"/>

   4:     <pattern category="warning" expression="^(.*)\\\.cs\\\(\\\d+,\\\d+\\\): warning (.*)\$"/>

   5: </regex.pp>

This will capture compiler errors and warnings, and also capture warnings from MSBuild itself. 

In order to capture the output from our unit tests, I a wrote a converter that converts MSTest XML into JUnit XML so that Pulse can report on our unit tests.   Pulse supports JUnit natively, so converting the MSTest XML was not that complex of a task.  Unfortunately, I cannot share that code.

I’ve been spending some time working with NServiceBus lately as we are looking for an open source publish/subscribe framework written in .NET.  I like what I have seen so far, although I think that the development model could be a little simpler.  My biggest gripe is that messages have to implement an IMessage interface and there is no mechanism for supporting headers on message envelopes.  That aside, Udi’s responsiveness (and politeness) to everyone who posts on the NServiceBus forum is refreshing and he seems to listen to people who make good suggestions.

A discussion came up on the list about implementing a retry strategy for when a message handler fails to execute (maybe a database is down for instance).  The nice thing about NServiceBus is that adding something like this is just a matter of doing some simple programming.  No worries implementing of custom behaviors or adding XML required.

My simple solution (which is just some prototype code):

   1: public interface IReplayableMessage : IMessage

   2: {

   3:   int RetryCount { get; set; }

   4:   DateTime LastReplayAttempt { get; set; }

   5: }

   6:  

   7: public abstract class RetryMessageHandler<TMessage> : IMessageHandler<TMessage>

   8:   where TMessage : IReplayableMessage

   9: {

  10:  

  11:   public IBus Bus { get; set; }

  12:  

  13:   public void HandleMessage(TMessage message)

  14:   {

  15:     if (DateTime.Now - message.LastReplayAttempt < 5.Seconds())

  16:     {

  17:       Bus.HandleMessageLater();

  18:       return;

  19:     }

  20:     try

  21:     {

  22:       HandleMessageInternal(message);

  23:     }

  24:     catch (Exception e)

  25:     {

  26:       if (message.RetryCount < 5)

  27:       {

  28:         message.RetryCount = message.RetryCount++;

  29:         message.LastReplayAttempt = DateTime.Now;

  30:         Bus.Send(message);

  31:       }

  32:       else

  33:      {

  34:        ..log error and move to dead letter queue..

  35:      }

  36:     }

  37:   }

  38:  

  39:   public abstract void HandleMessageInternal(TMessage message);

  40:  

  41: }

This is just some simple prototype code, but as you can see, NServiceBus handlers are easy to write and test.  For a more complicated implementation, Apache Camel has an implementation of the dead letter channel pattern to get some ideas from.  It keeps the message in memory while trying to retry and sleeps while waiting to reprocess.  The example I gave sends the message back to the end of the queue.

Besides ReSharper, there is only one other Visual Studio plugin that I cannot live without — GhostDoc.  If you have not used it before, it basically generates XML comments on your code and makes a best guess on what the comment summary should be.  This feature is pretty standard for Java IDEs (except for the actually generation of the summary for you), but it is yet another thing that is missing in Visual Studio. 

If you follow good naming conventions in your code, then you should get pretty decent results on the summary it generates.  It is definately a keystroke saver and makes documenting your code somewhat infectious.  When I see code that is undocumented, it is really hard for me not to hit Ctrl-Shift-D and have GhostDoc document it.

There are a number of different features/options and I am definitely not doing it justice in this short post.  The best way to find out if you like it is to try it out.  Small download and quick installation.

If you are familiar with NHibernate flushing semantics, then you know you usually want to treat a group of database operations as a single unit of work.  For one reason, flushing is expensive because it requires checking all of your entities for changes to see if they should be persisted to the database.  Second, you often want to treat all of your database operations as an atomic transaction.  Third, any entities that have lazy loaded properties can take advantage of the existing session.  ActiveRecord provides a nice abstraction for treating multiple database operations as a unit of work called SessionScope.  For instance, if all of your database operations are grouped together in one location, you would use SessionScope like:

var person = ...
var child = ...
using (SessionScope scope = new SessionScope)
{
  person.Save();
  child.Save();
}

In this case the neither the person or child is saved to the database until the Dispose() is called on the SessionScope.  For  the simple scenarios, this works fine, but in most cases you are doing your database operations in a DAO or Repository class — so you do not know how the database operations are going to be used or what other operations are going to be used with them.

If you are using ActiveRecord with MonoRail or another MVC framework, odds are you are using the built in SessionScopeWebModule to manage the SessionScope for you.  The web module begins a session when an HTTP request begins and ends it when the request has been processed.  Internally, the module uses HttpContext.Current.Items to store the current SessionScope in a thread local while the request is being processed.  If you are hosting your WCF services under IIS, you can take advantage of the web module to manage your SessionScope for you. 

If you are hosting not hosting your WCF services under IIS, then you need another mechanism for managing the SessionScope.  Fortunately, WCF provides a hook for just this type of scenario, ICallContextInitializer.  The WCF examples taking about using this extension point for managing thread context culture or impersonation scenarios.  First you need to implement ICallContextInitializer (I have removed documentation and logging for brevity, but I would recommend putting logging statements in so you can see what is going on at runtime):

    public class ARSessionScopeCallContextlInitializer : ICallContextInitializer
    {

        private const string ActiveRecordSessionScopeKey = "wcf.ar.sessionscope";

        public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message)
        {
            SessionScope scope = Local.Data[ActiveRecordSessionScopeKey] as SessionScope;
            if (scope == null)
            {
                Logger.Debug("Creating new ActiveRecord SessonScope");
                scope = new SessionScope();
                Local.Data[ActiveRecordSessionScopeKey] = scope;
            }
            return scope;
        }

        public void AfterInvoke(object correlationState)
        {
            SessionScope scope = Local.Data[ActiveRecordSessionScopeKey] as SessionScope;
            if (scope != null)
            {
                scope.Dispose();
            }
        }

    }

You can find the Local.Data class in Ayende’s rhino-commons library, but it just a simple wrapper around thread local storage.  Next, you need to implement IEndpointBehavior to add the initializer to your service:

    public class ARSessionScopeBehavior : IEndpointBehavior
    {

        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            foreach (DispatchOperation operation in endpointDispatcher.DispatchRuntime.Operations)
            {
                 operation.CallContextInitializers.Add(new ARSessionScopeContextCallInitializer());
            }
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
        }

        public void Validate(ServiceEndpoint endpoint)
        {
        }

    }

And finally, an example for configuring your service:

            var uri = new Uri("net.tcp://localhost/TestSessionScope");
            var host = new WindsorServiceHost(typeof(AuthorizationService));
            var endpointAddress = new EndpointAddress(uri);
            var endpoint = new ServiceEndpoint(ContractDescription.GetContract(typeof (ITestService)), new NetTcpBinding(), endpointAddress);
            endpoint.Behaviors.Add(new ARSessionScopeBehavior());
            _host.Description.Endpoints.Add(endpoint);
            _host.Open();

And that’s it.  If you want to be more explcit about your flushing behavior — for instance creating a ReadOnlySessionScope that never flushes for read only operations, you can modify the EndpointBehavior to work declaritively with attributes so that you could mark individual WCF methods with configuration information such as [ReadOnly].  I have read some discussions about poor performance do to flushing of read only operations, so this might be worth looking into if you are doing a lot of read only operations on a large object graph.

Ayende is complaining because of a post Glen Block made on the Alt.NET mailing list.  I think Ayende read Glen’s post the wrong way.  I read what Glen said and I do not think this is a bad thing.  What I read was in the next version of EntLib and WCF Composite, you would actually be able to use Windsor (or the container of your choice) instead of being forced to use ObjectBuilder.

I do not think that WCF Composite or EntLib are going away anytime soon, so freeing them from the ObjectBuilder dependency is a good thing.

Since Resharper will not support C# 3.0 features until next year and I do not like working in Visual Studio without Resharper, I was happy when I ran across this post by Jeffrey Palermo: http://codebetter.com/blogs/jeffrey.palermo/archive/2007/11/28/temporarily-disable-code-analysis-for-single-code-file-with-resharper-3-0-2-and-vs-2008.aspx.  This is a good workaround for allow the annoying error highlights of correct C# 3.0 code.  Now if someone could combine this with a macro to toggle between Visual Studio and Resharper Intellisense, we would have the ideal workaround until 4.0 EAP.

Yesterday, I posted a solution for intercepting WCF calls with IOperationInvoker for validation.  At the end of the article, I mentioned that you could probably get this integration working with Castle’s Validator if you did not want to use the Enterprise Library Validation Application Block.  I forgot that Windsor supports configuring components as WCF services.  While you could go the route that I suggested, you would probably be better served to take a look at Windsor’s WCF integration http://www.ayende.com/Blog/archive/2007/06/12/WCF-Windsor-Integration.aspx.  Then, you can use Castle Validator and configure your validations with attributes or Windsor.