For some of you who have been using Nhibernate for a while, may found this old news, but I thought this was coolest thing ever (at least this week).

I am working with a legacy database that is,.. unpleasant (yeah we'll go with that).  I'm adding a new feature that is using a table with the following schema.

CREATE TABLE [dbo].[icpric](
...
           [begqty1] [decimal](15, 5) NULL CONSTRAINT [df_icpric_BEGQTY1]  DEFAULT ((0)),

            [endqty1] [decimal](15, 5) NULL CONSTRAINT [df_icpric_ENDQTY1]  DEFAULT ((0)),

            [factor1] [decimal](15, 5) NULL CONSTRAINT [df_icpric_FACTOR1]  DEFAULT ((0)),

            [unitpr1] [decimal](15, 5) NULL CONSTRAINT [df_icpric_UNITPR1]  DEFAULT ((0)),

            [begqty2] [decimal](15, 5) NULL CONSTRAINT [df_icpric_BEGQTY2]  DEFAULT ((0)),

            [endqty2] [decimal](15, 5) NULL CONSTRAINT [df_icpric_ENDQTY2]  DEFAULT ((0)),

            [factor2] [decimal](15, 5) NULL CONSTRAINT [df_icpric_FACTOR2]  DEFAULT ((0)),

            [unitpr2] [decimal](15, 5) NULL CONSTRAINT [df_icpric_UNITPR2]  DEFAULT ((0)),

            [begqty3] [decimal](15, 5) NULL CONSTRAINT [df_icpric_BEGQTY3]  DEFAULT ((0)),

            [endqty3] [decimal](15, 5) NULL CONSTRAINT [df_icpric_ENDQTY3]  DEFAULT ((0)),

            [factor3] [decimal](15, 5) NULL CONSTRAINT [df_icpric_FACTOR3]  DEFAULT ((0)),

            [unitpr3] [decimal](15, 5) NULL CONSTRAINT [df_icpric_UNITPR3]  DEFAULT ((0)),

...

This is really not that uncommon in legacy apps and it really does not lend it self to a understandable domain.  Essentially  this is a price bracketing scheme in one table.  I wanted to map it to the following domain model, with a collection of price brackets.

public class PricingSchedule
{
    private int _id;
    private string _itemCode;
    private string _popt;
    private string _description;
    private string _method;
    private string _source;
    private string _group;
    private IEnumerable<PricingScheduleBracket> _priceBrackets;

}

I wasn't sure how I was going to do this, so I did some research to see if anything had been before, or what might work.  I finally decided I would give a Custom User Type a try.  I created a mapping file that used a custom type and passed in the columns I needed to convert to a list.

<property name="PriceBrackets" type="TRACS.Repositories.Impl.PriceBracketUserType, TRACS">
            <column name="begqty1"/>
            <column name="endqty1"/>
            <column name="factor1"/>
            <column name="unitpr1"/>
            <column name="begqty2"/>

</property>

I then created a class that implemented Nhibernates IUserType.  Here are the important methods to make this work.

Specify that the return type is IEnumerable<PricingScheduleBracket>

public Type ReturnedType
{
    get { return typeof(IEnumerable<PricingScheduleBracket>); }
}

public SqlType[] SqlTypes
{
    get { return new []
        {
            new NHibernate.SqlTypes.SqlType(DbType.Decimal),
            new NHibernate.SqlTypes.SqlType(DbType.Decimal),
            new NHibernate.SqlTypes.SqlType(DbType.Decimal),
            new NHibernate.SqlTypes.SqlType(DbType.Decimal),
            ...

The real work is done in the NullSaveGet method. this gives you the datareader pulling back the data and an array strings with the names of the column aliases for the columns specified in mapping file.  You can take these fields and transform them any way you want.  Don't forget to account for possible null values.

public object NullSafeGet(IDataReader rs, string[] names, object owner)
{
    List<PricingScheduleBracket> brackets = new List<PricingScheduleBracket>();
    brackets.Add(new PricingScheduleBracket(getValue(rs[names[0]]), 
                                            getValue(rs[names[1]]), 
                                            getValue(rs[names[2]]), 
                                            getValue(rs[names[3]])));

    brackets.Add(new PricingScheduleBracket(getValue(rs[names[4]]),
                                            getValue(rs[names[5]]),
                                            getValue(rs[names]),
                                            getValue(rs[names[7]])));
    ...

return brackets;

There is a corresponding NullSaveSet to set the values.  I am dealing with read-only values, so I left it empty.

Using techniques like this, you can use Nhibernate to effectively transforms even the most dificult database schemas into a domain that is coherent and truly models the reality it is trying to represent.

I love it when I find new ways to improve my testing ability.  In this case, it's not really new, just new to me.  I'm referring The Object Mother or Test Data Builder patterns used to encapsulate objects you need for testing.  I started playing with these patterns to simplify my tests and I found a way to further reduce the noise in my tests.

The basic concepts of these concept of these patterns is to put object populated with what you need behind simple factory methods to give you back the objects.  Test Builders can be more complicated, perhaps using a fluent interface to define the object exactly as you need for particular test.  The complexity for most of my tests fell somewhere between these too approaches.  The factory methods didn't give me enough flexibility and most of my objects were not complex enough to warrant a full fluent interfaces.

Most of my tests seem to follow this pattern, where I define variables to hold my expected values, assign these values to the objects I need to test and then run my assertions against these expected values.

And then do my tests:

private string _expectedName = "name";
private string _expectedPhone = "phone";
private string _expectedPlus4 = "plus 4";
private string _expectedStateAbbrev = "state";
private string _expectedZip = "zip";

...
[Test]
public void should_populate_the_work_order_table_to_the_work_order_dto()
{
    
    WorkOrderMapper mapper = new WorkOrderMapper();
    DataSet workOrderDataSet = SetUpWorkOrderDataSet();
    var dto = mapper.MapFrom(workOrderDataSet);
    Assert.That(dto.CompanyName, Is.EqualTo(_expectedCompanyName));
    Assert.That(dto.Phone, Is.EqualTo(_expectedPhone));
    Assert.That(dto.StateAbbrev, Is.EqualTo(_expectedStateAbbrev));
    Assert.That(dto.ZipCode, Is.EqualTo(_expectedZip));
}

So I once I started exploring the Object Mother pattern, I realized that I could encapsulate not only the data I need for my objects, but also my expectation variables as well.  So I created TestData objects, where I declared the expected values and populated the objects with those values.  After a couple of different approaches, these test data classes started to look like this.

public class CustomerTestData
{
    public CustomerTestData()
        : this(null)
    {
    }

public ExpectationData Expectations { get;set;} 

public Customer Item{get;set;} 
    public class ExpectationData
    {
        public int Id = 0;
        public string CustNo = "CustNo";
        public string Company = "Company";
        public double Tax = 50;
        public double Discount = 10;
        public string GlLink = "gl";
        public bool IsTaxExempt = true;
        ...
        public ExpectationData()
        {
        }
   }
}

I could then use the Test Data Objects in my test like this:

[Test] 
public void should_sum_all_line_item_prices_times_quantity()
{
    var salesOrder = TestingData.GetSalesOrderTestData().SalesOrder;
    
    var actualTotal = salesOrder.GetOrderTotal();
    Assert.That(actualTotal, Is.EqualTo(50m));
    
}

Variability and Keeping Test Readable

There are two issues with this approach.  The first one you probably noticed right away.  There's no way the same data can be used to satisfy all of your tests.  What if I have tests that need a null value or an invalid value?  Having the Expectations pre-defined reduce their usability to only positive tests.  The other issue is a little more subtle, but this approach reduces the readability of my test.  Now when someone wants to know what my tests are doing they have to look in two places, the test itself and the TestData objects.  The reduces their overall usefulness in describing the behavior of the system and it's just plain annoying.

So what we need is the ability to define the values that are important to the test, but also create the objects in a valid state with default values unrelated to the test at hand.  We can do this with an Action<T> delegate.  Lets create the TestData with an Action<CustomerExpectations> delegate:

public CustomerTestData(Action<CustomerTestData.ExpectationData> overrideDefaultExpecations)
{
    Expectations = new CustomertTestData.ExpectationData();
    Item = Expectations.SetExpectionsOn(overrideDefaultExpecations);
}

Since delegates are first class citizens in .Net, we can pass that function around and execute when we need it.  Let's create a method in ExpectationData class the creates our Customer object.  Now we'll use the delegate to change the expected values.  This will change the value of the expectations before we set the values on the Customer object.

public Customer SetExpectionsOn(Action<CustomerTestData.ExpectationData> setExpectations)
{
    if (setExpectations != null)
    {
        setExpectations(this);
    }
    ArCust item = new ArCust();
    item.Id = Id;
    item.Company = Company;
    ...
    return item;

}

Now are our test looks like this:

[Test] public void should_sum_all_line_item_prices_times_quantity()
{
      var salesOrder = TestingData.GetSalesOrderTestData(e => {
                                                                                                  e.LineItem.Price = 10m;
                                                                                                  e.LineItem.Price = 5m;
                                                                                                 }).SalesOrder;
      var actualTotal = salesOrder.GetOrderTotal();
     Assert.That(actualTotal, Is.EqualTo(50m));
}

Now we can set the values for the parameters we are interested in, keeping our test objects in a valid state and maintaining the readability needed to understand the test without needing to refer to other object.

Conclusion

I'm still tweaking the syntax, but so far it has really cleaned up some of my tests.  However, it can fall apart if you have a complicated setup process.  Some of my tests require the same data in multiple objects, so that that they all  match when my service is executed.  Using the delegates to wire up 3 different objects in the setup became very difficult to read.  So I switched to the Builder pattern (and some refactoring) to clean up the process.  In other cases I needed a quick method to populate all the fields, so I wrapped it up in a factory method.  It is very easy to combine this approach with Builders and Factory Methods to give you as much control as you need over your test data.

I started a new project at a client site this week.  I spent the first couple days on Iteration 0 tasks.  These are things you need in place before you can actually get to work.  Here are a few things we needed done.

Source Control

You absolutely must have some sort of source control.  My client happens to be a team of 1, so he wasn't using any source control.  We set up a subversion repository and the necessary folder structure for the current projects we are working on.

Build Scripts

I absolutely hate writing build scripts, but I love executing them.  This is just one of those things you've got to suck up and do right at the beginning.  You will be executing several times every day when you are working on stories and tasks, so take some time to get them right.  For this project, the build scripts were not too complicated. They simply compile the projects and run the unit tests.  Normally I would drop and recreate any database that would be used too.  In this case, we're accessing an existing database, but we are not working on that part yet, so I left it out for now.

Continuous Integration

We also set up the CI server.  While I really want to try out TeamCity (I tried once with no luck), I stuck with CruiseControl.net.  CCNet can be difficult to get right the first time, but again once you get it you can usually forget about it.

We also did some story writing too.  I don't consider this an Iteration 0 tasks, but is obviously important to have some stories and scenarios ready to go.

What are some of the the Iteration 0 tasks you do before starting a project?

I've been testing my code for a long time.  I finally got on the TDD / BDD bandwagon a year ago and haven't looked back.  But as much as I believe that testing is important, and I would never write professional code without an extensive suite of unit tests, I still find myself writing code at home without tests.  The reality is that it takes discipline to keep a test driven approach to software development on track.  When talking about a company that follows these practices and has the normal turnover of staff, it become even more important to have a culture that embraces, encourages and, when necessary, enforce quality at all stages of development.

So how do you create this culture of quality?  It doesn't happen overnight and it will definitely doesn't happen on it's own.  You're entire team has to work toward creating the culture that embraces it at every step.

Make it Easy

It takes a great deal of work to incorporate quality from the beginning of the project.  Don't make it any harder than it needs to be.  An automated build process is extremely important.  You need to be able to be able to "push a button" and compile and run all unit test for your entire application.  There are a lot productivity tools help with this too.  In the .Net world, Resharper should be a required tool in your toolbox.  The refactoring and navigation enhancement it provides make it possible to take a continuous design approach to your application.  Integrated source control and testing tools are also important.  It needs to be simple and easy to run a single or all unit tests, and if you can do that from within your IDE you are off to the races.

Code Coverage

Having a high level code coverage percentage is one way to ensure that you have quality in your process.  High coverage by itself is not an accurate measure of quality and 100% coverage is not going to guarantee it.  However it is low hanging fruit, and it can give you a level of comfort when it's time to refactor to a better design that you will not break existing functionality.

Continuous Integration

Continuous integration is the best tool you can use to help create culture that expects quality.  In a CI process, you can set the build to fail if any of your test fails, or if you fall below your test coverage threshold.  This gives the team immediate feedback when something goes wrong and can be fixed immediately. 

Don't Leave a Build Broken!!!

Even if you have a CI process in place that runs all your tests and measures your code coverage, if you allow the build to stay broken, all of your work is for nothing.  At the same time, breaking a build should not be a criminal offense. You want your team  members to commit their changes frequently.  When they do this it's okay to have a build fail.  You don't want developer to be overly cautious when committing, fearing a broken build.  What you don't want is to let a build stay broken.  If you leave a build broken for a long period of time, it is a symptom of apathy about keeping the code base at a  high level of quality. 

You should also never commit changes to a broken build.  You don't know what impact your changes will have on a systems that is not passing all of it's tests.  Also remember that the team has ownership of the code.  Anyone can fix the build (that includes you), it doesn't have the person who broke the test.

There are lots of ways to enforce this.  The easiest way is that tools like CruiseControl and TeamCity (I think) let you attache sounds to build events.  One thing Jeffrey Palermo does is to have everyone on the team choose a sound for build success and failure.  This gives the team positive and negative feedback to the build process.

Many people hook up a red strobe light to the build system.  That way it is glaringly obvious to the team that something is wrong.  A variation of this using a lava lamp and the goal is to fix the build before it starts bubbling. 

The danger here is that you don't want your team to fear committing frequently.  Life becomes much harder if people leave lots of code modified while they are working on a story or task.  As I said, it's okay to break the build, just don't leave it broke.

Bugs Are Blocking Issues

When working on a new project and you're got all of these story cards for new features, it is not much fun to work on bugs.  But it is essential that when bugs are found during the development phase that they are placed on the board as blocking issues.  If there are any reported bugs on your task board, you finish those before starting a new story.

These are just a few techniques you can do to instill a culture of quality in your organization.  I'm sure there are more.  What do you do to create a culture that values quality?

Some comments to a recent post on Jeremy Miller's blog raised the question of whether NHibernate's lazy loading capabilities violate Domain Driven Design.  While that conversation was centered around bypassing repositories for access data, which is not true since your aggregate roots are your repository source.  But there is another aspect that was not discussed.

Evans discusses that client code does not need to know about the repository implementation, but developers do.¹

Let's look at a simple example, suppose you have an Order object with a list of LineItems as a property. The source code is deceptively simple.

   1: Order order = orderRepository.GetById(1);

   2: foreach(LineItems item in order.LineItems)

   3: {

   4:     //do something fancy here

   5: }

Using NHibernate's lazy loading, the LineItems property on an Order instance will not be populated until it is first called.  When it is accessed, a database call will be made to populate the LineItems collection.  The first time I saw this, I was floored.  "That is sooo cool", Then I started thinking about it.  That lazy load call could be very expensive and if the person maintaining the code after I'm gone doesn't know that the property accessor results in a potentially expensive database call, how can they make the proper decision on when that collection should be used?

This functionality obviously satisfies Evans first clause, but to me it violates the second part.  Developer's need to know when expensive operations occurs, and hiding that operation behind a property accessor obscures that possibility. Now it has been argued that the real problem is that the property syntax is the real problem². And I can agree with that, however the cat is out of the bag on that one.

The title of this blog post is a question to the community.  What are your thoughts? Do you think that using a getter method better describes to the developer that something more than an instance variable is being accessed?  Or are you okay with the property syntax?

1.  Evans, Domain Driven Design, p. 154

2.  Richter, CLR via C#, p.217

My blog post on using ActiveRecordMediator to use the Repository pattern with ActiveRecord was discussed on Castle's Forums.  A good question was raised in that forum, and other people that I talked to about using the Mediator class: "Why use this instead of NHibernate directly"

As mentioned in the original blog, I am not a NHibernate Jedi yet.  We use it on some projects at work, but for the most part, setup and configuration was already done for me.  Using ActiveRecord took care of setup and configuration for me.  If you're familiar enough with NHibernate, then this probably isn't much a gain for you, but it was for me.

If you don't need any of the advanced features of NHiberate and have simple queries, then using Mediator is a quick way to get going quickly.  When you do need more control over Nhibernate, moving off of the ActiveRecordMediator for your Repository implementation should be quick and painless.  So in that respect, prototyping with Mediator class has a definite advantage.

Hope This Helps,

John

This is a Re-Post from my older blog at geekswithblogs.

Castle’s ActiveRecord frame work is an easy way to get introduced to NHibernate if you’re not familiar with setting up and using NHibernate (which I’m not). However many people are not fond of the ActiveRecord pattern. It can be a leaky abstraction, putting persistence related functions on your domain model is not a very clean separation of concerns for many people. I tend to agree with this. It really does depend on the complexity of your application.

When learning about AR I read a lot of blog entries or the documentation, people elude to how you can use AR API in a repository fashion, but I could find very few examples of how to uses.

It turns out there is an innocuous object within the API call ActiveRecordMediator<T>. This little guy has all of the persitance related methods you normally call directly on your ActiveRecord object. With this object you can use a Repository style DAL. Here is my simple BaseRepository that I inherit from to take advantage of ActiveRecordMediator. You can extend this further of course, but it’s all I need at the moment.

public class BaseRepository<T> : IRepository<T> where T :class 
    {
        protected ActiveRecordMediator<T> mediator;

        public virtual void Save(T item)
        {
            ActiveRecordMediator<T>.Save(item);
            
        }
        public virtual T FindById(object id)
        {
            return ActiveRecordMediator<T>.FindByPrimaryKey(id);
        }
        public virtual T FindOne(params ICriterion[] criteria)
        {
            return ActiveRecordMediator<T>.FindOne(criteria);
        }

       public virtual T[] FindAll()
        {
            return ActiveRecordMediator<T>.FindAll();
        }

        public virtual int Count()
        {
            return ActiveRecordMediator<T>.Count();
        }
       
    }
}