Generic Singleton Factory

Not too long after writing and blogging about a generic singleton base, I changed the code to use a Factory - a singleton factory to be specific. Below is a factory which can be used to create a singleton instance of any class. The original singleton base class implementors needed to be sealed or have unintended consequences of getting an instance of the wrong class. This caused me to reflect and conclude that the design was deceptive as it was almost in essense a factory.

Below is a refactored version which is a little more genuine. This is my first crack, and requires generics. I do not use this everywhere I use singletons but where the usage of a Factory fits better than a singleton such as when you have many implementors of the same interface and you want singleton creational behavior.

Jon Skeet's has a great article on some different singleton designs in his blog.

Automatically mapping objects of same derived types

I had a need to automatically map all properties from one class to another class. These two classes had the same derived type, this was by design and not by accident. FYI: this example's Unit Test uses NUnit (2.5), NBuilder, both are optional as the test below can be easily adapted.

The scenario goes like this: you have a base class called BaseTransaction with derived classes DebitTransaction and CreditTransaction. Often where there are many properties from the base class to map, it's redundant to write and tedious. This bit of reflection below iterates through each property of the base class and maps it to a new object that it creates and returns this object.

The following unit test shows the usage of this function, as well as outputs to the console showing that the bases members were in fact mapped. Each derived class has unique properties of the same name (TransactionId), neither of these were mapped - otherwise an exception would have been thrown during the reflection code (prop.SetValue...).

DRY is dead, long live MOISTURE

DRY has become a big buzzword these days that puts emphasis on reusability. While there are some advantages to reuse, I'm going to look at the downside; having DRY applications which are rigid crack over time due to the lack of Moisture.

What is Moisture? It is the syntactic sugar that makes procedural languages like JScript, VBScript, FoxPro and T-SQL powerful and fast. Unless you've been hiding in a cave, you have started migrating from an ORM (such as NHibernate) to more future-proof constructs like Stored Procedures or DataSets.

In the past, the only downside to Stored Procedures was that Refactoring them took a lot of effort. However, JetBrains has recently announced ReProcedural to which lets you refactor code written in VBScript, Microsoft JScript or T-SQL

Once you have moved all of your business logic to stored procedures, just plan on having an average of 4 stored procedures per table (for insert, update, delete and select). In a medium sized system with 50 tables, it's completely acceptable to have an upwards of 200 stored procedures or more. At this point, your team should have enough T-SQL work to justify having a DBA letting you focus on increasing system Moisture with procedural programming

Finally, you will want to rewrite any aspects (AOP) as table triggers. For non-DBAs out there, triggers are essentially AOP for databases. For instance, if you wanted to implement logging your pointcut will either be your Stored Procedure or your Trigger.

Remember the basics of Moisture: the more OO code you can migrate to a procedural language, the better. While you can do procedural programming in C# or Java, it's not something enforceable as there is nothing stopping some n00b developer from creating an Interface or an Abstract Class. As a general rule, all methods should be public and static

April Fools!!! :-)

Utility function to facilitate Domain AddChild functions

As I make certain domain models more rich, one of the first things I will do is make the property of Child lists on the target domain model to a setter that is internal or public:

There's nothing wrong with this code, it's short & concise. My only problem with it is that there is a repeatable pattern here, we are always going to check to see if the child is null, we will always need to check for the nullability of the target list, etc, etc. If we could centralize this pattern, then if it changes we could change it there too. The silver lining being that if we can reduce it to one line of code and that is always a good thing :-).

Utility Function for Adding Child to Parent: Usage:

It works pretty well and I've ran unit tests against it for both generic lists and non-generic lists. I first started off thinking I could do this with delegates, but I concluded that this code was not a proper use of delegates. Feel free to sound off if I've gone completely mad or if there is a better way to do this.

Unit Testing Daos with NHibernate with SessionScopes Version 2

In a previous post I outlined how to modify Ayende's post to support contextual sessions. With Contextual Sessions in NHibernate instead of injecting a Session into each DAO you will be injecting a SessionFactory in which the caller will invoke the SessionFactory's GetCurrentSession() in order to get the session tied to the context. The previous example I mocked the SessionFactory and stubbed the GetCurrentSession() to return one session that would have been open for the life of a TestFixture.

This really isn't necessary if you bind the SessionFactory to a context. This is very easy with NHibernate and the only requirement is that you tell NHibernate through it's configuration the scope of your session context.

Something else I've thought about was that each TestFixture should only every test one DAO. The tests in said fixture should also only ever reference one DAO to be an independent test. Therefore if you are testing and a function from your DAO and need another object from persistence it would be better to call get the persisted object directly from your Session than from a separate DAO. Too often I see people trying to reuse objects in their Unit Tests which violates the integrity of the tests because they would no longer be independent.

