DynamicProxy tutorials - Krzysztof Koźmic

Currently looking at DynamicProxy tutorials by Krzysztof Koźmic Any AOP type development is a candidate to be done by DP.

Excellent tutorial series...

Leave the irrelevant standards out of the coding standards...

Coding standards are put in place primarily for maintainability purposes but how far does an organisation/company or induvidual go in relation to coding standards?

Heres my opinion on coding standards: Once the code is some way consistent - that is acceptable enough to me.

Having to define exactly how many lines are between methods, and spacing rules are irrelevant in comparison to the quality of the code that is actually written.

Some open source projects that I have looked at (Castle and NHibernate to name a few) have general coding standards but don't go down to a spacing level.

I recently worked on a project where coding standards were so stringent that we had to run regression tests again due to spacing issues! - The word "practicality" comes to mind

Binsor 2.0 Spike

Recently, I tasked myself with the responsibility of spiking Binsor and checking if my current projects castle configuration (which we have in an XML config file) could be fully converted.

Binsor is a DSL language for Castle Windsor and is a feature offered in the reknowned open source Rhino.Commons assembly. There are quite a few "basic" posts about Binsor but there were a few configuration scenarios that I had to dig deeply for. This post attempts to describe these scenarios and also give an overall verdict of Binsor as a whole.

1. Import statements

You must import all assembly types in a Binsor file e.g.

import Billy.CommonLibraries
import Billy.Application.Facade from Billy.Application.Facade.RC2

Note that if you have a type with a namespace that is different to the assembly name e.g. all types under Billy.Application.Facade, you must specify in the format <namespace> from <assembly name>

2. Properties

Properties are simply represented via boo variable declaration e.g.

<properties>
 <p1>00:02:00</p1>
 <p2>SampleString</p2>
</properties>

would be represented as:

p1 = "00:02:00"
p2= "SampleString"

3. Comments

All comment lines start with '#' e.g.

# Properties

4. Facilities

Declaring facility usage is simple e.g.

<facility
 id="factory_Support"
 type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.MicroKernel" />

would be represented as:

facility FactorySupportFacility

5. Components

The following component Billy.CommonTypes.Handler.Default

<component
 id="exceptionHandler"
 service="Billy.CommonTypes.IHandler, Billy.CommonTypes"
 type="Billy.CommonTypes.Handler.Default, Billy.CommonTypes">
</component>

would be represented as:

component "exceptionHandler", Billy.CommonTypes.IHandler, Billy.CommonTypes.Handler.Default

6. Types instantiated using instance fields

The following component configuration for Billy.CommonTypes.SystemClock

<component
 id="clock"
 service="Billy.CommonTypes.IClock, Billy.CommonTypes"
 type="Billy.CommonTypes.SystemClock, Billy.CommonTypes"
 instance-accessor="Instance">
</component>

would be represented as:

component "clock", Billy.CommonTypes.IClock, Billy.CommonTypes.SystemClock: 
 createUsing Instance

7. Components with parameters

<component
 id="exceptionLogger"
 service="Billy.CommonTypes.Exception.ILogger, Billy.CommonTypes"
 type="Billy.CommonTypes.Exception.Logger.EventLog, Billy.CommonTypes">
 <parameters>
  <logName>#{exceptionLogName}</logName>
  <source>#{exceptionLogSource}</source>
 </parameters>
</component>

would be represented as:

component "exceptionHandler", Billy.CommonTypes.Exception.ILogger, Billy.CommonTypes.Exception.Logger.EventLog: 
 logName = exceptionLogName 
 source = exceptionLogSource

8. Components instantiated using factories

<component
 id="sampleTypeInstantiatedWithFactory"
 service="Billy.CommonTypes.IProviderFactory, Billy.CommonTypes"
 type="Billy.CommonTypes.ProviderFactory, Billy.CommonTypes"
 factoryId="mySampleFactory"
 factoryCreate="GetSampleType">
</component>

would be represented as:

component "sampleTypeInstantiatedWithFactory", Billy.CommonTypes.IProviderFactory, Billy.CommonTypes.ProviderFactory" 
 createUsing @mySampleFactory.GetSampleType

9. Event wiring

<component
 id="eventingBroker"
 service="Billy.CommonTypes.Eventing.IBroker, Billy.CommonTypes"
 type="Billy.CommonTypes.Eventing.Broker, Billy.CommonTypes">
 <subscribers>
  <subscriber
   id="subscriber1"
   event="Event1"
   handler="OnEvent1Firing" />
  <subscriber
   id="subscriber2"
   event="Event2"
   handler="OnEvent2Firing" />
 </subscribers>