Therefore it would be nice if the InMemoryDatabaseTest exposed the target DAO to the TestFixture to make it easier, it could also set the SessionFactory of the DAO. We can do this easily with Generics:

I have extended my existing base test fixture InMemoryDatabaseTest so that I don't break compatability with existing tests. All my new DAO TestFixtures will inherit from the new Generic version. I have also added some overloads for debugging. If you pass a true debug flag to the constructor it will output the SQL to the output Window. Also you can pass in a path to an actual SQLite file/db which will let you save the changes. This is helpful for complicated tests where you want to see what is being saved to the database and test the queries NHibernate is executing against SQLite.

BaseDao that all your DAOs inherit from to facilitate contextual sessions. This code should be in a separate assembly I call (rootnamespace).Data.Common InMemoryDatabaseTest that your test fixtures would inherit from. This code should be in a separate assmebly I call (rootnamespace).Testing.Common Usage

As you can see, the DAOs Unit Test didn't have to instantiate an instance of the target DAO since it already specified it as a Generic paramter. While this only eliminates 2 lines of code it more importantly enforces one DAO per test.

Mapping Date & Time fields With NHibernate

Let's say you have an entity or POCO that you have mapped from NHibernate (or any ORM) and the database has separated out the Date & Time values into separate fields.  Your best best is to map these Date & Time fields into properties (DateTime for Date and TimeSpan for Time).  Then create a helper property in your POCO to add them together.  I'd like to add that I'm not a fan of separating these sorts of things in the database, but some people do this for some reason:

HBM:


POCO

In my case either of these could be null (yes another great idea) which means I had to handle the nullability however this illustrates at least in worse case scenerio what will happen.  Date & Time data types are available in SQL Server 2008 and work with NHibernate 2.1 with .Net 2.0 or above.

Associating Users & Logins in SQL Server after Database Restore

Often times when you restore a database in SQL Server from one server to the next the Logins will become disassociated with the User a specific database.  We ran into this today and another software engineer found a good script from a guy he knows:

Executing this script should find unassociated logins and reassociate them with the users in the current database

CI Done Simple with CruiseControl.Net + MSBuild

If you want to setup Continuous Integration the learning curve for automated builds can be moderate for some. CruiseControl.Net (CCNet) allows you to integrate with automated build technologies such as NAnt, MSBuild, etc.  The advantage of this is that you can specify the Visual Studio Solution so that MSBuild knows the references and source code to build.

This example assumes using TFS for source code control, which definitely isn't my favorite SCM tool but odds are if you want to keep it simple and you're not using NAnt then you're probably in a shop that uses TFS.

Alt.Net Google Reader Bundle

Google Reader is a great way to subscribe to different RSS feeds because it enables certain social networking features on top of them.  If you are "Sharing" with other users then you will see what other users in your network liked and their comments.  It also makes it very easy to send links to people via email.

I created an ALT.Net Google Reader bundles a while back that I try to keep updated with different ALT.Net blogs that I subscribe to.  To subscribe to this bundle click the link below and then click the link "Subscribe".

http://www.google.com/reader/bundle/user/03066432769507324653/bundle/Alt.Net

You can expand the feeds to see what you are subscribing to and even remove certain feeds after you add the bundle.  If you have an ALT.Net blog and would like your blog added to this bundle just send me a message on Twitter or leave a comment here.

Practical use for NUNit 2.5's [TestCase]

Since NUnit 2.5, NUnit has supported a concept of Test Cases.  Briefly a test case to NUnit is a test which runs with a different set of parameters and can expect a different set of results.  This has the potential to minimize the amount of code required to write new test methods.

To this point I've been using standard [Test] attributes and since seeing this attribute in the documentation I've been thinking about uses for it.  Now that I've started using [TestCase] I've thought of some other uses for it cutting my test fixtures down to 1/2 or less the size previously.

Below is an simple example of the code without the [TestCase] using the traditional [Test] attribute:


The above code can be trimmed down to one function using the [TestCase] attribute:



The other beautiful thing about [TestCase]s is that it collapses each test case underneath a node which actually looks cleaner:

A couple of notes on the code above.  The compiler (C# here) will not allow you to use object initializers as a parameter to the [TestCase] so you cannot create a test function Validate(object myUser) and do something like below.

This is because the compiler will only allow constants in attributes, however if you really need something like this, NUnit allows a work around. This is documented here.

Houston TechFest Samples

Houston TechFest was a lot of fun, I attended some very interesting sessions and had the opportunity to present on the topic of NHibernate.  I have uploaded the samples and they are downloadable by clicking here.  The presentation is available here.

Unit Testing - Mocking to test Edge Cases with NHibernate

Sometimes in code you want to test edge cases, some of these can be difficult to test even with integration tests because of database constraints, etc.  This may be a business key or unique identifier (that's not a primary key)- may be enforced or not.  The key is you make an assumption that in code you want to test for.  Mocking dependencies is the key here, to create behavior that would not otherwise be possible.

Unlike the pattern illustrated by Ayende or that I added onto here, I wanted NHibernate's SessionFactory and Session objects to return data that I could not return from the database because of unique index constraints.

In this scenerio I'm returning data from the database that matches certain values and it should always return a list that contains either 0 or 1 objects otherwise it throws an exception:

Problem is that integration tests are unlikely to uncover this error with normal data and end user testing won't uncover it either.  This is simple, but I want to make certain that the exception is correctly thrown.

The only tricky part really is that after mocking the ISessionFactory & ISession objects you need to also mock each ICriteria object returned from the Session object.  So with Rhino Mocks after telling it to expect a call to CreateCriteria that returns an ICriteria, we also need to create expectations for this result calling Add and its result calling list.  This is because fluent interfaces use method chaining which makes this part a little tedious:

This allows us to now test what would actually happen if more than one Animal objects were returned.  NHibernate makes this easy because there are interfaces for pretty much every object.

FYI: this code uses Rhino Mocks, NBuilder, NUnit & NHibernate

NHibernate, Spring.Net & Dependency Injection

Inverson of Control (IoC) is a very powerful concept. The basic premise of IoC is to invert elements of your programming paradigm for flexibility and extensibility. Most procedural or OO code the linkages are hard code. Most data access code, take DAO for instance, need a handle to a connection object. Fortunately if you are using a good persistence framework like NHibernate you don't have to directly deal with the ADO Connection object as it handles that for your, however you need to efficiently manage an NHibernate Session.

How to do so is very important in ASP.Net applciations as you may have dozens of request per second and if you handle this poorly your application performance will suffer. Handle it well and you will often have better performance than straight ADO.Net applications.

Let's take two simple application layers UI and Data Layer. Our data layer contains our DAOs (data access objects) which perform direct interaction with our database and of course our UI contains all necessary user interface related code.

UI Code

The public setter that we declare here exists for dependency injection (DI), this will allow Spring.Net to set (or inject) our dependencies for us. We configure Spring to set this pages dependencies in our configuration file like the following:

This section is telling Spring that the page (Applications/Default.aspx) has a property named GenericAppSectionDao which needs to be set to a reference of an object named GenericAppSectionDao

At your applications first run (first request for a website) Spring will create all of these objects in memory for you and set them up (unless you configure them differently of course). This requires an upstart cost but saves performance with each request after the first.

Next we need to tell Spring how to create this object GenericAppSectionDao:

The first object element creates an abstract object so that Spring knows to create before the objects that are dependent on it. Next we tell Spring to create an instance of a generic class called Dao that provides basic Dao functions and we tell Spring that it's dependent upon BaseDao (again so that Spring knows to create this object after it creates its parent). The generic Dao class looks like the following:

Lastly is BaseDao which provides a public setter to set the SessionFactory with a public Getter to get the current session. This enables SessionScopes which are a good idea for web apps. BaseDao code is below

You could obviously perform the same exact methods with any IoC framework (Castle or anything else). The only difference should be the XML files. Dependency Injection (DI) is a form of IoC and reinforces best practices for writing proper unit tests because you can isolate each layer you are testing and mock its dependencies. It also facilitates AOP so you can do all sorts of stuff (transactions, logging, etc) between application layers automatically.

Working Around DLL Hell in .Net

Assembly Bindings with different Public Key Tokens

There was a little fiasco started when log4net accidentally generated a new public key token for log4net from version 1.2.9.0 to 1.2.10.0.  This became evident to me when I tried to do an assembly redirect in the .config file for NAnt so that it would use the newer version of log4net.  You get the public key token from any .Net assembly by executing the following command on it:

If you perforrm this against log4net 1.2.9 & 1.2.10 you will get b32731d11ce58905 & 1b44e1d426115821.  Therefore if you are executing a custom task that requires log4net (or who's dependencies require log4net) .Net will not let you redirect the two version because as far as Microsoft is concerend, they are not two different version of the same thing, they are different assemblies altogether.  However since they are different assemblies technically the work around is to rename one of the new assembly (1.2.10 in this scenerio) filename to log4net-1.2.10.dll.  Next in the NAnt.exe.config add the following within the <configuration> element

This will force .Net to load the new assembly alongside the old one thus avoiding any compatibility issues, bypassing DLL hell for good.