</component>

would be represented as:

component "eventingBroker", Billy.CommonTypes.Eventing.IBroker, Billy.CommonTypes.Eventing.Broker:
 wireEvent Event1:
  to @subscriber1.OnEvent1Firing
 wireEvent Event2:
  to @subscriber2.OnEvent2Firing

10. Startable components

<component
 id="myStartableComponent"
 type="Billy.CommonTypes.Type1, Billy.CommonTypes"
 startable="true">
</component>

would be represented as:

component "myStartableComponent", Billy.CommonTypes.Type1:
 @startable = true

11. Transient components

<component
 id="myTransientComponent"
 type="Billy.CommonTypes.Type2, Billy.CommonTypes"
 lifestyle="transient">
</component>

would be represented as:

component "myTransientComponent", Billy.CommonTypes.Type2:
 lifestyle Transient

12. WCF client components

<component
 id="myWCFClient"
 type="Billy.Clients.IClient, Billy.Clients"
 wcfEndpointConfiguration="MyClient">
</component>

would be represented as:

component "myWCFClient", Billy.Clients.IClient:
 wcfEndpointConfiguration="MyClient"

Conclusion

Excellent overall as it reduced the size of my castle configuration file down to 38% of its original size. The Binsor file is also much more readable and eradicates all the XML fluff! However the downside is that I had to reference the Rhino.Commons assembly. Binsor may get integrated into Castle in a future release so I am nearly more inclined to wait until this happens!

A big thank you to Craig Neuwirt for answering any Binsor questions that I had (via Castle forum)

Setter injection - when its makes sense to use it

It is common enough to have a bunch of subclasses that all implement the same contract and have a common base class,dependencies, ctor etc.

Sometimes one of these subclasses needs an extra dependency. If you are working within a TTD framework, it is likely that you inject all dependencies into your classes via the ctor (i.e. ctor dependency injection). Now, because your new class breaks the mould, what do you do?

1. Do you update the base class to include this new dependency? - Bad as every other subclass does not require this dependency.

2. Do you create a subclass base class that contains this dependency. This isnt too bad but if you know that no other class will need this dependency then a subclass base class is wasteful.

3. Simply new up the dependency object in the subclass that requires it. This is ideal from a functional perspective. However we still cannot test the subclass as we cannot mock up the dependency.

4. Simply new up the dependency object in the subclass that requires it but in addition, add a setter method in the subclass to enable you to set the dependency with a mocked up dependency for testing purposes. In the actual code, the real dependency is still instantiated in the ctor. See the code extract below:

public class Class1: Base
{
     private IExtraDependency  c_extraDependency;

     public IExtraDependency ExtraDependency
     {
          set { this.c_extraDependency= value; }
     }

     public Class1(Param1 p1) : base(p1)
     {
          this.c_extraDependency = new ConcreteExtraDependency();
     }

The production code will never call the setter but the test code will. When using Castle Windsor or any other IOC container for that matter, I like to use constructor injection. However if an "oddball" dependency surfaces, that must be covered in testing - it doesnt make sense to always have to inject that dependency via ctor.

In the example above it makes sense to tightly bind Class1 with its extra dependency but we also make it testable via setter injection.

More NHibernate Validator...

[CreditCardNumber]
public readonly string CreditCard;

Two things to quickly point out:

1. Works on readonly attributes (big thing where defining immutable types where attributes are only set vai ctor)

2. [CreditCardNumber] validation performs luhn check! - didnt expect that...

NHibernate Validator

In a domain driven design codebase, all value types should be immutable. Also, where concerns such as concurrency raises its head, defining as many entities as possible as immutable can really simplify things.

NHibernate validator helps you to ensure that value/entity types never enter an invalid state.

You can implement validation using NHibernate Validator by declarative tags, fluent interfaces or defining the validation in an xml file. I really like the latter mechanism i.e. defining validation in an xml file as you are not polluting entity/value type ddfinition with validation logic.

In relation to ORMs, one major problem that has been discussed numerous times in DDD forums is that when a value type is retrieved from the database, it may be in an invalid state. Before with NHibernate, we got around this by validating the object retrieved manually via a PostLoadEventListener handler. However NHibernate Validator has full integration with the NHibernate lifecycle and it really makes it easy now to validate post load.

Overall, Im very impressed with NHibernate Validator...

Epicenter 2009

The irish software show (epicenter) is on in Dublin on August 24th - 28th 2009. From what I know it is an amalgamation of microsoft, opensource, java, database and architecture tracks so I would highly recommend going to this if you are around the dublin area: Ref: http://epicenter.irishdev.com/