Frederik Gheysels' DevLog

WinForms: DataBinding on a cancellable Dialog Form

2009-06-19T10:18:00.002+02:00

On some occasions, you might want to create a dialog window that enables a user to modify data.

In almost all situations, you will want to make use of the databinding capabilities in the .NET Framework, so that you do not have to write the tedious synchronization-code yourself.

However, when you want to databind a custom object to the controls on the dialog-form, databinding might get in the way:
When you change the Text in a TextBox that is databound on a property of your object, the property of your object will be updated as soon as the databound TextBox has been validated (default behaviour).
This is not a problem, until the user decides that he does not want to keep the changes he has made, and clicks the Cancel button of the dialog form.
In such a case, you want to revert back to the original state of the object.

There are several solutions to handle this problem.

One solution is to implement some kind of Undo-behaviour in your custom object, but this might be a little bit overkill for the situation at hand.

A more simple solution, is to disable the 2-way databinding when the form is displayed, and explicitly update the databound object when the user clicks the Ok button of the dialog.

This can be done like this:

public class MyEditForm : Form
{
    public MyEditForm( MyClass objectToDisplay )
    {
        // Suppose that you have defined databindings via the
        // designer
        this.MyBindingSource.DataSource = objectToDisplay;

        DataBindingUtils.SuspendTwoWayBinding(this.BindingContext[MyBindingSource]);
    }

    public void btnOk_Click( object sender, EventArgs e )
    {
        DataBindingUtils.UpdateDataBoundObject(this.BindingContext[MyBindingSource]);
        this.DialogResult = DialogResult.Ok;
    }

    public void btnCancel_Click( object sender, EventArgs e )
    {
        this.DialogResult = DialogResult.Cancel;
    }
}

The concept is very simple; when the form is displayed, we suspend the databindings, so that changes that are made to the controls on the form, are not directly persisted in the underlying object.
When the user confirms the changes he has made by clicking the OK-button, we need to make sure that the contents of the controls are persisted in the underlying object.

The two methods that are of interest look like this:

public static class DataBindingUtils
{
    public static void SuspendTwoWayBinding( BindingManagerBase bindingManager )
    {
        if( bindingManager == null )
        {
           throw new ArgumentNullException ("bindingManager");
        }

        foreach( Binding b in bindingManager.Bindings )
        {
            b.DataSourceUpdateMode = DataSourceUpdateMode.Never;
        }
    }

    public static void UpdateDataBoundObject( BindingManagerBase bindingManager )
    {
        if( bindingManager == null )
        {
           throw new ArgumentNullException ("bindingManager");
        }

        foreach( Binding b in bindingManager.Bindings )
        {
            b.WriteValue ();
        }
    }
}

Forcing NHibernate to cascade deletes before updates

2009-05-15T11:49:00.004+02:00

At work, I've ran into a particular problem; let me describe the situation at hand.

Suppose I have the following DB schema:

In the OrderLines table, there exists a UNIQUE CONSTRAINT on ( OrderId, SequenceNumber)

Next to this DB schema, I have an Order and an OrderLine class.
The Order class has a collection of OrderLines:


public class Order
{
    public int Id
    {
       get;
       private set;
    }

    public ISet OrderLines = new HashedSet();

    public void AddOrderLine( OrderLine ol )
    {
       ol.Order = this;
       OrderLines.Add (ol);
    }
}

I've them mapped using NHibernate so that I can save them in the above DB schema.
In the mapping, I've specified that the OrderLines collection should be cascaded when the Order is saved:


<set name="OrderLines" cascade="all-delete-orphan">
   <key column="OrderId" />
   <one-to-many class="OrderLine" />
</set>

Now, all goes well until you remove an OrderLine, add a new OrderLine with the same sequencenumber as the one that you've just removed.

Instead of first removing the OrderLine that you want to remove, and inserting the new OrderLine afterwards, NHibernate will perform these actions just the other way around:

It will first try to insert the new OrderLine, and then it will remove the existing Orderline.
Now, since we have a unique constraint in the DB, this will fail offcourse.

I've found a way to work around this problem. Although I find it not optimal (rather an ugly hack), it kinda works, so I'll stick with it for now.
This is how I've done it:

Instead of specifying 'all-delete-orphan' as the cascade option for the collection, I've modified it to 'delete-orphan' instead.
This means that deletes will be cascaded, but inserts & updates are not

All DB access goes through 'repositories' in my application. This means I have an OrderRepository which has a Save method.
I have modified my Save method so it looks like this:
```
public void Save( Order o )
{
    // With.Transaction only starts a transaction when the given session
    // is not in a transaction yet.
    // session is an ISession and is a member variable of my Repository.
    With.Transaction (session, new delegate()
    {
       session.SaveOrUpdate (o);

       session.Flush();

       foreach( OrderLine ol in o.OrderLines )  
       {
          session.SaveOrUpdate (ol);
       }
    };
}
```
What I do here, is just calling SaveOrUpdate on the given Order. Because of the cascading setting, only the OrderLines that are to be deleted, will be cascaded.
Afterwards, I call the Flush method of the session to make sure that the DELETE statements are actually send to the database.

We're now left with the OrderLine entities that are new or modified. To make sure that they get persisted as well, I loop over the OrderLines collection and call SaveOrUpdate for every OrderLine instance.
This will make sure that new OrderLines get inserted and modified ones, are updated.
NHibernate will not update those OrderLines that are not changed.

Although this 'hack' is nicely hidden / abstracted by the Repository, I still find it a bit ugly, but at this very moment I see no better way to handle this kind of issue ...

Google Chrome

2008-09-02T21:42:00.002+02:00

The beta-version of Google's Chrome browser is available for download. I've just installed it, and I like it.
I love their new 'start-page' concept, for instance.

They've also created a comic where they explain the concepts and techniques of Chrome. Very interesting as well. :)

On reading books ....

2008-08-25T21:23:00.004+02:00

Davy Brion has made a statement on his blogs in where he states that reading certain development books should be considered as an investment for a software developer.

I fully support that statement.
I have a few books on my shelf that I consider as 'my Software Development Bibles'. These books have -imho- sharpened my skills, broadened my view and helped me to be a better developer.
These books -which I consider to be my bibles- are, in no particular order:

Domain Driven Design: Tackling Complexity in the Heart of Software

Design Patterns: Elements of Reusable Object-Oriented Software

Patters of Enterprise Application Architecture

Refactoring: Improving the design of existing code

Design Patterns Explained

Agile Software Development

There are lots of other books on software development on my shelf, but I consider the ones above as the ones that have influenced me most.
Books, you can't get enough of them (you still have to read them as well offcourse). There are still some books regarding software-development on my whishlist, and I'm sure that every now and then, another book will be added to it...

Locking system with aspect oriented programming

2008-08-19T21:14:00.014+02:00

Intro

A few months ago, I had to implement a 'locking system' at work.
I will not elaborate to much on this system, but it's intention is that users can prevent that certain properties of certain entities are updated automatically;
The software-system in where I had to implement this functionality, keeps a large database up-to-date by processing and importing lots of data-files that we receive from external sources.
Because of that, in certain circumstances, users want to avoid that data that they've manually changed or corrected, gets overwritten with wrong information next time a file is processed.

The application where I'm talking about, makes heavy use of DataSets and I've been able to create a rather elegant solution for it.
At the same time, I've also been thinking on how I could solve this same problem in a system that is built around POCO's instead of Datasets, and that's what this post will be all about. :)

Enter Aspects

When the idea of implementing such a system first crossed my mind, I already realized that Aspects Oriented Programming could be very helpfull to solve this problem.

A while ago, I already played with Aspect Oriented Programming using Spring.NET.
AOP was very nice and interesing, but I found the runtime-weaving a big drawback. Making use of runtime weaving meant that you could not directly create an instance using it's constructor.

So, instead of:

MyClass c = new MyClass();

you had to instantiate instances via a proxyfactory:

ProxyFactory f = new ProxyFactory (new TestClass());

f.AddAdvice (new MethodInvocationLoggingAdvice());

ITest t = (ITest)f.GetProxy();

I am sure that you agree that this is quite a hassle, just to create a simple instance. (Yes, I know, offcourse you can make abstraction of this by making use of a Factory...).

Recently however, I bumped at an article on Patrick De Boeck's weblog, where he was talking about PostSharp.
PostSharp is an aspect weaver for .NET which weaves at compile-time!
This means that the drawback that I just described when you make use of runtime-weaving has disappeared.
So, I no longer had excuses to start implementing a similar locking system for POCO's.

Bring it on

I like the idea of Test-Driven-Development, so I started out with writing a first simple test:

The advantage of writing your test first, is that you start thinking on how the interface of our class should look like.

This first test tells us that our class should have a Lock and an IsLocked method.
The purpose of the Lock method is to put a 'lock' on a certain property, so that we can avoid that this property is modified at run-time.
The IsLocked method is there to inform us whether a property is locked or not.

To define this contract, I've created an interface ILockable which contains these 2 methods.
In order to get this first test working, I've created an abstract class LockableEntity which inherits from one of my base entity-classes implements this interface.
This LockableEntity class looks like this:

This is not sufficient to get a green bar on my first test, since I still need an AuditablePerson class:

These pieces of code are sufficient to make my first test pass, so I continued with writing a second test:

As you can see, in this test-case I define that it should be possible to unlock a property. Unlocking a property means that the value of that property can be modified by the user at runtime.
To implement this simple functionality, it was sufficient to just add an UnLock method to the LockableEntity class:

Simple, but now, a more challenging feature is coming up.

Now, we can already 'lock' and 'unlock' properties, but there is nothing that really prevents us from changing a locked property.
It's about time to tackle this problem and therefore, I've written the following test:

Running this test obviously gives a red bar, since we haven't implemented any logic yet.
The most simple way to implement this functionality, would be to check in the setter of the Name property whether there exists a lock on this property or not.
If a lock exists, we should not change the value of the property, otherwise we allow the change.
I think that this is a fine opportunity to use aspects.

Creating the Lockable Aspect

As I've mentionned earlier, I have used PostSharp to create the aspects. Once you've downloaded and installed PostSharp, you can create an aspect rather easy.

There is plenty of documentation to be found on the PostSharp site, so I'm not going to elaborate here on the 'getting started' aspect (no pun intended).

Instead, I'll directly dive into the Lockable aspect that I've created.

This is how the definition of the class that defines the aspect looks like:

Perhaps I should first elaborate a bit on how I would like to use this Lockable aspect.

I'd like to be able to decorate the properties of a class that should be 'lockable' with an attribute. Like this:

Decorating a property with the Lockable attribute, means that the user should be able to 'lock' this property. That is, prevent that it gets changed after it has been locked.
To be able to implement this, I've created a class which inherits from the OnMethodInvocationAspect class (which eventually inherits from Attribute).

Why did I choose this class to inherit from?
Well, because there exists no OnPropertyInvocation class or whatsoever.

As you probably know, the getters and setters of a property are actually implemented as get_ and set_ methods, so it is perfectly possible to use the OnMethodInvocationAspect class to add extra 'concerns' to the property.

This extra functionality is written in the OnInvocation method that I've overriden in the LockableAttribute class.

In fact, it does nothing more then checking whether we're in the setter method of the property, and if we are, check whether there exists a lock on the property.
If there exists a lock, we won't allow the property-value to be changed. Otherwise, we just make sure that the implementation of the property itself is called.
The implementation looks like this:

Here, you can see that we use reflection to determine whether we're in the setter-method or in the getter-method of the property; we're only interested if this property is locked if we're about to change the value of the property.

Next, we need to get the name of the property for which we're entering the setter method. This is done via the GetPropertyForSetterMethod method which uses reflection as well to get the PropertyInfo object for the given setter-method.

Once this has been done, I can use the IsLocked method to check whether this property is locked or not.

Note that I haven't checked whether the conversion from eventArgs.Delegate.Target to ILockable has succeeded or not. More on that later ...

When the property is locked, I call the OnAttemptToModifyLockedProperty method (which is declared in ILockable), and which just raises the LockedPropertyChangeAttempt event (also declared in the ILockable interface). By doing so, the programmer can decide what should happen when someone / something attempts to change a locked property. This gives a bit more control to the programmer and is much more flexible then throwing an exception.

When the property is not locked, we let the setter-method execute.

With the creation of this aspect, our third test finally gives a green bar.

Compile time Validation

As I've said a bit earlier, I haven't checked in the OnInvocation method whether the Target really implemented the ILockable interface before I called methods of the ILockable type.

The reason for this , is quite simple: the OnMethodInvocationAspect class has a method CompileTimeValidate which you can override to add compile-time validation logic (hm, obvious).

I made use of this to check whether the types where I've applied the Lockable attribute really are ILockable types:

Note that it should be possible to make this code more concise, but I could not just call method.DeclaringType.GetInterface("ILockable") since that gave a NotImplementedException while compiling. Strange, but true

Now, when I use the Lockable attribute on a type which is not ILockable, I'll get the following compiler errors:

Pretty neat, huh ?
Now, what's left is a way to persist the locks in a datastore, but that will be a story for some other time ...

NHibernate in a remoting / WCF scenario

2008-07-28T21:39:00.003+02:00

I am thinking on how I could use NHibernate in a remoting scenario (using .NET remoting, webservices, WCF ... ), but I can already see some problems which I will likely encounter on my path.

This is how I see the big picture of the application:

Let me explain it in short:
The client application (a rich Windows client for instance) communicates via some kind of technique, be it WCF or the old .NET remoting, with the Service Layer.
This means that the client application calls a (remote) method on the Service Layer to retrieve a Customer for instance. The client can make some changes to that object and later, the client can call the remote 'SaveCustomer' method so that the Service Layer can persist the changes back to the datastore.
In order to do this, the Service Layer uses a Repository that uses NHibernate to retrieve or persist objects.
Note that the Client Application and the Remote service layer use the same Domain Entities. This means that the domain classes need to be [Serializable].

The problem that I will be facing is this:
- Since (N)Hibernate uses its ISession as a UnitOfWork, which keeps track of the objects that have been created, deleted, inserted, the Client Application doesn't know whether it is necessary to perform a remote call to save the entity or not.
(The client application doesn't know anything of some thing called an 'NHibernate Session', and my business object (entity) has no state tracking as well. (In other words: my entity itself doesn't know whether it has been created, changed or deleted).

- The remote method which will save my entity, will use another ISession then the method that has retrieved it. (Remote methods should be stateless, since multiple callers can call the same method. Client x should not know anything of client Y).
The fact that the 'SaveCustomer' method will use another ISession, means that it is possible that NHibernate will perform unnecessary UPDATE statements. This could be problematic if you use an AuditInterceptor, since this Interceptor will update the LastUpdated, Version, etc... columns in the DB, while this was not necessary. In other words: this leads to wrong information in the database.

How could these problems be tackled:
- For the first problem, you could implement some kind of 'state tracking' in your entities, and add a property which tells you whether the entity has modified , etc...

- Implementing state-tracking in your domain entities may also solve the 2nd problem; in your repository you can check whether you've to Update or Save (for new entities) your entity. However, I don't know yet how this will behave in situations where an entity contains a collection of other entities ...

I'd like to know from other people how they have tackled these kind of problems ? Did you implement some kind of state tracking in your business entities ?
Or, did you choose not to expose your business entities to the client application, and use Data Transfer Objects instead ? If so, how did you map these DTO's to your business classes ?

NHibernate IInterceptor: an AuditInterceptor

2008-07-05T20:51:00.007+02:00

As I was playing around with NHibernate today, I came accross a rather inconvenient problem. :).

Let me first explain what I wanted to achieve:
For every domain object that I save, I want to persist in the database when the entity has been created, when it has been last updated and by whom. Nothing special, just regular audit-information.

To make this all possible, I've created the following classes / interfaces:

IAuditable interface
AuditableEntity interface

I think this is pretty straightforward and doesn't require any further explanation.
Then, I continued with creating an NHibernate interceptor which would set the Created and Updated dates. (I could also used the ILifecycle interface instead, but this meant that I would have a dependency to the NHibernate assembly in my 'domain classes assembly', and I don't like that. In fact, the ILifecycle interface has been deprecated for exactly that reason).

This is an extract from my AuditInterceptor which would perform the task I wanted (at least, I thought so ... ).
(Note that my AuditInterceptor is NOT in the same assembly where the IAuditable, AuditableEntity and other domain base class reside in. This would create a dependency from my base classes to NHibernate and again, I hate this :) ).

The AuditInterceptor (snippet):

As you can see, it is very simple: I only had to implement 2 methods of the IInterceptor interface:

OnSave, which is called when an entity is saved for the first time in the database (INSERT)

OnFlushDirty, which is called when an existing entity is dirty and has to be updated

What I do, is check whether the entity that is to be saved implements the IAuditable interface, and if so, I just set the necessary properties (Created and Updated) to the appropriate values (the current DateTime).

Easy enough, simple, understandable and clean... If only this would work...
During testing, I got the following exception:

  ----> System.Data.SqlTypes.SqlTypeException : SqlDateTime overflow. 
Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
   at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object[] fields, 
Boolean[] notNull, SqlCommandInfo sql, Object obj, ISessionImplementor session)

As it turns out, NHibernate doesn't 'see' the changes you make to the entity parameter that is passed to the Interceptor methods:

You can however, change the values that are in the state array parameter. Then NHibernate will correctly persist the changes.

But, I do not like to 'hard-code' property names as strings for obvious reasons (if you change a property, the compiler will not detect that you should change your 'hardcoded property name string', etc...).

Anyway, in order to get my interceptor to work, I have no other choice then messing around with the propertyNames[] and state[] parameters.
In order to get rid of the 'weak-typing', I added a little bit more code.
So, now my classes look like this:

IAuditable interface

AuditableEntity class

AuditInterceptor

This solution is, IMHO, elegant enough to live with, and it works.

However, maybe someone else has a better, more elegant solution for this ? If so, I'd like to hear from you ...

NHibernate Session Management

2008-07-01T22:21:00.005+02:00

I know that there has been written a lot about this topic, but somehow, I haven't found the 'sweet spot' concerning NHibernate Session Management in WinForms applications yet.

Some time ago, I've created a simple abstraction around the NHibernate ISession which would make it easier to use the ISession in my Winforms application.

Why do I want to clutter my presentation layer with NHibernate stuff, you ask ? Because Context is King.
The Repository has no notion of transactions, since the Repository doesn't know the context in where it's used.
Therefore, I like to start my Transaction in my WinForm app for instance, and pass the 'Transaction' to my repository, like this:

In the code above, the UnitOfWork class is just a simple wrapper around the NHibernate ISession which allows me to start and commit or rollback a transaction, disconnect the ISession from the Database, etc... with a minimum amount of code.

The UnitOfWork class looks like this:

This approach also allows me to have multiple NHibernate ISessions opened in one application instance.
This approach also gives me full control about when to start a new UnitOfWork, and when to close a UnitOfWork.

I've been convinced that this was the way to go. Especially because I thought that you had to commit the changes you've made to an object using the same ISession as the ISession which you've used to retrieve the object if you want to avoid unnecessary SELECT statements.

But, thanks to my collegue Thierry (who's starting to use NHibernate as well, and acted as some kind of catalysator to me so that I picked up my NHibernate quest again), it seems that my assumptions where not true:
I thought that, when you save an object to the datastore, using another ISession then the ISession you've used to retrieve the object, NHibernate would first perform a SELECT query in order to find out whether an INSERT or an UPDATE statement should be executed.
This seems to be false if you do not use the 'assigned' generator class for your Id property.

So, now I'm in doubt:

do I really need to be able to have concurrent ISessions in the same application instance ? Until now, I haven't needed it yet (so, yes, that makes it a YAGNI in fact).

I haven't seen anyone on the net using a similar approach. I see that everyone uses some kind of 'SessionManager' like the one Billy McCafferty has written here, so this makes me doubt as well ...

This last point is also the reason for this blogpost: I'm in doubt :)
Using some kind of 'SessionManager' class allows me to do the transaction demarcation where ever I want as well. Next to that, I also do not have to pass my UnitOfWork to the repository, since the repository has access to the current Session via the SessionManager as well ...

I know that, maybe, I should just give it a try. However, I'd like to hear experiences and thoughts of other people who are using (N)Hibernate in a Rich Client environment as well.
How are you dealing with those (session management) issues ? What difficulties did you encounter ?

Note: another post of me regarding this subject can be found here

assumptions are the mother of all fuckups.

New Layout

2008-06-30T21:01:00.002+02:00

I've changed the layout of my weblog, I hope you like it.

If you have any remarks regarding the layout, if you don't find it readable, if you miss something, please let me know.

Setting Up Continuous IntegrationPart II: configuring CruiseControl.NET

2008-06-13T18:38:00.008+02:00

Now that we've created our buildscript in part I, it's time to set up the configuration file for CruiseControl.NET

The ccnet.config file and multiple project-configurations

The tasks that CruiseControl.NET should execute for your project, are configured in the ccnet.config file.
The ccnet.config file can contain multiple project configuration blocks. However, I like to have each project-configuration in it's own, separate file. In my opinion, this is much more manageable.

In order to put each project-configuration in its own XML file and import it in the ccnet.config file, you can make use of DTD entities to substitute constants with the contents of other XML files.
This is how I've done it:

<!DOCTYPE cruisecontrol [
    <!ENTITY project1  SYSTEM "file:D:\folder\project1_ccnet.xml.config">
    <!ENTITY project2 SYSTEM "file:D:\folder\project2_ccnet.xml.config">
]>

<cruisecontrol>

  &project1;
  &project2;

</cruisecontrol>

The above piece of code makes sure that the &project1 and &project2 'placeholders' are replaced with the content of the project1_ccnet.xml.config and project2_ccnet.xml.config files.

I just saw that CruiseControl.NET 1.4 has a new approach to accomplish this, however, I haven't tried it yet.

The CC.NET config file

The CC.NET config file is in fact very simple. You just have to put the Tasks that you've defined in your MSBuild file in the CC.NET config file.
Your CC.NET config file could look like this:

The above configuration file is by all means not complete; I've kept it simple, and left out some tasks. However, you should have an idea :)

MSBuild doesn't support my sln file format

The reason why I specify which executable must be used by msbuild, is very simple:
My project is written in VS.NET 2008, but targets the .NET 2.0 framework. So, by default, CC.NET will use the MSBuild program that has been delivered with the .NET 2.0 framework.
This results in an error: MSBuild doesn't recognize the VS.NET 2008 solution file format, and will stop with this error:

Solution file error MSB5014: File format version is not recognized. MSBuild can only read solution files between versions 7.0 and 9.0, inclusive.

This is offcourse due to the fact that the MSBuild that is used by VS.NET 2005 doesn't know anything about the solution file format that is used by VS.NET 2008.
You can solve this issue by specifying that CC.NET should use the MSBuild executable that can be found in the directory of the .NET 3.5 framework.

The MSBuild XmlLogger Issue

It is possible that CruiseControl.NET will not be able to execute your project, because CC.NET can't find an appropriate XmlLogger.
In this case, you'll find the following error in the CC.NET logfile:
Cannot create an instance of the logger. Could not load file or assembly 'ThoughtWorks.CruiseControl.MsBuild.dll' or one of its dependencies. The system cannot find the file specified.

You can solve this problem by placing the XmlLogger for MSBuild (you can find the dll here in your project working directory.

Setting Up a Continuous Integration process using CruiseControl.NET and MSBuild.Part I: creating the MSBuild build script

2008-06-07T17:37:00.016+02:00

Intro

I’ve been struggling lately to get a new project that I’ve started at work, under Continuous Integration.
Although I’ve used CruiseControl.NET & NAnt in my previous project for CI purposes, things didn’t go so smooth now ...

In my current project, I’m using Visual Studio.NET 2008 and targetting .NET 2.0.

Now, I wanted to use MSBuild for the build process and that’s where it all started.

I had to spent some time searching on the Net in order to get everything working like I wanted. It seems that there’s no single source of documentation for MSBuild & CC.NET which addresses all the problems that I’ve encountered.
So, the intention of this article, is to help other people setting up a CC.NET environment with MSBuild, and it will also serve as a reference for me, so that I can grab back to it when needed. :)

Requirements

What I wanted to achieve, is very simple:

I have a build machine where CruiseControl.Net is installed. This machine is already used for another project of mine for which I’m using NAnt for the build process.

The new project that I’ve started, is being developped in VS.NET 2008, targets the .NET 2.0 framework and is under SourceControl via Visual SourceSafe.

I wanted to have a CI process that regularly looks in VSS and, when something has changed, performs the following tasks:

Make sure that the latest buildscript will be used

Clean the source directory

Get the latest version of the codebase out of Visual SourceSafe

Build the entire codebase

Execute the unit tests that I have using NUnit

Perform a statical code analysis using FxCop

The MSBuild build-script

In order to automate all the steps above, I needed to have a build-script first which I can execute using MSBuild.

Such a script is also handy when the application you’re building consists of numerous VS.NET solutions; instead of opening each solution separately in Visual Studio, compiling it, opening the next solution ..., you can build the entire codebase using a single command line.
This is quite handy and productive, I can tell you :)

For every ‘task’ (clean source directory, get latest, build codebase, etc… ) that I want to execute, I’ve created a Target in the build script.

A first little problem I encountered was that MSBuild doesn’t contain any tasks that would allow you to get a latest version out of VSS, run NUnit unit-tests or perform a code analysis with FxCop out of the box.
Fortunately, there exists an open source project called the 'MSBuild Community Tasks Project' which contains additional tasks that can be executed by MSBuild. This means that you don’t need to write your own MSBuild Tasks.

Skeleton of the buildscript

Before creating the Targets, I’ve defined a few properties which I will use in all the tasks:

I define the working directory (where my source can be found) as the builddir, and a directory where the assemblies that have been build should be placed (outputdir).
Next to that, I also have an artifactsdirectory where the results of the unittests and code analysis will be put.

The last line in the above code is necessary so that we can use the additional MSBuild Tasks that can be found in the MSBuild Community Tasks Project.

Now, we can start creating our 'Targets'.

Clean Target

I want to have the possibility to start from a 'clean sheet', so I really need a Target which justs deletes everything that can be found in my builddir and outputdir.
This Target is very simple; you just have to make use of the Delete Task:

Getlatest Target

In order to get the latest version of the source out of SourceSafe, I’ve created the following step:

Here, I just make use of the VssGet Task that is part of the MSBuild Community Tasks project.
Also, notice that this Target depends on the createdirs Target; this means that, when you execute the getlatest Target, the createdirs Target will be executed before the getlatest Target is executed.

The createdirs tasks looks like this:

BuildAll Target

This is the first target where I’ve had some issues, although it’s task is very trivial:
Compile and build everything that can be found in the $(builddir), and make sure that the assemblies that have been built are placed in the $(outputdir).

It seemed very easy to do, since I found out that MSBuild.exe (which is the program I use to compile the code) had a property OutputDir. So, it would be fairly easy to set this property to the $(outputdir) variable.

Alas, to no avail. My assemblies were never copied to the output-directory. Eventually, I discovered that there also exists an OutputPath property, so I tried it. This seemed to work.
So, the buildall Target looks like this:

Offcourse, you can put multiple solution files in the Projects attribute of the MSBuild Task.
You’ll have to separate the sln files with a semicolon.

NUnit Target

This Target is quite simple:

With this Target, I run the NUnit tests that have been written in my test assembly. (I tend to name all my Test-assemblies .Tests.dll).

The results of the unit-tests procedure are placed in the artifacts directory as an XML file. In this way, I can easily incorporate the test-results in my CC.NET report (more on this later).

FxCop Target

This one was a bit cumbersome.
I started out writing this Target with the FxCop task that can be found in the MSBuild Community Project; it looked like this:

The reason why I do not apply the output XSL stylesheet, is very simple: I want CC.NET to display the results on the Dashboard, so CC.NET should read the XML file, and apply the XSL stylesheet.

Now, this Target just worked fine on my development box. However, on my ‘build server’ *ahum* (my previous dev Workstation), I couldn’t get it working.
On the build machine, I constantly kept getting errors.
Apparently, msbuild was trying to locate FxCop in C:\Program Files\Microsoft FxCop 1.32, but I don’t have this old version of FxCop installed.
I’m using FxCop 1.36 beta instead.

Therefore, I eventually opted to put the path where FxCop is installed in my %PATH% environment variable, and decided to use the Exec Task so that I could call the fxcopcmd tool:

In order to keep my build script a bit readable, I’ve created an ItemGroup in where I define all the command-line arguments that I want to pass to FxCopCmd.exe.

By default, the items that are defined in an ItemGroup will be concatenated with a semicolon. This is something I do not wanted offcourse, since command line arguments should be separated by a space.
It is easy to define that the items should be separated by a space:

@(Args, ' ')

There’s a litle sublety with the Exec command however: it doesn’t work well when you have a commandline argument that is a path which contains a space. You should escape such paths with quotes, but I haven’t succeeded in getting it to work with MSBuild yet ...

Executing Targets via MSBuild

Now that we’ve defined all the Targets, we need to see if they work offcourse.
Executing a Target is fairly easy:

Just open up a VS.NET command prompt (or open a regular command prompt and make sure that the path to the MSBuild.exe utility is in your path environment variable), and navigate to the location where your msbuild build-script is located.

Then, you just execute MSBuild, make sure that your build script is used, and tell MSBuild which target he should execute. You can also override the default values of the parameters (like $(outputdir) ) that we’ve defined in our script.

For instance:

msbuild myproject.msbuild /t:buildall /p:outputdir=r:\myproject\release /p:buildmode=release

I think that this is enough text for today.  I will soon post a subsequent article in where I’ll explain how to use this script in CruiseControl.NET.

using directives within namespaces

2008-04-20T20:09:00.002+02:00

Sometimes, I come across code examples where the programmer puts his using directives within the namespace declaration, like this:

namespace MyNamespace
{
    using System;
    using System.Data;

    using SomeOtherNamespace;

    public class MyClass
    {
    }
}

I am used to put my using directives outside the namespace block (which is no surprise, since VS.NET places them by default outside the namespace declaration when you create a new class):

using System;
using System.Data;

namespace MyNamespace
{
    public class MyClass
    {  
    }
}

So, I'm wondering: what are the advantages of placing the using directives within the namespace declaration ?
I've googled a little bit, but I haven't found any clue why I should do it as well. Maybe you'll know a good reason, and can convice me to adapt my VS.NET templates ?

VS.NET 2008: Form designer not working on Windows Vista

2008-03-12T17:31:00.004+01:00

I installed Visual Studio.NET 2008 on my Vista workstation at work. I was keen to work with it, but apparently, my workstation had some issues.

When I started VS.NET 2008, and created a new WinForms project, I received the following error when I wanted to open a Form in the designer:

The Service Microsoft.VisualStudio.Shell.Interop.ISelectionContainer already exists in the service container

I've searched a bit on the Internet, and it seems that I was not the only person who was having this problem.
However, nobody seemed to have a solution for this problem, and according to Microsoft, this problem was not reproducable ...

Eventually, I found a website where someone said you had to install SP1 for .NET 2.0 and SP1 for .NET 3.0.
Unfortunately, these service packs are not supported by Vista.

I was however able to install the updates KB110806 and KB929300 and installing these 2 updates, fixed my problem

Debugging the .NET framework

2008-01-28T11:31:00.000+01:00

As I've written earlier, Visual Studio.NET 2008 makes it possible to debug code that can be found on a source server.
I think this can be very interesting and I can think of numerous situations where this can be very handy.
Suppose you work in a company that uses an in-house developped framework, and you're building an application that uses this framework.
If you experience some strange behaviour inside your application, you can debug your code and step into the code of the framework to see if the company's framework has a bug.

I've read that Microsoft has setup a source server which contains the debug-symbols of the .NET framework, so, as from this month, it is possible to step into the .NET framework source-code as well!
Setting up VS.NET 2008 to enable this is very simple; you can find a step-by-step guide here.

The Mozilla team also have a symbol server. You can read more about it here

Cannot open log for source {0} on Windows 2003 Server

2008-01-15T12:33:00.001+01:00

I am writing an application which uses some .NET remote components that are hosted in IIS on a Windows 2003 Server.
When the remote component throws an exception, the exception information should be written to the EventLog on the Windows 2003 Server; however, Win2k3 seems to be a bit restrictive when a component that is hosted in IIS wants to write to the eventlog.
Although the component does not run under the IIS_WPG or ASPNET account (I am using Windows Impersonation), I always received the following exception when the .NET remote component wanted to write something to the eventlog:

Cannot open log for source {0}. You may not have write access. Access is denied

You can get rid of this behaviour and make sure that the error is indeed written to the EventLog by following the steps below:

Open the registry on the Win2k3 server using regedit
Locate the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\Application key
Find the CustomSD key and append the following string to the existing value: (A;;0x0002;;;AU)

Now, the (impersonated) remote component should have rights to write to the EventLog.

Now, what is the meaning of the string you've just added to the CustomSD key ?

A stands for SDDL_ACCESS_ALLOWED. (See ACE strings).
0x0002 stands for ELF_LOGFILE_WRITE. (See also Event Logging Security
AU stands for Authenticated Users. (See also SID strings



Castle Windsor and ActiveRecord
2007-11-03T16:10:00.000+01:00
I sometimes read blogposts where people mention Castle Windsor and Castle's ActiveRecord, so I decided to have a little peek at these two projects.
Castle Windsor is an IoC container and ActiveRecord is an implementation of the Active Record pattern which internally uses NHibernate.
These projects look very interesting, and I'd like to make use of them in a little hobby-project before using it in a real-world project
Is there anybody who has used one (or both) of these projects in a real world scenario and who wants to share his (or her) findings ? 



New debugging experience in VS.NET 2008
2007-10-24T22:07:00.000+02:00
As I was reading a bit on Bart De Smet's weblog today, I came accros an interesting post where Bart talks about a new 'debugging experience in VS.NET 2008.
It seems that Microsoft will release the source code for the .NET Framework libraries, and that there will be an integrated debugging support in VS.NET 2008.  
This means: when debugging your code, it should be possible to 'step into' the code of the .NET framework classes.   
I think this is great!
I've also read another interesting thing on Bart's weblog:   Bart will be working in the MS HQ's in Redmond, where he'll work on WPF.   That must be a great job, and I'd like to wish Bart a lot of succes!



MSDN RampUp
2007-10-18T20:20:00.000+02:00
Microsoft has set up a programme in which you can take part to gain new or refresh your  existing .NET development skills.
This programme is called 'MSDN Ramp Up'.  It is an online course with a lot of course material and online virtual labs.
The nice thing about this Ramp Up programme, is that Microsoft has made different 'tracks', which are tailored to the existing experience and knowledge of the student.
There are four tracks available:
Aspiring Developer; which is suited for people who have no prior programming experience, but want to learn programming with MS technology

Java Developer; this track is for Java developers who want to gain knowledge about the .NET framework and want to learn programming in C#

MS Visual Basic 6.0 developer; lets existing VB 6 developers become proficient in .NET and VB.NET 2005

MS VS.NET 2002/2003 developer; introduces the .NET 1.x developer with the improvements and changes in the .NET 2.0 framework

If you want to learn more about this programme, or want to take part in it, then visit this website.


MS LEAP Programme, yet another rant.
2007-09-28T18:51:00.000+02:00
A while ago, I received an e-mail with an invitation to take part in the MS LEAP programme.

This looked very interesting, so I asked my employer if I could take that course and if my employer could help me bear the costs.
A few days later, I received the answer that I could and that they (the company where I work) would bear the majority of the cost.  \o/

Now, today, I wanted to subscribe but unfortunately, the program is already fully booked. :(

_{The ranting doesn't stop. :(}


Auto-Formatting in VS.NET 2005 does not work anymore
2007-09-27T22:09:00.000+02:00
After a harddisk-crash, I had to reinstall Visual Studio.NET 2005.
As I started programming again after it was re-installed, I noticed that the 'auto-formatting' function of VS.NET didn't work anymore ...
This is very strange, and very annoying once you're used to it.  I've verified my options, and they're set the way I want too.   
The options:
Automatically format completed statement on;
Automatically format completed block on }

are enabled.   However, when I type a ; or a }, the code is not being formatted at all...
When I use the shortcut 'Ctrl + E, D (format document)', my current document is formatted.
I've no idea why this doesn't work anymore.  I've just made a fresh install of VS.NET.  
Is there anybody who has experienced this 'annoyance' as well, and if so, how did you fix it ?
In other words: if there's anybody out there who knows how to fix it, please let me know. :)



Cleaning a Keyboard
2007-08-13T20:30:00.001+02:00
My keyboard is about 5 years old, and it has been used extensively.  During these years, it has become more and more filthy.
Now, I thought the time has come to do something about it.  Basically, I had two options:
Buy a new keyboard
Clean my keyboard
I thought the second option was more of a challenge then just buying a new one.
So, this is what I did.
To give you an idea of how filthy my keyboard actually was, I've made a picture of it:
After I took a picture of the layout of my keyboard, I removed all keys from the board.  You can imagine that the picture I've taken comes in quite handy when I wanted to place the keys back.
I've put all the keys in a bucket of water, and cleaned them.
After removing all the keys, the keyboard looked like this:
Hmm, this contains a lot of filth as well.  I made good use of the vacuum-cleaner to remove most of it.
Then, when all the cleaned keys were dry again, I could put all the keys back to where they belong.  The result: a clean keyboard:
It was quite some work, but, devving with a clean keyboard is much nicer then using a dirty one. ;)



C# 3.0: new language features
2007-08-08T19:37:00.000+02:00
I've already written a blogpost regarding LINQ and new language features that we may expect in C# 3.0 a while ago.
Since the release of VS.NET 2008 and thereby C# 3.0 is coming closer and closer, I was planning to write an updated blogpost about the new language features in C# 3.0.
However, I've noticed that John Papa has already written an excellent article already concerning the language enhancements in .NET 3.5, so I've decided to just link to that article:
.NET 3.5 Language Enhancements
That's much easier for me, and it saves me some time. :)



XSD Schema for configuration of Log4Net
2007-08-04T10:59:00.000+02:00
A few days ago, I was playing around with log4net, the open source framework that allows you to easily log messages in an application.
Since log4net is very configurable, I wanted to have Intellisense in Visual Studio.NET when I'm editing the log4net configuration. 
Therefore, I need a schema definition for the log4net XML configuration file so that I can set up the Intellisense for the log4net configuration as I did here for NHibernate.
Unfortunately, it seems that the source of log4net doesn't contain such an XSD.
So, before I take the time and effort to create such an XSD, I wonder if anyone has already made such an XSD for log4net and is willing to share it. :) 



NHibernate & MS Access: problems with autonumber fields
2007-07-27T20:39:00.001+02:00
I was playing around with NHibernate and MS Access a bit the other day, and I ran into an annoying problem.

When I tried to save an object which maps to a table wich has an 'autonumber' field, I received this error:

a different object with the same identifier value was already associated with the session: 0

It looked like NHibernate was unable to retrieve the ID that has been given to the new record in the database.   

So, I decided to set up log4net to see if I could find any clue in the logs about the reason for this problem.
As it turned out, it seems that NHibernate was closing the database-connection between the INSERT and the SELECT @@identity statements.
DEBUG NHibernate.SQL - INSERT INTO table ...
DEBUG NHibernate.Connection.DriverConnectionProvider - Obtaining 
IDbConnection from Driver
DEBUG NHibernate.Impl.BatcherImpl - Closed IDbCommand, open IDbCommands: 0
DEBUG NHibernate.Impl.ConnectionManager - aggressively releasing 
database connection
DEBUG NHibernate.Connection.ConnectionProvider - Closing connection
DEBUG NHibernate.Impl.BatcherImpl - Opened new IDbCommand, open IDbCommands: 1
DEBUG NHibernate.Impl.BatcherImpl - Building an IDbCommand object for 
the SqlString: select @@identity
DEBUG NHibernate.SQL - select @@identity
After some research in the Hibernate documentation and on the Internet, I discovered that this is caused by the 'connection release mode'.

The default connection release mode seems to release the connection after each SQL statement, so obviously, Access is not able to determine the correct ID of the last inserted record, since the select @@identity command must be executed on the same connection as its related INSERT statement.
Now that we know what caused this problem, it is easy to fix it: just make sure that you do not use the default connection release mode when using NHibernate with MS Access.  

To do so, you should specify the connection release mode in your NHibernate configuration file like this:
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <property name="hibernate.connection.release_mode">on_close</property>
  </session-factory>
</hibernate-configuration>
More information regarding the different options / settings for the connection-release mode can be found here.



Counting in SQL Server: SELECT COUNT(*) != SELECT COUNT(columnname)
2007-07-18T19:08:00.000+02:00
Today, I've learned something new; or rather, I was being pointed out something that I didn't know about:
It seems that, doing a SELECT COUNT(columnname) does not always give you the same results as doing a SELECT COUNT(*).   As it was pointed out to me, doing a SELECT COUNT(columnname) returns the number of rows in the resultset in where the value of the field in 'columnname' is NOT NULL.
This means that, given the following set of data:
id name
1 Name1
2 NULL
3 Anothername

performing this statement:
SELECT COUNT(*) FROM table
gives us 3 as a result, while doing this:SELECT COUNT(name) FROM table
 returns 2 as result.
I really was ignorant to this behaviour, as I do (or did), most of the time a SELECT COUNT(1) FROM table instead, since I thought that this was the most performant option, but this also seems to be not true in some circumstances; 
doing a SELECT COUNT(*) enables SQL Server to use indexes in calculating the number of results in a resultset.
For a more thourough article about this, I'd like to refer to this article on SQL Server Central.
Thanks to Peter De Boer for pointing this out



Dependency Injection versus Service Locators
2007-06-18T20:42:00.000+02:00
When I was driving home from work, I have been thinking:  when an object (entity) needs a reference to a repository for instance, to get some work done, how do you get a reference to that dependency (in this case, the repository) ? 
Do you use dependency injection, or do you use a service locator ?   When to choose what ? What are the advantages / disadvantages over both approaches ?
For example, suppose you have a 'Customer' class; this class has a property 'Status' which says whether the Customer is a 'Gold Customer', a 'Badly Paying Customer' or a 'Normal Customer'.
In order to determine to which 'state' a specific Customer belongs to, it might be necessary to retrieve some information out of a datastore.  In this case, it could be necessary for instance to retrieve some invoice information regarding this customer.
(A Gold Customer for instance, is a Customer who has ordered for a specific amount of goods in a certain period, while a Bad Payer might be some-one who has overdue invoices).
So, a reference to an instance of IInvoiceRepository must be given to the Customer object.
The question now is, how do you give this dependency to the Customer object ? 

Do you use 'Dependency Injection', and give this dependency via a constructor or a property to the Customer instance, like this:
Customer c = customerRepository.GetCustomer (5);
c.InvoiceRepository = repositoryFactory.CreateInvoiceRepository();
Or, should you leave this responsability to the Customer object ?   In other words: let the Customer instance search for the correct IInvoiceRepository using a service locator.  This could then be done in the Status property of the Customer class:
public CustomerStatus Status
{
   get
   {
      IInvoiceRepository ir = DomainSettings.Instance.RepositoryLocator.GetInvoiceRepository();
      ...
      return status;
   }
}
In this case, the 'RepositoryLocator' can decide which implementation of IInvoiceRepository it has to create and return based on a value in a config file for instance.
Anyway, when do you choose for which option ? What are the advantages  /disadvantages of both concepts ? In which situation do you favor the one over the other ? 
I hope that some smart people can enlighten me about this matter. :)



NHibernate Session Management in Domain Driven App's
2007-04-30T22:33:00.000+02:00
As  I've posted earlier, Billy McCafferty has written an excellent article on using NHibernate within ASP.NET applications.
In this article, he describes how to use the 'Open Session in View' pattern.  This is perfectly useable and a very clean way of working with NHibernate in a DDD ASP.NET application, unfortunately, it is -imho- less (or not) useable in a WinForms application.
The 'Open Session in View' pattern implies that a new NHibernate ISession object is created at each request, and closed at the end of each request.  (Changes are committed as well).
It is very important that the Repositories keep their hands off of Transaction Management.  In other words: a repository should not start, commit or rollback a transaction.  This is natural, since the repository doesn't know anything of the 'context' of the Unit of Work.  Therefore, transaction managment should be a responsability of the client (the UI, the Service layer, whatever).
To achieve this, Billy stores the current ISession in the CallContext or HttpContext (he has made abstraction of which implementation is used offcourse.  CallContext is used in the case of a WinForms app or a Unit-Test project, HttpContext is used in case of an ASP.NET app; see the source-code that accompagnies the article for more details).
In this way, the repositories can easily access the current ISession when they need it by just getting it out of the CallContext or HttpContext, and the ASP.NET application (the ASP.NET webpages) have access to the ISession as well, so they can start, commit and rollback the unit-of-work.
This is the ideal solution in ASP.NET, since you only need one 'ISession' on each request.  At the end of the request, the Session can be closed (committed / rollbacked), so they're short-lived, and this is perfect.
However, in a WinForms application, you'll probably want more then one 'Unit of Work' at the same time, and therefore, have more then one open ISession at the same time.
An example will clarify this a bit more:
Suppose you've a WinForms application which consists of a form which lists all Customers.  You can edit a customer by double-clicking it; a 'Customer-Detail' form will open up, where you can make changes to the Customer.
Now, what happens if you edit a Customer ? You'll retrieve the ISession from the CallContext, load the Customer from the DB, make some changes and confirm the changes; closing the form will close the ISession.
So far, no problem.   However, what happens if you open another Customer-Detail form before you've committed the changes to the first Customer ? 
What if you have 2 Customer Detail Forms open, make changes to Customer 1, save the changes and close the form.  Afterwards, you want to save the changes to Customer 1... The problem now is that you've closed the ISession when you've closed the first Customer-Detail form.  Customer 2 was attached to the same session which is now closed.  If you want to save the changes to customer 2, you'll need an ISession, so you'll require a new ISEssion in this case.  Then, NHibernate will think that Customer 2 is a new Customer, and will try to insert a new record to the DB where in fact, the existing Customer needs to be updated.
In my opinion, it is better to have a seperate Unit Of Work (ISession) for each instance of the CustomerDetail form in this case.  
This implies that you should create a new ISession for each instance of the CustomerDetail form: this means that the ISession cannot be kept in the CallContext since otherwise, each form would share the same ISession.
Then... how should this be solved ? In my humble opinion, the best way to solve this is to create an ISession when an instance of a form is created, pass it to the repositories, and use it to handle the transaction(s) in the form:
public class CustomerDetailForm : Form
{
   private ISession _unitOfWork;

   private CustomerRepository _custRep;

   private Customer _customer;

   public void ShowCustomer( int customerId )
   {
       _unitOfWork = AppSettings.Instance.SessionFactoryObj.OpenSession();
       
       _custRep = new CustomerRepository(_unitOfWork);

       _customer = _custRep.GetCustomer(customerId);

       // Disconnect from the DB, since we do not need DB action at this time 
       // anymore.
       _unitOfWork.Disconnect();

   }

   public void OKButton_Click(object sender, EventArgs e )
   {
      // Reconnect to the DB
      _unitOfWork.Reconnect();

      ITransaction tx = _unitOfWork.BeginTransaction();
      _custRep.Save (_customer);
      tx.Commit();
   }
}
I don't know if there's any better / cleaner way of doing this... If you know one, please let me know. :) It is offcourse cleaner if you could abstract the use of NHibernate's ISession by creating a class which encapsulates the ISession, but I wanted to keep things a bit sparse. :)



Article: NHibernate best practices with ASP.NET
2007-04-27T19:20:00.000+02:00
Billy McCafferty has written an excellent article on NHibernate and Domain Driven Design.  It can be found here on the CodeProject.
Although it is focused on using NHibernate in ASP.NET, it is still very interesting even if you do not develop in ASP.NET.  He talks about a few key concepts in DDD, and the example code is also very interesting.
There's one little drawback however in his example code: although he mentions that the way of working he demonstrates should work for Winforms development as well, I do not completely agree on that.   However, I've to investigate it a bit more, which I'll do as soon as I find some time.   Once done, I'll post my findings offcourse.



Split
2007-04-22T13:19:00.000+02:00
When I started this weblog in december 2005, I decided to blog about software development and about photography.
Now, 1 and a half year later, it seems to me that this was not such a good idea; I feel that software engineering and photography do not share the same audience.  
Now, you probably think, did it really take you that long to acknowledge this fact ?  Well, not really: during the first few months of blogging, the number of photography posts here was pretty low.  At this time, I've noticed that 3 out of the 5 last posts were tagged with 'photography', so that's why I've finally decided to split things up.
This will remain my weblog that is focussed on programming (notice that I've changed the name from 'weblog' to 'devlog' as well :) ).  Things that are focused on photography will appear on my photolog, so if you're interested, you can have a look there :).
I've choosen Wordpress to host my photo-blog, since Wordpress allows me to import posts from blogger, and that's what I've done: I've imported all the 'photography-tagged' posts from this weblog in my wordpress photo-blog, and translated them to dutch.



.NET 1.1: Problems when selecting rows from a DataTable using an aggregate filter
2007-04-13T22:33:00.000+02:00
I came accross a rather weird error today when I was working in C# 1.1.  I was trying to select the records that exist in a DataTable that had more then one child in a related datatable.

To make things a little bit more clear, I've reproduced this by creating a Typed Dataset which contains 2 tables from the Northwind database:


What I want to do, is to select the Categories for which there are multiple products classified into.
So, this is what I've done; I created an instance of this dataset, and populated it with some data:
NorthwindDS ds = new NorthwindDS();
NorthwindDS.CategoriesRow c1 = ds.Categories.NewCategoriesRow();
c1.CategoryID = 1;
c1.CategoryName = "Category 1";
ds.Categories.AddCategoriesRow (c1);

NorthwindDS.CategoriesRow c2 = ds.Categories.NewCategoriesRow();
c2.CategoryID = 2;
c2.CategoryName = "Category 2";
ds.Categories.AddCategoriesRow (c2);

NorthwindDS.ProductsRow p1 = ds.Products.NewProductsRow();
p1.ProductID = 1;
p1.CategoryID = 1;
p1.ProductName = "Product 1";
ds.Products.AddProductsRow (p1);

NorthwindDS.ProductsRow p2 = ds.Products.NewProductsRow();
p2.ProductID = 2;
p2.CategoryID = 1;
p2.ProductName = "Product 2";
ds.Products.AddProductsRow (p2);

// The following line is important to illustrate the problem :)
ds.AcceptChanges();
This is pretty simple, I've just populated the Dataset with 2 categories and 2 products, and the 2 products are both linked to Category 1.
Now, the Query I've talked about earlier should thus return 1 Category, specifically, Category 1, since there's more then one product related to this category.
I do this using the following code:
string filterExpression = "COUNT (Child.CategoryID) > 1";
DataRow[] dr = ds.Categories.Select (filterExpression);

foreach( NorthwindDS.Category cat in dr )
{
   Console.WriteLine (cat.CategoryName);
}
This gives me the expected result, it writes 'Category 1' to the output-window.
However, suppose that I've populated this Dataset with data coming from the Database, and that I add a product - record to this Dataset after the Dataset has been populated...  
I can simulate this by adding a ProductRow to the DataSet after the 'AcceptChanges()' call:

// previous lines which create the dataset, and add the categories
// and the first 2 products are left out for brevity
ds.AcceptChanges();

NorthwindDS.ProductsRow p3 = ds.Products.NewProductsRow();
p2.ProductID = 3;
p2.CategoryID = 1;
p2.ProductName = "Product 3";
ds.Products.AddProductsRow (p3);

filterExpression = "COUNT (Child.CategoryID) > 1";
DataRow[] dr = ds.Categories.Select (filterExpression);

foreach( NorthwindDS.Category cat in dr )
{
   Console.WriteLine (cat.CategoryName);
}
Now, I would expect that this gives me the exact same result as before, however, I get an exception:
An unhandled exception of type 'System.Data.VersionNotFoundException' occurred in system.data.dll

Addition information: There is no original data to access.
Probably, .NET wants to access the original contents of my new ProductRow, but since it is a new one, it has no Original DataViewRowState ...
I've tried to work around this by specifying that the CurrentRows should be used:
ds.Categories.Select (filterExpression, 
                      string.Empty, 
                      DataViewRowState.CurrentRows);
But, to no avail. (Which didn't surprise me, because this line just says: return the Current DataViewRowState of the Categories and the problem seems to occur when the Product datarows are accessed).
So, this seems to be a bug in the .NET 1.1 (I've tried this in .NET 2.0 as well, and there, it works like a charm).
So, is there anybody who knows how to solve or work around this issue ?



Tagliatelle - scampi
2007-04-01T12:37:00.001+02:00



Oudenaarde by Night
2007-03-09T21:01:00.000+01:00
Yesterday evening, I've been walking around in Oudenaarde - the city were I'll be living in in the near future -, and I've taken these photographs.







DDD: implementing persistence using NHibernate
2007-02-25T12:02:00.001+01:00
Introduction
At last, I've found some time to sit down and begin writing what should be the last part of this 'Domain Driven Design Quickstart' series of articles.  In this final article, I will implement the persistence of the domain model that I’ve created in the previous parts of this series.  (part I, part II and part III).
To implement the persistence functionality of the domain model, I will use an O/R mapper.  I’ve opted to use NHibernate as O/R mapper for this project.
I will not make an in-depth coverage of NHibernate in this article, since this is a bit beyond the scope of this article.  Besides, there are various excellent resources on (N)Hibernate available.  The book Hibernate in Action, for instance, is an excellent resource to learn about (N)Hibernate, and it offers also some more insights in the O/R principle.

The Database Schema
To get the information in a database, we need a database first (clever :) ).  So, I’ve created this ERD:


I’m not going to elaborate on this database-schema since I presume that you have enough knowledge of databases / database-modelling, etc…  So lets hop to the next phase.
NHibernate configuration
NHibernate is an O/R mapper which lets you persist your data to a number of supported databases.   To be able to use it however, it needs to be setup properly; in .NET this can be easily done in the configuration file of your project.
For this project, I’ll create a WinForms application, and I’ll make some changes to the app.config file to configure NHibernate.   This is done like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="nhibernate"
             type="System.Configuration.NameValueSectionHandler, 
                   System, Version=1.0.5000.0,Culture=neutral, 
                   PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <nhibernate>
    <add key="hibernate.connection.provider"
         value="NHibernate.Connection.DriverConnectionProvider"/>
    <add key="hibernate.dialect"
         value="NHibernate.Dialect.MsSql2000Dialect"/>
    <add key="hibernate.connection.connection_string"
         value="Data Source=localhost;
                Initial Catalog=SomeShop;
                Integrated Security=SSPI"/>
  </nhibernate>
</configuration>
As you can see, I need to define the nhibernate configuration section first.  Once this is done, I specify to which type of database NHibernate will have to talk to (SQL Server 2000), and I also specify the connection string that must be used.
If you use Microsoft Visual Studio.NET 2005, you might come across some unwanted error/information messages concerning the nhibernate config section.  I’ve written another post about this problem, and how to solve it a while ago.  You can read it here.
Now we’ve configured our project to use NHibernate, but we also need to tell NHibernate how our classes should be mapped to our database-schema.  This can be done by creating NHibernate mapping files which describe how a class should be represented in the database.  Those mapping files are nothing more then XML files.  As I’ve said earlier, this is not an NHibernate tutorial, but merely an article on how NHibernate can be incorporated in a Domain Driven Design project.  Therefore, I will not post all the mapping files here or explain them in detail.  I will post 2 mapping files here however, and explain them a bit.
NHibernate mapping files
For each class in my domain model, I create an NHibernate mapping file in my Visual Studio.NET project which contains my business classes.
In this specific case, I have a Class Library project which contains the ‘Customer’, ‘Order’, ‘OrderLine’, etc… business classes, so it is in this class library that I also create the NHibernate mapping files.
The mapping file for the Order class, for instance, looks like this:
<xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
  <class name="SomeShopDomain.Order, SomeShopDomain" 
         table="[Order]" lazy="false">
    <id name="Id" column="OrderId" type="Int32" 
        unsaved-value="-1" 
        access="field.camelcase-underscore">
      <generator class="identity" />
    </id>
    <property name="OrderDate" column="OrderDate" 
              access="field.camelcase-underscore" />
    <property name="Status" column="OrderStatus" 
              access="field.camelcase-underscore" />
    <property name="Discount" column="Discount" 
              access="field.camelcase-underscore" />

    <many-to-one name="OwningCustomer" column="CustomerId" 
                 class="SomeShopDomain.Customer, SomeShopDomain"
                 not-null="true" 
                 access="field.camelcase-underscore"
                 />

    <bag name="OrderLines"  cascade="save-update" 
                            inverse="true" 
                            access="field.camelcase-underscore">
      <key column="OrderId" />
      <one-to-many class="SomeShopDomain.OrderLine, SomeShopDomain"/>
    </bag>
    
  </class>
</hibernate-mapping>
This is not the most simple mapping-file in the project, since the Order class contains a collection of OrderLines, so this relationship is reflected in the mapping file.
But, it is maybe better if I just explain the complete mapping file a bit .
As you can see at the beginning of the file, this file describes how the Order class should be mapped to the Order table in the database.
The 'id' element tells NHibernate that the Id property of the class should be used to identify each Order.  This element also defines that the Id property of the class maps to the OrderId column in the Order table.  The data-type is also defined in there, and it is stated that instances of the Order class that have a value of -1 for the Id property, are New/transcient (unsaved).
Now, NHibernate will use the Id property of the Order class to get or set the value of the Id.  
This however, has some disadvantages in my opinion: what if you have some specific logic in the setter-part of the property, some validation-logic for instance ? When NHibernate loads an object out of the database, should this logic be executed ? In my humble opinion not.  When an object is loaded from a persistent state, the values of the object must be set, without performing any extra logic.
Another problem pops up when the property is read-only.  In this case, Id is an 'identification', and the programmer that uses the Order class, shouldn't be able to change this property.  Therefore, this property has only a getter in the Order class, and no setter.  NHibernate will have a problem with that:  it will throw an exception saying that it cannot set the value of the Id property since it has no setter.
That's why I use the access attribute.  With this attribute, I tell NHibernate that it should use the field instead of the property, and that it can find this field by taking the property-name that I've defined in the mapping file, prefix it with an underscore, and make the first character lowercase.  
So, in this case, instead of setting the Id property, NHibernate will look for a field in the Order class which is called _id and give this field the value of the OrderId column.   By using the field instead of the property, I'm always sure that no extra logic will be executed, and I do not have to bother with getter-only properties.
You can read more about this here and here Particulary in the comments of these articles.
The following three properties are quite straightforward.  These elements just say to which column each property maps, and I've also defined that NHibernate should use the field instead of the property to get / set these properties.
The next two elements are bit more interesting though.
The many-to-one element defines how the relationship between Order and Customer must be saved.   As you might remember, the Order class holds a reference to the Customer to which the order belongs.  To be able to populate the OwningCustomer property which contains this reference, and to be able to save the link with the Customer when the Order is saved, the many-to-one element is used.  A Customer can have many Orders, and an Order always belongs to one Customer.  The many-to-one element just says that the OwningCustomer property maps to the CustomerId column in the Order table, and that the OwningCustomer is of the type SomeShopDomain.Customer.  By defining this type, NHibernate knows that it should look for a mapping file which should be called SomeShopDomain.Customer.hbm.xml in where the mapping of the Customer type is defined.  
Mapping files should be named after the class for which they contain the mapping, and should have the extension hbm.xml.  Next to that, you also have to specify 'embedded resource' as build action for the mapping files.
The <bag> element defines that the Order contains a collection of OrderLines, and that these objects must be of type SomeShopDomain.OrderLine.  NHibernate will use the mapping-file of the OrderLine class to determine in which table those OrderLines must be saved.  
The <key> element states that the Id of the current Order must be saved in the OrderId column of the table where the OrderLines will be saved.

This concludes the quick tour of the NHibernate mapping file.  For more information about the possible elements, I'll refer to the Hibernate in Action book, or to the Hibernate documentation.
The mapping file of the OrderLine class, looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
  <class name="BlogShopDomain.OrderLine, BlogShopDomain" 
         table="OrderLine" lazy="false">
    <id name="Id" type="Int32" 
                  column="OrderLineId" 
                  unsaved-value="-1" 
                  access="field.camelcase-underscore">
      <generator class="identity" />
    </id>
    <property name="ArticleName" column="ArticleName" 
              access="field.camelcase-underscore" />
    <property name="ArticlePrice" column="ArticlePrice" 
              access="field.camelcase-underscore" />
    <property name="ArticleId" column="ArticleId" 
              access="field.camelcase-underscore" />
    <property name="NumberOfItems" column="NumberOfItems" 
              access="field.camelcase-underscore" />

    <many-to-one name="OwningOrder" column="OrderId" 
                 class="BlogShopDomain.Order, BlogShopDomain" 
                 access="field.camelcase-underscore"
                 not-null="true" />
    
  </class>
</hibernate-mapping>
I'm not going to elaborate on this file, so lets get to the next part. :)
Integrating NHibernate in the project
At this point, I've done some necessary configurations, but some coding needs to be done as well.
NHibernate uses the concept of Sessions as an 'interface' between your objects and the database.  A session can be considered as a unit of work.  This is a bit a simplistic definition, but you can find a better one in the Hibernate documentation or in Hibernate in Action.
To be able to create Sessions, you'll need a SessionFactory.  Unlike Hibernate Sessions, a SessionFactory is an expensive object to instantiate, so it's best practice to create this object only once.
Therefore, I like to create a Singleton class which holds amongst some other stuff, the NHibernate ISessionFactory:
public class ApplicationSettings
{
  private static ApplicationSettings _instance;

  private ApplicationSettings() {}

  // The only access point to the ApplicationSettings instance.
  public static ApplicationSettings Instance
  {
    get
    {
       if( _instance == null )
       {
         _instance = new ApplicationSettings();
       }
       return _instance;
    }
  }

  private ISessionFactory _sessionFactory = null;

  public ISessionFactory SessionFactoryObj
  {
    if( _sessionFactory == null )
    {
      Configuration cfg = new Configuration();
      cfg.AddAssembly (typeof(SomeShopDomain.Customer).Assembly);
      _sessionFactory = cfg.BuildSessionFactory();
    }
    return _sessionFactory;
  }

}
This structure guarantees that I'll have only one ISessionFactory in my project, and that this SessionFactory is created only once.
The code to create the ISessionFactory is quite simple; first of all a Configuration object is instantiated, and the assembly which contains the business classes is added to the Configuration.  As you can see, I use reflection to find that assembly, since I don't want to be bothered with assembly-names and locations.   After that, the BuildSessionFactory method is called which creates the ISessionFactory.
This ApplicationSettings class is not part of my class library which contains the domain, but belongs to the project that contains my client application (in this case, a WinForms application).  More on that later.
At this time, we can create ISessions.
ISession s = ApplicationSettings.Instance.
                   SessionFactoryObj.OpenSession();
Creating Repositories for our Domain classes
In Domain Driven Design, getting objects from a persistence store, and getting objects into a persistence store, is being abstracted by the use of repositories.
As you might have seen in the previous articles of this serie, I've already created 'dummy' repositories for the unit-tests.
Now, it is time to implement the 'real' repositories, which will actually do the work of loading / storing objects to our database.
In the 2nd part of this serie, I've already mentionned the existence of the DomainSettings class and the RepositoryFactory interface.
At that point, I've only implemented the 'mock-repositories', but now, I want to implement repositories which use NHibernate to do some real work.  This means that I'll have to create an NHibernateRepositoryFactory class.  I choose to put this class, along with the NHibernate-repositories in the same project / assembly where my business classes reside.
The NHibernateRepositoryFactory class must implement the IRepositoryFactory interface, which looks like this:
public interface IRepositoryFactory
{
 ICustomerRepository  CreateCustomerRepository();
 IOrderRespository CreateOrderRepository();
 ...
}
There's one caveat here however...  When using databases you'll be faced with 'Transactions'.  A repository should not be the initiator nor the 'committer' of a transaction.  
Why?  The repository has no knowledge of the 'context' of the situation.  The repository does not know when it should initiate and commit or rollback a unit-of-work.
As I've told earlier in this article, the NHibernate Session object is the NHibernate object which 'controls' a unit-of-work.  Therefore, I'd like to extent the IRepositoryFactory interface with methods which allow me to create a specific repository with an object which is responsible for transaction-handling injected into it:
public interface IRepositoryFactory
{
 ICustomerRepository  CreateCustomerRepository();
 IOrderRespository CreateOrderRepository();
 ...
 
 ICustomerRepository CreateCustomerRepository( object transHandler );
 IOrderRepository CreateOrderRepository( object transHandler );
}
This allows me to create repositories which can take part in a specific transaction/unit-of-work, and it also allows me to create repositories without having to take care about transactions.  (This is also necessary; as you can see in the code in the Customer class in part 2 of this serie.  There I need to retrieve a value, which is given to me by a repository.  In this case, I do not really need a transaction context).
I've chosen to define the transHandler in my CreateXXX methods in the IRepositoryFactory as an object, since I do not want to couple the IRepositoryFactory interface with NHibernate.
At this time, I can already start writing an implementation of a NHibernateRepositoryFactory:
public class NHibernateRepositoryFactory :
    IRepositoryFactory
{
  public IOrderRepository CreateOrderRepository()
  {
    ISession s = DomainSettings.Instance.SessionFactoryObj.OpenSession();
    return new NHibernateOrderRepository(s);
  }

  public IOrderRepository CreateOrderRepository( object transHandler )
  {
    // convert the transHandler to an NHibernat ISession object.
    ISession s = transHandler as ISession;

    if( s == null )
    {
      throw new ArgumentException ("object of type NHibernate.ISession expected.",
                                   "transHandler");
    }

    return new NHibernateOrderRepository (s);
  }
}
The NHibernateOrderRepository can look like this:public class NHibernateOrderRepository :
  IOrderRepository
{
  private ISession _context;

  public NHibernateOrderRepository( ISession s )
  {
    _context = s;
  }

  public Order GetOrder( int id )
  {
    return _context.Get (typeof(Order), id) as Order;
  }

  public decimal GetOrderTotalForCustomerSinceDate( Customer c, DateTime date )
  {
    string hql = "select sum (ol.NumberOfItems * ol.ArticlePrice) " +
                 "from Order o, " +
                 "OrderLine ol, Customer c " +
                 "where ol.OwningOrder = o and o.OwningCustomer = c " +
                 " and c.Id = :custId and o.OrderDate >= :orderDate";

    IQuery q = _context.CreateQuery (hql);
    q.SetInt32 ("custId", c.Id);
    q.SetDateTime ("orderDate", date);

    object o = q.UniqueResult ();

    if( o == null || o == DBNull.Value )
    {
      return 0;
    }
    else
    {
      return Convert.ToDecimal (o);
    }
  }
}
I will not elaborate here on the HQL and the specific ISession methods which I've used in the code above, since this would be truly outside the scope of this article.  For more information, I'd refer -again- to the Hibernate documentation or the Hibernate in Action book.
I do like to mention though that the bug which I've mentionned here is fixed in NHibernate 1.2.0 CR1. :)

As I'm typing this, I now also see that it would be better to let the repositories implement the IDisposable interface.  In the Dispose method.  In the Dispose method of the NHibernateRepositories, I can then check if my _context is still open, and close it if it is.
Then, I should also change the code in the Status property of the Customer class, so that it looks like this:
public CustomerStatus Status
{
  get
  {
    CustomerStatus result = CustomerStatus.Normal;
    
    using( IOrderRepository or = 
             DomainSettings.Instance.
                            RepositoryFactoryObj.
                            CreateOrderRepository () )
    {
      decimal orderTotal = or.GetOrderTotalForCustomerSinceDate(this,  
                                 DateTime.Now.AddMonths (-3));

      if( orderTotal > DomainSettings.GoldAmountTreshold )
      {
        result = CustomerStatus.Gold;
      }

    }
    ...
    return result;
}
If I don't do this, the ISession which is used by the OrderRepository would be kept open.

Using NHibernate in the client application
Now that we've seen (albeit rather quickly) how we can use NHibernate, it is time to integrate it in the client application.
Because of the way NHibernate works when it has to save changed objects back to the DB, I'd like to use long living sessions.
When you retrieve an object from the database, NHibernate will keep this object in the Session.  When you save the object back to the database, NHibernate will try to find the object in the ISession instance which is used to perform the save.   If the instance is found, NHibernate will update the corresponding record.  If the instance is not found, NHibernate will create a new record.
If you use a separate ISession to retrieve an object from the DB, and use another ISession to persist this object back to the DB, NHibernate will asume that it has to insert a new record.
Therefore, it is -imho- best to use the same ISession instance for retrieving and saving the same business object instance.
When you're using NHibernate in Windows applications, you can do this by using the 'long conversation' model. 
In short, this means that you can keep your session open as long as the user is busy with a 'unit-of-work', but you can disconnect your session from the database when no database-access is needed for a while.
Although this article doesn't provide really in-depth information, I'd like to finish it here.  This is yet another article which is way to long (maybe I should stop writing such long posts), but if you've gotten to here, please feel free to post any comments, critics, remarks, ...



Meet My Mom
2007-01-31T23:46:00.000+01:00
In the past few weeks, I've been making some portraits.   Some of them in a studio, others 'on location'.
I will post some of the results here and I'll start with a portrait of my mother.
These photographs are shot in her 'study room'; my mom loves painting and  calligraphy (she's pretty good at it) and I wanted to express this in my photographs.


Just a pity that she's holding the pen a little bit to high



The photos have been taken with ambient light (I don't like to use flash for location-portraits).  I've used a Nikon D200 with a 50mm f/1.8 lens mounted on it.  Since there was not too much light available, I've choosen a small aparture number and a high ISO setting. (The EXIF information is available in the picture; you can easily view it using Opanda IEXIF Viewer").  Despite the high ISO setting, I've to admit that I'm pleasantly surprised with the noise levels in these photo's.



Lambda expressions in .NET
2007-01-20T11:41:00.001+01:00
In C# 3.0, there will be a new feature available: lambda expressions.   This new feature was necessary to create the LINQ feature, which will also be introduced in C# 3.0
Today, I came across an interesting article written by Howard Dierking in where he explains what lambda expressions are, and how you can use them.  
Very nice and clear article.



Tagged
2007-01-20T10:39:00.000+01:00
Seems that I've been tagged by Mike Nichols, so I'm supposed to come up with 5 things you don't know about me; here goes: 

I've started playing music when I was about 8 or 9 years old.  I've played guitar until I was about 16 years old.  At that age, I stopped playing music.  I didn't wan't to do it anymore.  I was supposed to go to music classes each wednesday afternoon, and each saterday morning and I wanted to do other things during that time. :)  Sometimes, I regret it though that I didn't continue with that guitar-thing. (I still have my guitar though, and maybe I'll pick it up again in the future)

I don't like cheese.
Well, that's not completely true; I don't eat cheese 'as is', but I do like food that has cheese as an ingredient (pizza, croque monsieur, tiramissu, heck I even like cheese-burgers).  I also like Cheetos.  Weird huh?

I started programming relatively late.  I was 17 years old when I wrote my first computer program.

I always wanted to become a pilot.  Not on airliners, but a jet pilot. :)  At age 16, I've sent a letter to the Belgian Air Force to enquire for more information about this.  A few days later, I've received an information bundle about it.  Unfortunately, I never took part in any of the 'promotions' of the Belgian Air Force.  Maybe I was already realistic about my chances: there are only very few positions (about 4 each year) and numerous candidates.  
I haven't lost my interest in jets though; I still like to visit air-shows (although since a plane crashed at the Ostend Airshow in 1997, air-shows in Belgium aren't what they used to be...).
If I would ever have the chance to be a passenger in a two-seater, I'd certainly do it!

I do like karting.  Until a few years ago, I used to do it at least once a week.  Unfortunately, I'm not able to keep up that frequency right now.  I'm already happy if I can go karting once a month.  
I also dream of driving an open-wheel formula race car once (Formula One, Formula Ford, F3000, ... whatever
The 5 persons I'm tagging are: PJ van de Sande, Peter Veentjer, Jelle-Jan Van Veelen, Valentijn and Evan Hoff



Left- and RightPadding in SQL Server
2007-01-10T20:07:00.000+01:00
Although SQL Server contains a few string manipulation functions, there exists no function that allows you to left- or rightpad a string expression.
This is a bit of a pity, since left- and rightpadding is sometimes necessary.
But, no one stops you from creating your own LPAD and RPAD function offcourse; in fact, it is rather very simple. :)
Although SQL Server doesn't provide padding methods out of the box, it doesn't require a lot of work to pad a string.

For instance: suppose you have a variable @number, which contains a number. If you need to leftpad this string with zeroes so that it always contains 8 characters, you simply have to do this:
SELECT RIGHT ('00000000' + @number, 8)
If @number contains '81337', this statement will return '00081337'.
With this knowledge, it is pretty simple to create your own LPAD method.  This is the code:
CREATE FUNCTION [dbo].[LPAD] (@string VARCHAR(8000), 
                              @length INT, 
                              @paddingChar CHAR(1))
AS
BEGIN
    RETURN RIGHT (REPLICATE (@paddingChar, @length) + @string, @length)
END
Creating an RPAD function is very similar:
CREATE FUNCTION [dbo].[RPAD] (@string VARCHAR(8000),
                              @length INT,
                              @paddingChar CHAR(1))
AS
BEGIN
    RETURN LEFT (@string + REPLICATE (@paddingChar, @length), @length)
END
As you might have noticed, REPLICATE is a SQL Server function which repeats a specified characters a number of times. :)



Shelfari Bookshelf
2006-12-30T16:15:00.000+01:00
As a software developer, I reguraly buy (and read) books on software development.  I've found a website where you can create your 'virtual bookshelf', and I've decided to create one.

On my virtual shelf, you will mostly find books on software development and photography.  Not all of my books are already listed, but I will complete my shelf in the near future.  
For some books on my shelf, I've written a little opinion about it.  If you want to buy a book that I have on my shelf, you can directly go to the Amazon.com website by clicking on a particular book.
If you want to know my opinion on a particular book for which I haven't supplied an opinion yet, do not hesitate to contact me. :)



VS.NET 2005: XML View of a Typed DataSet
2006-12-27T19:37:00.000+01:00
Although I'm not a big proponent of (typed) DataSets ~ I rather use custom business classes ~ , I do have to use them every once in a while.
When I use a typed dataset in VS.NET 2003, I always use 'typed DataSet Annotations'.  
This is very easily done in VS.NET 2003: you'll have to switch from DataSet view to XML View, and this can easily be done by the handy buttons that you can see in the lower-left corner:

 

Clicking on 'XML' would give you the XML view of your typed Dataset; simple as that.
A few days ago, I was working in VS.NET 2005, and I wanted to create a typed DataSet ...  I wanted to use the 'annotations' like I was used to do in VS.NET 2003.
I was amazed to find out that those handy XML / DataSet View buttons that exist in VS.NET 2003 are gone in VS.NET 2005.   
Apparently, Microsoft doesn't like the idea that developers sometimes want to tweak some settings via code instead of via the properties window ? At least, that's how I'm thinking about it.



After some searching, I've found out that it is still possible to get the XML View of a DataSet in VS.NET 2005, but damn, it is very well hidden.
Here's how you can see the XML definition of the DataSet:

Right click on the DataSet file

You'll see the following context-menu:


Select the 'Open With option'

The following Dialog Box opens:



Select the 'XML Editor' option

Now, you can see the XML View of the DataSet definition

As you can see, in VS.NET 2005, 3 user interactions are needed in order to go to your destination, instead of just a single click in VS.NET 2003.  
Not very productive IMHO.

I wonder why Microsoft has removed those buttons that existed in VS.NET 2003...




Official owners
2006-12-09T11:22:00.000+01:00
Since yesterday, my girlfriend and I are the official and proud owners of this piece of Belgium:




Next step: building a house on it.


High Key
2006-12-01T18:40:00.000+01:00
Yesterday, I've been playing around a bit and wanted to create a high-key picture.  
I think the result is quite ok. :)

Apart from some 'levels' adjustements in Photoshop, no other modifications have been made.
I've put the lighters on a plexiglass (hence the reflection), and used two elinchrome strobes to make the picture like it is shown here.



Nested Transactions in SQL Server
2006-11-11T11:02:00.000+01:00
I've been wondering if it would be possible to use 'nested transactions' in SQL Server.  To test this, I've set up a little test database and executed a few 
T-SQL batches:
USE testdb
BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name1')

BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name2')
COMMIT TRAN

INSERT INTO tblTest (Name) VALUES ('Name3')

COMMIT TRAN
This is trivial, and it works as expected: 3 records have been added to the table.  The next batch looks like this:
USE testdb
BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name1')

BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name2')
COMMIT TRAN

INSERT INTO tblTest (Name) VALUES ('Name3')

ROLLBACK TRAN
This is no big deal either: as expected, no records have been added to the table.  Up to the next one:
USE testdb
BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name1')

BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name2')
ROLLBACK TRAN

INSERT INTO tblTest (Name) VALUES ('Name3')

COMMIT TRAN
This batch fails with the following error message:
Server: Msg 3902, Level 16, State 1, Line 16

The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
It turns out that only the last record (Name3) is inserted into the database.  That's not what I expected.  
Normally, one should expect that Name1 and Name3 are persisted in the database, and only Name2 gets rollbacked.



However, as my collegue Geert pointed out: the BEGIN TRANSACTION statement increments the @@TRANCOUNT Server Variable with 1, and the COMMIT TRANSACTION decrements the @@TRANCOUNT variable with 1. 
The ROLLBACK TRAN statement however, decrements the @@TRANCOUNT server variable to 0.  That's why the last COMMIT statement gives us the error message: there has been a rollback, and therefore the @@Trancount is set to zero.
Apparently, the ROLLBACK TRANSACTION also rollbacks to the most outer begin transaction, that's why the record 'Name1' is not persisted into the database.
As it turns out, it is not possible to use nested transactions in this way.  There is however a way to solve this 'problem':
Savepoints to the rescue
It is possible to use 'savepoints' to solve this problem.  As stated in the SQL Server books online:
Savepoints offer a mechanism to roll back portions of transactions.
You use savepoints like this:BEGIN TRAN
INSERT INTO tblTest (Name) VALUES ('Name1')

SAVE TRANSACTION sp1
INSERT INTO tblTest (Name) VALUES ('Name2')
ROLLBACK TRAN sp1

INSERT INTO tblTest (Name) VALUES ('Name3')

COMMIT TRAN
In this code example, you start a transaction, execute a statement, and save the transaction using the SAVE TRANSACTION sp1 statement.
This statement sets a savepoint with the name 'sp1'.  You can then rollback to that savepoint using the ROLLBACK TRAN <savepointname> command.
The result of this batch is as expected: 2 records are inserted into the tblTest table: 'Name1' and 'Name3'



Aspect Oriented Programming in .NET
2006-11-05T10:37:00.000+01:00
A while ago, there was somebody who asked the question on a programming forum whether it was possible to retrieve the values of the arguments that are passed to a method in .NET.   The purpose was to create some kind of a 'logging' system so that he could log which methods have been called, and what values were passed to those methods.
This person had already created a method that retrieved all kinds of information of a certain method, but getting the values of the parameters via reflection was not possible.
The disadvantage of this approach is that your methods are being polluted by this logging method.  You always have to add a call to this logging method in your 'business methods'.  
For instance:
public void SomeMethod()
{
    LogThisMethod (MethodBase.GetCurrentMethod());
    
    // Do the real work here.
}
The call to the LogThisMethod method is not likely a core concern in the application, yet, if you want to log calls to certain methods, you’ll have to write a call to this method in every method that you want to log.
In other words: the logging is a cross-cutting concern because it is an aspect of our program that has nothing to do with the core-problem that is to be solved by our program and it appears in multiple parts of the program.
Luckily, there's a much cleaner approach to solve this problem.    Aspect Oriented Programming offers a way to separate cross-cutting concerns like logging in a much cleaner way.
AOP allows you to remove the cross-cutting concerns from your 'business code', and create an 'aspect' for it instead.  
This ‘aspect’ will then be weaved into your code at runtime which means that you do not have to call it yourself in the core parts of the application.
In this way, the cross-cutting concerns can be decomposed from the core logic of the application and this will result in more readable and better maintainable software.
In .NET, you can use the Spring.NET framework to apply Aspect Oriented Programming.
In the examples that follow, I’ll be using the Spring.NET framework.
You can solve the logging-problem that I've mentioned earlier using AOP in C# in the following way:
Suppose we have a class 'TestClass' and we want to log every method that is being invoked in this class.   Our TestClass looks like this:
public interface ITest
{
  void SayHello( string name );
  void Shout( string message );
}

public class TestClass : ITest
{
  public void Method1( string name )
  {
    Console.WriteLine ("Hello " + name + " ! ");
  }

  public void Shout( string message )
  {
    Console.WriteLine (message + "!!!!!!!");
  }
}
These are the steps that have to be taken to create some kind of logging functionality using AOP:

Create an Advice that takes care of the logging.  An Advice describes a certain ‘procedure’ that must be executed at certain points (joinpoints) in the application.   For instance: an Advice can be executed at the entry point of a method.

If you use Spring.NET, you can create a class which implements the IMethodBeforeAdvice.  This will make sure that this Advice is called before a method-call.
The Advice can look like this:

public class MethodInvocationLoggingAdvice : IMethodBeforeAdvice
{

  public void Before( System.Reflection.MethodInfo method, 
    object[] args, object target )
  {
    string message = method.Name + " called with ";

    string arguments = string.Empty;

    for( int i = 0; i < args.Length; i++ )
    {
      arguments += args[i] +", ";
    }

    Console.WriteLine (message + arguments.SubString (0, arguments.Length - 2));
  }
}

Now, we have separated the logging logic in a separate class.

Tell our program to use the Advice
In our program, we must indicate that our Advice has to be called when we invoke the methods of a certain class.
Using Spring.NET, we can do this with only 3 lines of code:
static void Main()
{
  ProxyFactory f = new ProxyFactory (new TestClass());

  f.AddAdvice (new MethodInvocationLoggingAdvice());

  ITest t = (ITest)f.GetProxy();

  t.SayHello ("Frederik");

  t.Shout ("Watch out");
}

The beautiful thing is, that we've kept our 'business methods' clean and every time we invoke a method, the logging functionality is called.   If we extend our TestClass with a couple of new methods, we do not have to worry about this logging functionality, since those new methods will also call our MethodInvocationLoggingAdvice as well.

But, what if you only want to log invocations of certain methods, instead of logging every method call? This can also be done rather easily by defining a PointCut.   Everytime the pointcut is reached, our Advice will be executed.
.NET attributes provide a great way to define PointCuts.

Building on the previous example, we can extend our code so that the MethodInvocationLoggingAdvice is only called when a method is decorated with a specific Attribute.   For instance: only invocations of methods that have the 'Log' attribute, must be logged.
To do this, we must first create this Log attribute:
[AttributeUsage(AttributeTargets.Method)]
public class LogAttribute : Attribute
{
}

We can now change the TestClass to indicate that only method-calls to the Shout method should be logged:
public class TestClass : ITest
{
  public void Method1( string name )
  {
    Console.WriteLine ("Hello " + name + " ! ");
  }

  [Log]
  public void Shout( string message )
  {
    Console.WriteLine (message + "!!!!!!!");
  }
}

All what's left to do, is to make a change to the code that will be responsible of weaving the advice into our code.   We must now indicate that our Advice should only be executed on methods that have the Log attribute.
static void Main()
{
  ProxyFactory f = new ProxyFactory (new TestClass());

  f.AddAdvisor (new DefaultPointCutAdvisor (
    new AttributeMatchMethodPointcut (typeof(LogAttribute),  
          new MethodInvocationLoggingAdvice()));

  ITest t = (ITest)f.GetProxy();

  t.SayHello ("Frederik");

  t.Shout ("Watch out");
}

When you execute this program, you'll see that only the method-call to 'Shout' is being logged.





Changing the default access modifier when adding a new class in VS.NET 2005
2006-09-30T02:19:00.000+02:00
When you add a new class or interface to an existing project in Visual Studio.NET 2005, VS.NET 2005 will not define this class (or interface) as public by default.
In Visual Studio.NET 2003 however, new classes and interfaces always received the public access modifier by default, and I do like this VS.NET 2003 approach far better.
When I create a class-library, most of the classes and interfaces that are contained in this library are meant to be used outside the library itself.  This means that I have to explicitly add the public access modifier to most of my classes, and this is a dreadfull job.
Not only is it a boring job to manually define this access modifier for (almost) every new class that you create, it sometimes causes me loosing some time as well:
Today, I created a new class in VS.NET 2005 in where I've written some unit-tests.  I'm using Testdriven.NET to execute my unit-tests in Visual Studio, and as long as I executed only one Test-method at a time, everything went fine.
However, when I wanted to run all the test-methods that I've written in that class, Testdriven.NET didn't execute a single one of them.  I didn't get any error-message, I just received the message: '0 tests passed, 0 tests failed'.
After some investigating, it turned out that my class didn't had the public access modifier, and was therefore internal.  Adding the public access modifier fixed the problem, and all my tests ran smoothly.
After living with this little annoyance for a while, I thought that it should be possible to change this behaviour and make sure that every new class I create in Visual Studio.NET 2005 is marked as public.  In the rare cases that I'll need an internal class, I'll just explicitly change the public modifier to internal.
Since every new item that you can create in VS.NET is based on a template (just like a Word document is based on the normal.dot Document Template), it should be rather easy to change this behaviour.
After some digging in the directory-structure of VS.NET 2005, I've finally found where those templates are being kept.  They're in this directory:

<PF>\Microsoft Visual Studio 8\Common7\IDE\ItemTemplates\CSharp\1033

(where <PF> is your Program Files directory, or the directory where you've installed VS.NET)

In this directory, you'll find a number of zip files.  I've just unzipped the Class.zip file, and editted the Class.cs file that was in it to this:
using System;
using System.Collections.Generic;
using System.Text;

namespace $rootnamespace$
{
 public class $safeitemrootname$
 {
 }
}
Then, I've just added the changed template-file back into the zip-file and thought the job was done, so I tried to create a new class in an existing Class Library...  Sadly, the new class was still not public by default...
After some searching, it appeared that I had to execute a command which would load the Item Templates into Visual Studio.  The command to do so is:

devenv /InstallVsTemplates

This finally did the trick! When I add a new class in VS.NET 2005, this new class now has the public access modifier by default!



Session on Unit Testing & TDD
2006-09-28T21:38:00.000+02:00
Tomorrow, I'll be giving a talk on Unit Testing and Test Driven Development at work. I just hope that everything will go smoothly, and that I can encourage a few collegues to effectively use Unit Testing. :)




VS.NET 2003 not supported on Vista ?
2006-09-28T21:35:00.000+02:00
Today, I've encountered some articles on blogs that some unpleasant news.  
It seems that Microsoft will not support Visual Studio .NET 2003 on Windows Vista; however, Visual Basic 6 will be supported.  I do not understand the logic behind this; 
I thought VB6 was deprecated ? 
Why is VS.NET 2003 not supported ? 
I hope that these rumours will not turn into reality, since I'm still using VS.NET 2003 as my primary dev-tool at work.

Frans Bouma: So, VB6 is more important then VS.NET 2003
Fear  and Loathing: Join the Windows XP club ... for 5 more years or so
Paul  Wilson: Vista will NOT support developers


Collections in Business Entities
2006-09-03T12:02:00.000+02:00
A while ago, I've been thinking on what would be the best approach to work with collections inside business entities.
As an example, I'll refer back to the domain classes I'm using in another post of me.
There, I have a class Order, and an OrderLine class.  The Order class contains a collection of OrderLines.
In C# 2.0, this could look like this:
public class Order
{
  private List<OrderLine> orderLines 
    = new List<OrderLine>();
}
The problem here, is that I want to have 'controlled access' to the OrderLines collection in the Order class. 
What I mean is, that a consumer of these classes should not be able to add an OrderLine to the Order directly, since some additional action(s) need to be executed.



More precisely, if an OrderLine is added to the Order, I want to set a member of the OrderLine, so that the OrderLine knows to which Order it belongs.
Therefore, I create an AddOrderLine method in the Order class:public void AddOrderLine( OrderLine ol )
{
  ol.OwningOrder = this;
  this.orderLines.Add (ol);
}
A consumer of the code should always use the AddOrderLine method if he wants to add an OrderLine to the Order.
You can enforce this easily by not making the orderLines member public; easy enough.
However, at one time, the consumer of your code (or you :) ) will want to iterate through the OrderLines of the Order, or he will want to know how many OrderLines an Order contains.


Now, you'll have several options to achieve this:

One solution is to expose the orderLines collection to the public.  In other words: create a public property which exposes the collection to the outside:
public class Order
{
  private List<OrderLine> orderLines
    = new List<OrderLine>();

  public List<OrderLine> OrderLines
  {
    get
    {
      return orderLines;
    }
  }
}
Although this is a solution, I do not like it.
Now, we're unable to force the user to use the AddOrderLine method.  Since the OrderLines collection is now publicly exposed, it is now possible to just use the Add method of the List to add OrderLines to the Order.
The documentation of the classes could of course mention that you should always use the AddOrderLine method, but there's no real hard constraint here.  (If the classes are used inappropriatly, the program could of course crash, so then there is a constraint after all. ;)  However, then the programmer using those classes will maybe lose a lot of time to detect the error he made.
Another solution is to keep the OrderLines collection private, and to add some extra members to the Order class.  In this way, uncontrolled access to the OrderLines is not possible.
However, there are offcourse disadvantages to this approach as well.  First of all, you'll have to write some tedious code that just delegates the functionality to the Collection class, like this:
public class Order
{
  private List<OrderLine> orderLines = ...

  public void AddOrderLine( OrderLine ol )
  {
    ol.OwningOrder = this;
    orderLines.Add (ol);
  }

  public int NumberOfOrderLines
  {
    get
    {
      return orderLines.Count;
    }
  }
}
Unnecessary to say that this is just a boring task.
Then, to be able to iterate through the OrderLines of an Order, you could write code like this:public class Order
{
  private List<OrderLine> orderLines = ...

  ...

  public OrderLine[] GetOrderLines()
  {
    return orderLines.ToArray();
  }
}
Actually, I think this is plain ugly.
I always have to make a choice between these 2 approaches, where each one has his disadvantages.  After doing this too much, I wanted a better solution for this problem, and after some reading and experimenting, I finally found one.  It is in fact such a simple solution that I can't imagine why I haven't been using this one much earlier...
It's just nothing more then this:
Keep the collection private, create the necessary methods to provide the necessary controlled access to the collection (for instance the AddOrderLine method, and create a public property which returns a read-only instance of the collection, so that you can iterate through the collection, change existing instances of objects within the collection (at least, this is only true if you have reference types in the collection; you will not be allowed to modify value types on a ReadOnlyCollection, get the number of objects that are in the collection, ...

In code, it looks like this:
class Order
{
  private List<OrderLine> orderLines =
    new List<OrderLine>();

  public void AddOrderLine( OrderLine ol )
  {
    ol.Order = this;
    orderLines.Add (ol);
  }

  public ReadOnlyCollection<OrderLine> OrderLines
  {
    get
    {
      return orderLines.AsReadOnly();
    }
  }

}
This is the C# 2.0 version.  
Now, it is impossible to add OrderLines in an uncontrolled way, but it is possible to iterate the OrderLines that are in the collection, and modify existing OrderLine objects that are already in the collection (since it are instances of a reference type; if OrderLine was a struct, it would not be possible to modify them.

In C# 1.x, it looks like this:class Order
{
  private IList orderLines = new ArrayList();

  public void AddOrderLine( OrderLine ol )
  {
    ol.Order = this;
    orderLines.Add (ol);
  }

  public IList OrderLines
  {
    get
    {
       return ArrayList.ReadOnly (orderLines);
    }
  }
}
Here, I return a readonly copy of the ArrayList.  It is still possible to iterate and change the items that are in the collection, but it is impossible to Add an OrderLine to the Order in an uncontrolled fashion like this:Order o = new Order();
OrderLine ol = new OrderLine();
o.OrderLines.Add (ol);
In this case, a System.NotSupportedException will be thrown.
It would of course be nicer to not have an Add and Remove method on the read-only ArrayList property, like we've achieved in the C# 2.0 version (the ReadOnlyCollection class does not have Add and Remove methods).  
In .NET 1.x we can achieve that by letting the property return an ICollection instead of an IList, however, then we're not able to use an indexer to retrieve an OrderLine like this:OrderLine ol = theOrder.OrderLines[i] as OrderLine;
Therefore, I prefer to return an IList instead of an ICollection



1 month ago....
2006-08-27T12:14:00.000+02:00
... I was still in Spain.  
Surely, the weather was much better there then it is now here in Belgium and every evening, we could enjoy a beautiful sunset:

 



WinFX == .NET 3.0 ?
2006-08-23T20:14:00.000+02:00
Scott Bellware makes an excellent point here, when he says that Microsoft should not rename WinFX to .NET 3.0.
I can only agree with him that it will be confusing to rename WinFx to .NET 3.0, since WinFx is another product.
WinFX is just an API, while .NET is a platform, so, why giving an API the name of a platform ?

Anyway, I'm not going to repeat all of it here, so, if you also think that Microsoft will be making a huge mistake here, you should sign the petition.


DDD: A Quickstart - Part III
2006-08-19T22:20:00.000+02:00
Introduction
This is the 3rd post of a serie of posts on Domain Driven Design and Test Driven Development.
In this article, I'll continue from where the previous article ended.  This means that I'll continue with the implementation of the Domain Model that was defined in the first article of this serie.
In the previous article, we tackled the functionality of Customers placing Orders, and Gold Customers receiving a discount.
In this article, I'll focus on the behaviour for Bad Paying Customers and the creation of Invoices.


Bad Paying Customers
Now that we can determine whether a Customer is a 'Gold' Customer or not, we should build the functionality to determine whether a Customer is a bad payer or not. 
Just like I've done for the 'Gold Customer' case, I'd like to kick off with writing a small unit-test. 

A Customer is tagged as a bad paying Customer when 1/3 of his invoices are overdue/payed too late. The consequence of being a bad paying Customer is, that such a Customer cannot place Orders whose OrderTotal exceeds 250 euro. The test looks like this:
public void TestBadPayingCustomerPlacesOrder()
{
  Customer c = custRep.GetCustomer (3);

  // We 'know' that Customer 3 is a bad paying Customer.
  // To check this, we can check the 
  // Status of the Customer. 
  Assert.AreEqual (CustomerStatus.BadPayer, 
    c.Status, 
    "This should be a bad paying Customer.");

  // Get the Articles that we'll need.
  Article art1 = artRep.GetArticle (1);
  Article art2 = artRep.GetArticle (2);

  // Check the prices of the articles, so that we 
  // do not make any false assumptiosn here.
  Assert.AreEqual (15M, art1.Price, 
    "The 1st Article should have a unit-price of 15eur.");
  Assert.AreEqual (12.5M, art2.Price, 
    "The 2nd Article should have a unit-price of 12.5eur.");

  // Create the Order...
  Order o = c.CreateNewOrder();

  // and add the order-lines.
  OrderLine ol1 = o.CreateNewOrderLine();
  ol1.SetArticle (art1);
  ol1.NumberOfItems = 10;

  OrderLineAddQueryResult result = o.CanOrderLineBeAdded (ol1);
  
  Assert.AreEqual (OrderLineAddQueryResult.Yes, 
    result, 
    "The 1st OrderLine should pose no problem.");

  // At this time, the OrderTotal should be 150eur.
  Assert.AreEqual (150M, 
    o.TotalAmountToPay, 
    "The OrderTotal should be 150eur.");

  // Create a 2nd OrderLine which will cause 
  // the Order-limit to be exceeded.
  OrderLine ol2 = o.CreateNewOrderLine();
  ol2.SetArticle (art2);
  ol2.NumberOfItems = 10;

  result = o.CanOrderLineBeAdded (ol2);

  Assert.AreEqual (
    OrderLineAddQueryResult.NoBecauseOrderLimitExceeded, 
    result,
    "Bad Paying Customers are not allowed to place orders > 250eur.");
}
Before we can make this test succeed, we must be able to compile it. This means that we'll have to extend the OrderLineAddQueryResult enumeration with the NoBecauseOrderLimitExceeded value. This is a simple task, and just a matter of adding this value to the enumeration type. This is in fact so simple, that I'm not going to elaborate on that here.
Once this is done, the test compiles, but it fails. This is due to the fact that we haven't implemented any functionality yet to determine whether a Customer is a bad paying Customer or not, so lets do that right away.
A Bad Paying Customer is a Customer that has at least one out of three overdue invoices. To be able to check this, we need to introduce a new entity: the Invoice.
Invoices are made for Orders that are shipped. An invoice contains a date when the Invoice has been created, and a due-date. Offcourse, it also contains the list of Articles that have been ordered and where the Customer has to pay for, and, it contains the amount that the Customer has to pay. 
Since Invoices are created from Orders that have been shipped, we can start with this unit-test:
[Test]
public void CreateInvoice()
{
    Order o = orderRepository.GetOrder (2);

    Invoice inv = o.CreateInvoice();
}
This is rather simple!  But simple is good.

As we can learn from the test, we'll need an Invoice entity, and we'll need to write a CreateInvoice method in the Order class.
Let's start off with the new entity.  The Invoice class contains these members:
public class Invoice
{
  private int id;
  private DateTime invoiceDate;
  private DateTime dueDate;
  private Customer owningCustomer;
  private InvoiceStatus status;
  private bool isOverdue;
  private DateTime datePayed;
  private decimal subTotal;
  private decimal discount;
  private IList invoiceLines = new ArrayList();

  public int Id
  {
    get
    {
      return id;
    }
  }

  public DateTime InvoiceDate
  {
    get
    {
      return invoiceDate;
    }
  }

  public DateTime DueDate
  {
    get
    {
      return dueDate;
    }
    set
    {
      dueDate = value;
    }
  }

  public Customer OwningCustomer
  {
    get
    {
      return owningCustomer;
    }
  }

  public InvoiceStatus Status
  {
    get
    {
      return status;
    }        
  }

  public bool IsOverdue
  {
    get
    {
      return isOverdue;
    }
    internal set
    {
      isOverdue = value;
    }
  }

  public DateTime DatePayed
  {
    get
    {
      return datePayed;
    }
  }

  public decimal SubTotal
  {
    get
    {
      return subTotal;
    }
  }

  public decimal Discount
  {
    get
    {
      return discount;
    }
  }
}
An Invoice should not be created directly by the user of our Domain classes, so it's not necessary (and not favorable) to have a public constructor in this class. Therefore, I've decided to create an internal constructor. An Invoice is also created for one Order, so the constructor can take the Order for which the invoice is created, as an argument. Then, the constructor and it's implementation looks like this:
public class Invoice
{
  ...

  internal Invoice( Order o, DateTime invoiceDate, DateTime dueDate )
  {
    id = -1;
    this.invoiceDate = invoiceDate;
    this.dueDate = dueDate;
    owningCustomer = o.OwningCustomer;
    status = InvoiceStatus.Open;
    isOverdue = false;
    subTotal = o.OrderTotal;
    discount = o.Discount;

    foreach( OrderLine ol in o.OrderLines )
    {
      AddInvoiceLine (ol.ArticleId, 
        ol.ArticleName, 
        ol.ArticlePrice, 
        ol.NumberOfItems);
    }
 }
}
The AddInvoiceLine method will add an InvoiceLine object to the invoiceLines collection for each OrderLine object that is contained by the Order:
private void AddInvoiceLine( int articleId, 
  string articleName, 
  decimal articlePrice, 
  int numberOfItems )
{
  invoiceLines.Add (
    new InvoiceLine (this, articleId, 
      articleName, articlePrice, numberOfItems));
}
An InvoiceLine object contains information about the article for which the Customer has to pay, and, offcourse, it contains a pointer to the Invoice to which it belongs.
The CreateInvoice method should also be implemented.  This is quite simple; in this method, we'll just use the internal constructor of the Invoice class, and we can also check if the Order has been shipped, since it is not allowed to create Invoices for Orders that haven't been shipped.
public class Order
{
  ...
  public Invoice CreateInvoice()
  {
    if( this.Status != OrderStatus.Shipped )
    {
      throw new ApplicationException ("The order hasn't been shipped yet.");
    }

    return new Invoice (this, DateTime.Now, DateTime.Now.AddDays (30));
  }
}
As you can see, the dueDate for the Invoice is calculated in this method. By default, the Customer has 30 days time to pay his invoice. 
Since this logic is quite simple, it can safely be placed inside the CreateInvoice method. If the calculation of the due date would becomes more complicated, we could opt to factor this logic into a specification object.

Once the InvoiceLine class is implemented and the CreateInvoice method has been written, the tests compile.  However, the first test still fails, because we still have no functionality written to determine if a Customer is a bad payer.
To do this, we can extend the Status property of the Customer class.
public CustomerStatus Status
{
  get
  {
    CustomerStatus result = CustomerStatus.Normal;

    // First get the amount of orders this 
    // customer has made in the last 3 months.
    decimal orderTotal = DomainSettings.Instance.
                           RepositoryFactoryObj.
                           CreateOrderRepository().
                           GetOrderTotalForCustomerSinceDate (this,
                            (DateTime.Now.AddMonths (-3));
                                                          
    if( orderTotal > DomainSettings.GoldAmountTreshold )
    {
      result = CustomerStatus.Gold;
    } 

    // Check if the Customer is a bad Payer, 
    // if the Customer is a Gold Customer AND a bad payer, 
    // the Status should be 'Bad Payer'.
        
    // Get the number of invoices for this customer, 
    // and get the number of overdue invoices.
    IInvoiceRepository invRep =   
      DomainSettings.Instance.
                     RepositoryFactoryObj.
                     CreateInvoiceRepository();

    int numberOfOverdueInvoices = 
      invRep.GetNumberOfOverdueInvoicesForCustomer (this);
                                          
    if( numberOfOverdueInvoices > 0 )
    {
      int totalInvoices = invRep.GetNumberOfInvoicesForCustomer (this);
                                    
      if( numberOfOverdueInvoices / totalInvoices > 0.333 )
      {
        result = CustomerStatus.BadPayer;
      }
    }

    return result;
  }
}
In order to get this code to compile, the IInvoiceRepository interface and an implementation of it have to be created:
public interface IInvoiceRepository
{
  int GetNumberOfOverdueInvoicesForCustomer( Customer c );
  int GetNumberOfInvoicesForCustomer( Customer c );
}
I'll also create an InvoiceMemoryStoreRepository for the test-cases in the project that contains the unit-tests, and I'll extend the IRepositoryFactory interface (and the classes that implement this interface) with a method that creates the correct IInvoiceRepository. 
Once that is done, the CanOrderLineBeAdded member method of the Order class needs to be extended, so that we check if a Customer is allowed to add the OrderLine to it's Order. This means that we'll have to adapt the Order class a bit. 
First of all, I'd like to change the isGoldCustomer boolean member that acted as some kind of a helper variable, in order that we do not have to check the Status property of the OwningCustomer (because checking this status can be considered as expensive). 
I want to do that because it is not sufficient any more to know if the 'owning customer' of the order, is a Gold Customer or not; now, I want to know whether the customer is a Normal Customer, a Gold Customer or a Bad Payer. Therefore, I removed the isGoldCustomer member variable, and changed it to a customerStatusHelper member, that is of type CustomerStatus. 
I've put the code that has to keep track of the CustomerStatus into a separate method that looks like this:
private void DetermineCustomerStatus()
{
  customerStatusHelper = owningCustomer.Status;
  customerStatusDetermined = true;
}
Then, the CalculateDiscount() member method of the Order class has to be changed as well:
private void CalculateDiscount()
{
  if( customerStatusDetermined == false )
  {
    DetermineCustomerStatus();
  }

  if( customerStatusHelper == CustomerStatus.Gold )
  {
    _discount = OrderTotal * 5 / 100;
  }
  else
  {
    _discount = 0M;
  }
}
Although this is a rather small refactoring, thanks to our unit-test, we can be assured that our code is still correct.

Now, we can add a test to the CanOrderLineBeAdded member method to check whether the 'OrderLimit' is exceeded, when a Customer who's a Bad Payer, makes an Order:
public OrderLineAddQueryResult CanOrderLineBeAdded( OrderLine ol )
{
  OrderLineAddQueryResult result = OrderLineAddQueryResult.Yes;
  
  if( customerStatusDetermined == false )
  {
    DetermineCustomerStatus();
  }

  if( customerStatusHelper == CustomerStatus.BadPayer )
  {
    if( this.TotalAmountToPay + ol.LineTotal > 
        DomainSettings.BadPayerOrderLimit )
    {
      result = OrderLineAddQueryResult.NoBecauseOrderLimitExceeded;
    }
  }

  // the other checks that were shown before, are now not shown any more.
  ...
  ...

  return result;

}
The GetReasonWhyOrderLineCantBeAdded needs to be extended as well, but I'm not going to discuss that.
Creating Invoices
Until this time, we're still unable to create Invoices for Orders that are shipped. As discussed earlier, creating Invoices from shipped Orders would best be implemented as a Service. 
This 'Domain Service' can then be used by a Windows Service, so that this task is done every night. The CreateInvoices service should use an IOrderRepository to get all the Orders that are shipped, and for which no Invoice has been created yet.
For those Orders, the service should create Invoices. Given the text, the service should look like this:
public static class CreateInvoicesService
{
  public static void CreateInvoices()
  {
    IOrderRepository ordersRep = 
      DomainSettings.RepositoryFactoryObj.CreateOrderRepository();
    IInvoiceRepository invoiceRep = 
      DomainSettings.RepositoryFactoryObj.CreateInvoiceRepository();

    IList orders = ordersRep.FindShippedOrdersWithoutInvoice();

    foreach( Order o in orders )
    {
      Invoice inv = o.CreateInvoice();
      invoiceRep.Save (inv);            
    }
  }
}
This is pretty straightforward. However, there is something that we haven't considered yet: transaction handling/boundaries.
The Repository itself should not be responsible for starting and committing or rollbacking transactions.
The Repository is not aware of the context of the transaction, so therefore, it is not the task of the repository to start and commit a transaction. Only the client knows when to start and commit a transaction, so it's his responsability. In this case, it's the CreateInvoicesService service that is responsible for starting and committing (or rollbacking) the transaction.
But since we haven't focused on persistence yet, we'll just keep this in the back of our mind. 
Now that we're able to create Invoices, we're still not able to determine whether an Invoice is overdue or not. This batch-process should also be implemented as a service.
An IInvoiceRepository should be used that gives us all Invoices that haven't been payed yet.
Then, each Invoice that has been returned can be checked by a Specification class if the Invoice is overdue or not. If the Invoice is overdue, the IsOverdue flag can be set, and the Invoice can be persisted. If the logic to determine whether the Invoice is overdue or not would be complicated, and depend on several other factors (like, for instance the CustomerStatus of the Customer), then this would be a good solution.
In this case however, things are quite simple: an Invoice is overdue if it is past its duedate (however, we could allow a retention period of say 4 days). This means that marking all Invoices that are past their due date as overdue, could be done be just one query. In other words, the MarkOverdueInvoices Service could be as simple as just calling a method on the IInvoiceRepository:
public static class MarkOverdueInvoicesService
{
  public static void MarkOverdueInvoices()
  {
    IInvoiceRepository invRep = 
      DomainSettings.RepositoryFactoryObj.CreateInvoiceRepository();

    invRep.MarkOverdueInvoices();
  }
}
So, I think that's about it. I think we've discussed the most important part of the Domain. Now, we can concentrate on the persistance of the objects in a relation database. For more information about test driven development, you can read these guidelines, written by Jeffrey Palermo.
That's it for now.  In the next article (if it ever comes, since I still have to start writing...) of this series, I'll try to tackle the persistence functionality using NHibernate.



New photography toy!
2006-08-07T22:26:00.000+02:00
I was planning to blog about this, but I constantly postponed it until I almost forgot about it.  And how could I forget this...  
After years of using only a film-camera, I've finally decided to go digital.  Well, I'm not really telling the truth here, since I already own a digital compact camera since 2003.
Anyway, I finally decided to buy a digital SLR camera.  Since I already have a Nikon F55 film SLR, the choice was easy: my digital SLR would also be a Nikon.
After reading some reviews and testing different models, I've made a decision on the model as well: it would be a Nikon D200.
I've ordered the camera in May 2006, and I got it in my hands in the first week of July 2006.
I have the D200 now for about one month, and it is a great camera.  I've done about 1000 shots in past month, and although I've already achieved some satisfying results, I feel that I haven't unleashed its full potential yet.
I hope that I'll be able to show the progress I make by regularly posting a photo here on my blog.
Here you see my F55 film camera next to the D200.  Quite a difference in size!
Image taken with a compact digital camera





This is the end....
2006-08-06T19:21:00.000+02:00
... of my holiday.
The last day of my holiday is coming to an end.  This means that, as from tomorrow, I'll be spending most of my time behind my workstation at work, developing in .NET.
I've had a nice 3 weeks of vacation wich have passed very fast, which is a good sign: it means that I haven't bored myself. :)
My girlfriend and I made a trip to Spain, continued our search for a suitable and affordable piece of terrain where we could build a house.  Hopefully, that quest will come to an end soon, because it becomes quite exhausting.
Next to that, I've read some books, and I've continued reading Applying Domain Driven Design and Patterns, and so far, I find it a very good book.
I've also spent some time preparing for a session about Unit Testing and Test Driven Design wich I'm planning to do in the near future at work.
I hope to finish those preparations very soon, so that I can concentrate on the next episode of my blog article regarding Domain Driven Design.
I think I can say that the past 3 weeks were well spent, and I'll be ready to get back to work with a fresh, relaxed mind.



Back in Belgium
2006-07-31T20:15:00.000+02:00
I'm back from vacation.

I've spent the past few days in Southern Spain, in the province of Andalucia.
We stayed in a hotel nearby the 'La Barossa' beach, from where we've explored the nearby region a bit.


This picture has been taken in Medina Sidonia.  A 'pueblo blanco' (white town), a few km's more inward the country.



DDD: A Quickstart - Implementation using Test Driven Development
2006-07-18T22:53:00.000+02:00
Introduction

In the first part of this serie, I've focussed on the modelling of the domain-model.
Now, since the entities, aggregates, etc... have been roughly defined in the first part, I think it's time to dive into the code.
Instead of directly writing classes to model the domain, I want to develop the domain layer using the Test Driven Development Mantra.
This means that I should start with writing a test case before I actually write the 'functional' code.  
I will develop the domain using C#, so I'll use the NUnit Framework to create the unit tests.
A first use case

It would be helpfull to have some kind of a use case, so that I can start with writing a test for that use case.
I can start off with the use case that can be found in part 1 of this article:
A customer places an order.
By writing a unit test for this scenario first, I'm forced to think about the class interfaces.  Writing the test first, will help me in creating a clear, simple and easy to use class interface and class hierarchy since I will design the classes in the way that I want to use them.
The Unit Test for the use case 'Customer places an Order' looks like this:
[TestFixture]
public class OrderTestCase
{
  [Test]
  public void TestNormalCustomerPlacesOrder()
  {
    ICustomerRepository custRep = 
      new CustomerMemoryStoreRepository();
    IArticleRepository artRep = 
      new ArticleMemoryStoreRepository();

    // Get a customer from the repository.  We should
    // make sure that this customer is a normal customer.
    Customer c = custRep.GetCustomer (1);

    // Create a new order for the Customer.
    Order o = c.CreateNewOrder ();

    // The Customer orders some articles...
    Article art1 = artRep.GetArticle (1);
    Article art2 = artRep.GetArticle (2);
    OrderLine ol1 = o.CreateNewOrderLine();
 
    ol1.NumberOfItems = 2;
    ol1.SetArticle (art1);

    o.AddOrderLine (ol1);
    OrderLine ol2 = o.CreateNewOrderLine();
        
    ol2.NumberOfItems = 5;
    ol2.SetArticle (art2);

    o.AddOrderLine (ol2);

    // Now, the order-total should be equal
    // to ( 2 * price of art1 ) + ( 5 * price of art2 )
    Assert.AreEqual ((2 * art1.Price ) + ( 5 * art2.Price ),
                      o.OrderTotal );

  }
}
This first test is pretty simple.  It shows how a Customer can place an Order, and it checks if the OrderTotal of the Order is correct.
While this test case is very simple, you can already discover the advantage of Test Driven Development: by writing a Test first, I've already defined the API, the interface of the domain classes.  This will make sure that the interface of those classes will be clear and intention revealing.
By writing the test first, you're forced to design the classes in a way where it's easy to use them.  I think the above test is quite self-describing and doesn't need any further explanation.
Now, we should make the test pass.  However, I know that good TDD practice preaches that you should make sure that the test fails first meaningfully.  This is actually a quite important step, because it enables you to make sure that you know that what you're testing is correct.   However, to keep this article a little bit more concise, I've allowed myself to skip this step.
At this point the test fails offcourse since we haven't written any functional code yet, so lets start with that right away.
The first thing that you encounter, is the ICustomerRepository and the IArticleRepository interface, along with the CustomerMemoryStoreRepository and ArticleMemoryRepository classes which implement these interfaces.
For this test, it is sufficient that the ICustomerRepository and the IArticleRepository interfaces look like this:

public interface ICustomerRepository
{
    Customer GetCustomer( int customerId );
}

public interface IArticleRepository
{
    Article GetArticle( int articleId );
}
The CustomerMemoryStoreRepository and the ArticleMemoryStoreRepository class are not a part of the Domain Layer.  These classes are 'mock objects' that live in the assembly that contains the test cases.  They do not really access a database, they just hold some objects in memory.
Then, let's get along with the Customer class.  To be able to make the above test pass, it would be sufficient that the Customer class only has a CreateNewOrder() method at this point.  However, we also want to identify a customer (it is an entity), so let's give it a name and an id as well.
This should be the implementation of the Customer class:

public class Customer
{
    private int _id;
    private string _name;

    public Customer() : this(-1, string.Empty)
    {
    }

    public Customer( int id, string name )
    {
        _id = id;
        _name = name;
    }

    public int Id
    {
        get
        {
            return _id;
        }
    }

    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }

    public Order CreateNewOrder()
    {
        return new Order(this);
    }
}
The CreateNewOrder method creates a new Order, and passes the current Customer object as an argument.  This is necessary so that we know to which Customer an Order belongs.
Since we have a reference to the Order class in the Customer class, lets continue with writing the Order class.
Since an Order is also an entity, we will want to uniquely identify an Order as well, so we're going to add an Id to this class as well.  Next to that, we also want to know when the Order was made, so let's give the Order class an OrderDate member as well.

public class Order
{
    private int _id;
    private DateTime _orderDate;
    private Customer _customer;
    private IList _orderLines = new ArrayList();

    public Order( Customer c ) : this(-1, c, DateTime.Now)
    {
    }

    public Order( int id, Customer c, DateTime orderDate )
    {
        _id = id;
        _customer = c;
        _orderDate = orderDate;
    }

    public int Id
    {
        get
        {
            return _id;
        }
    }

    public DateTime OrderDate
    {
        get
        {
            return _orderDate;
        }
    }

    public Customer OwningCustomer
    {
        get
        {
            return _customer;
        }
    }

    public IList OrderLines
    {
        get
        {
            return _orderLines;
        }
    }

    public decimal OrderTotal
    {
        get
        {
            decimal total = 0.0M;
  
            foreach( OrderLine ol in _orderLines )
            {
                total += ol.NumberOfItems * ol.ArticlePrice;
            }

            return total;
        }
    }

    public OrderLine CreateNewOrderLine()
    {
        return new OrderLine (this);
    }

    public void AddOrderLine( OrderLine ol )
    {
        // Perform some checks before adding.
        if( ol.IsArticleSet == false )
        {
            throw new ApplicationException ("You must specify an Article.");
        }
        
        if( ol.NumberOfItems == 0 )
        {
            throw new ApplicationException ("You must order at least one item.");
        }

        _orderLines.Add (ol);
    }    
}
Note that I've used an IList for the _orderLines member, and not the generic IList<T> type which would provide strong typing.  The reason why I did this, is that I'm planning to use NHibernate as an O/R mapper between the domain classes and the relational database, and the version of NHibernate that I have now does not support generics yet.
I think the Order class is pretty straightforward and doesn't need any further explanation.  I think the code is pretty self-explaining.

The OrderLine and Article class haven't been created yet, so let's do that right now.

public class OrderLine
{
    private int _id;
    private int _articleId;
    private string _articleName;
    private decimal _articlePrice;
    private int _numberOfItems;
    private Order _owningOrder;
    private bool _isArticleSet;

    public int Id
    {
    }

    internal bool IsArticleSet
    {
        get
        {
            return _isArticleSet;
        }
    }

    public int ArticleId
    {
        get
        {
            return _articleId;
        }
    }

    public string ArticleName
    {
        get
        {
            return _articleName;
        }
    }

    public decimal ArticlePrice
    {
        get
        {
           return _articlePrice;
        }
    }

    public int NumberOfItems
    {
        get
        {
            return _numberOfItems;
        }
        set
        {
            _numberOfItems = value;
        }
    }

    public Order OwningOrder
    {
        get
        {
            return _owningOrder;
        }
    }

    public OrderLine( Order owningOrder )
    {
        _owningOrder = owningOrder;
        id = -1;
        _articlePrice = 0.0M;
        _articleName = string.Empty;
        _numberOfItems = 0;
    }


    public void SetArticle( Article art )
    {
        if( art != null )
        {
            _articleId = art.Id;
            _articleName = art.Name;
            _articlePrice = art.Price;
            _isArticleSet = true;
        }
        else
        {
            _articleId = -1;
            _articleName = string.Empty;
            _articlePrice = 0.0M;
            _isArticleSet = false;
        }
    }
}
I've decided to not put a reference to an Article object in the OrderLine class, because, when an existing Order is retrieved, the price of the Article can already have changed opposed to the price of the Article at the time the Order was made.  So, we're not interested in the current price of the Article, but in the price of the Article at the time when the Customer has ordered that Article.
Therefore, I've decided to just put the Article information that is of interest into the OrderLine class, and make that information available through read-only properties.  I've created a SetArticle method so that all the required Article information can be set at once, and in this way, we're sure that the Article information in the OrderLine class is correct.
The IsArticleSet flag is marked internal since it is of no use outside our domain-assembly.  At this time, only the Order class uses it to check if the OrderLine that's being added has an Article set.
The Article class is very simple:

public class Article
{
   private int _id;
   private string _name;
   private decimal _price;

    public int Id
    {
        get
        {
            return _id;
        }
    }

    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }

    public decimal Price
    {
        get
        {
            return _price;
        }
        set
        {
            _price = value;
        }
    }

    public Article() : this(-1, string.Empty, 0.0M)
    {
    }

    public Article( int id, string name, decimal price )
    {
        _id = id;
        _name = name;
        _price = price;
    }
}
This code now makes sure that the test we've written passes.   However, as I've said earlier, if I was to follow the TDD rules strictly, I should write code first that makes the test fail meaningfully.  I've chosen to skip this step though, so that I can make this post a little bit shorter.

At this stage, we have the functionality that we need for a Customer to place Orders.  However, we're not there yet.  The code we have now, does not take 'Gold Customers' and 'Bad Paying Customers' into account.

Test Case for Gold Customers

To implement the functionality which gives Gold Customers a discount, I'll start of with writing a Unit Test again.  This test is pretty similar as the previous one, but you should note that the Repositories are now promoted to be member variables of the class that contains the test-methods.
This is how the test looks like:

[Test]
public void TestGoldCustomerPlacesOrder()
{
  // 2 is a gold-customer..
  Customer c = custRep.GetCustomer (2); 

  // To be sure of it, test it...
  Assert.IsTrue (c.Status == CustomerStatus.Gold, 
                 "We should have a gold customer.");

  Order o = c.CreateNewOrder ();

  Article art1 = artRep.GetArticle (1);
  Article art2 = artRep.GetArticle (2);

  OrderLine ol1 = o.CreateNewOrderLine ();

  ol1.SetArticle (art1);
  ol1.NumberOfItems = 10;

  o.AddOrderLine (ol1);

  OrderLine ol2 = o.CreateNewOrderLine ();

  ol2.SetArticle (art2);
  ol2.NumberOfItems = 7;

  o.AddOrderLine (ol2);

  // The expected OrderTotal is the 'regular'
  // OrderTotal minus a 5% discount.
  decimal expected = ( 10 * art1.Price ) + ( 7 * art2.Price );
  expected -= ( expected * 5 ) / 100;

  Assert.AreEqual (expected, o.TotalAmountToPay);
}
In the above test, I retrieve the Customer with Id 2 out of the Repository.  I assume that this is a Gold Customer, and, to be sure, the Status property of the Customer is tested.
Note that I haven't defined this property in the first version of the Customer class since there was no need for that property in the first unit test.  This means that I'll have to extend the Customer class with a Status property.
This Status property will return an enumeration-type which indicates whether this Customer is a 'Normal', 'Gold' or 'Bad Paying' Customer.  This also implies that I'll have to create that enumeration type.

Let's start of with creating the enumeration type, and adding the Status property to the Customer class.  The enumeration is very simple:

public enum CustomerStatus
{
  Normal,
  Gold,
  BadPayer
}
Determining the correct Status of a Customer requires a bit more work.  First of all, we need to determine whether the Customer is a 'Gold Customer'.  We'll have to do this by getting the total amount of money that a Customer has spent on Orders in the last 3 months.  Since the Customer class does not contain a collection of the Orders that he made, we'll have to ask a Repository what that amount is for a specific Customer.
If this amount is over 2500 euro, the Customer is a Gold Customer.
To determine whether the Customer is a bad payer, we should do something similar; we'll need to know how many of his invoices have been or are overdue.  To be able to know this, we'll also have to call in a repository.
In a first case, I'll concentrate on determining whether a Customer is a Gold Customer or not.
To do this, I'll have to extend the Customer class with the Status property:

public class Customer
{
  ...

  public CustomerStatus Status
  {
    get
    {
      CustomerStatus result = CustomerStatus.Normal;

      // First get the amount of orders this 
      // customer has made in the last 3 months.
      decimal orderTotal = DomainSettings.Instance.
                             RepositoryFactoryObj.
                             CreateOrderRepository().
                             GetOrderTotalForCustomerSinceDate (this,
                              (DateTime.Now.AddMonths (-3));
                                                          
      if( orderTotal > DomainSettings.GoldAmountTreshold )
      {
        result = CustomerStatus.Gold;
      }

      return result;
    }
  }
  
  ...

}
This code is pretty straightforward I guess.  First of all, we assume that the Customer is a Normal Customer.  Then, I 'ask' the OrderRepository to give me the total amount for which the given Customer has placed Orders in the last 3 months.   If this value is higher then a specific value, we can say that this Customer is a Gold Customer.
To be able to compile and run this code, we'll need some additional classes.
The first new class that springs into view, is the DomainSettings class, which appears to be a singleton.
I've decided to create this class to get easy access to things like repositories, and usefull constants, like the GoldAmountTreshold property.  The DomainSettings class looks like this:

public class DomainSettings
{
  private static DomainSettings _instance;

  public static DomainSettings Instance
  {
    get
    {
      if( _instance == null )
      {
        _instance = new DomainSettings();
      }
      return _instance;
    }
  }

  public const decimal GoldAmountTreshold = 2500;

  private IRepositoryFactory _repositoryFactoryObj;

  public IRepositoryFactory RepositoryFactoryObj
  {
    get
    {
      if( _repositoryFactoryObj == null )
      {
        object repType = Configuration.
                           ConfigurationManager.
                           AppSettings["repositorytype"];

        if( repType != null )
        {
          switch( repType.ToString().Trim().ToLower() )
          {
            case "testrepositories" :
              // Since I've put the 'test/mock' 
              // repositories in another assembly, 
              // along with my unit-tests, 
              // use reflection to load 
              // the correct assembly and type.
              Assembly asm = Assembly.LoadFrom ("BlogShopTests.dll");
              object o = asm.CreateInstance
                          ("BlogShopTests.RepositoryMocks.TestRepositoryFactory", 
                           true);
              _repositoryFactoryObj = o as IRepositoryFactoryObj;           
              break;
            default :
              throw new ConfigurationErrorsException (
                "Unknown repository-type: " + repType.ToString());
          }   
        }
        else
        {
          throw new ConfigurationErrorsException (
            "Repository type must be defined in the app-settings.");
        }
      }
      return _repositoryFactoryObj;
    }
  }
}
As you can see, I've implemented the DomainSettings class as a singleton, so that there can only be one instance of that class.  The most interesting thing in this class is without any doubt the RepositoryFactoryObj property.
Since the unit-tests I've written so far are using 'mock' repositories instead of the real ones that will be used eventually, I wanted to be able to hide which implementation of the Repository that should be used.  This is extremely usefull in the Status property of the Customer class.  When running the tests, the 'mock' repositories should be used, and, when running the code 'for real', the 'real' Repository should be used.
To be able to do this, I've provided the DomainSettings class with a property that returns a Factory that will create the correct repository objects.
The concrete type of the factory that must be used, depends on a value in the configuration file.
Since the TestRepositoryFactory and the TestRepositories are in the assembly that contains all the unit-tests, and since I do not want to create a dependency between the assembly that contains the Domain classes, and the assembly that contains the test classes, I use reflection to create the TestRepositoryFactory.  The Abstract Factory approach for the creation of the Repositories, allows me to hide which specific factory is to be used.  In other words: the user -in this case the Customer class- is left unaware of which specific Factory that's being used and therefore, which specific repository that will be used.

To be able to create and use the abstract factory, an interface is needed which describes the methods that a 'RepositoryFactory' object must have.  In our client code, we can then talk to that interface without knowing which specific implementation is being used.
At this moment, it is sufficient if the interface looks like this:

public interface IRepositoryFactory
{
    ICustomerRepository CreateCustomerRepository();
    IOrderRepository CreateOrderRepository();
    IArticleRepository CreateArticleRepository();
}
Once this is done, the implementation of the TestRepositoryFactory is fairly easy; it just instantiates and returns an instance of the correct Repository:

public TestRepositoryFactory : IRepositoryFactory
{
    public ICustomerRepository CreateCustomerRepository()
    {
        return new CustomerMemoryStoreRepository();
    }

    public IOrderRepository CreateOrderRepository()
    {
        return new OrderMemoryStoreRepository();
    }

    public IArticleRepository CreateArticleRepository()
    {
        return new ArticleMemoryStoreRepository();
    }
}
In the DomainSettings class, it is now just a matter of creating the correct IRepositoryFactory object depending on the value that's found in the configuration file.
Once the GetOrderTotalForCustomerSinceDate is implemented, we're able to determine if the Customer is a Gold Customer or not.  The implementation of the GetOrderTotalForCustomerSinceDate method of the OrderMemoryStoreRepository could be as simple as just returning true if the given Customer has a specific Id, and otherwise false.

We still need to make our test pass, because at this point, we haven't written any functionality yet to calculate the OrderTotal for Gold Customers.  As we learn from the user story, Gold Customers receive a discount of 5% on their OrderTotal.
It is usefull to extend the Order class with a member variable that holds the discount.  For Normal Customers, this discount variable will just contain 0.
I think that the best place calculate the discount -if there's one-, is in the AddOrderLine method of the Order class.  Each time an OrderLine is added to an Order, the amount of the discount for a Gold Customer changes.
There's also something else were I haven't paid attention to yet: once an Order is confirmed by the Customer, it should not be possible to add or remove OrderLines from it. 
It is however possible that a user cancels the complete Order.  This pops up another issue: an Order should have an OrderStatus.
Let's start with one thing at a time, and begin with the calculation of the discount.
As I've said earlier, the best place to calculate this discount is in the AddOrderLine member method of the Order class.  Thus, we can extend this method so that it looks like this:

public void AddOrderLine( OrderLine ol )
{
  // Perform some checks here to see if all necessary stuff is provided.
  if( ol.NumberOfItems == 0 )
  {
    throw new ApplicationException ("You must at least order 1 item.");
  }

  if( ol.IsArticleSet == false )
  {
    throw new ApplicationException (
      "You must specify the article that must be ordered.");
  }
  
  this.OrderLines.Add (ol);

  // Calculate the discount.
  CalculateDiscount ();
}
In the CalculateDiscount method, we'll just have to check the Status property of the Customer to which the Order belongs to. However, since determining the Status of a Customer is a rather expensive operation (remember that we have to query the database to determine the status) and the fact that the AddOrderLine method is likely to be called more then one time (an Order can contain more then one OrderLine), it would be better to call this Status property only one time. We can do this like this:

private bool customerStatusDetermined = false;
private bool isGoldCustomer = false;

private void CalculateDiscount()
{
  if( customerStatusDetermined == false )
  {
    if( _owningCustomer != null )
    {
      isGoldCustomer = _owningCustomer.Status == CustomerStatus.Gold;
    }
    else
    {
      isGoldCustomer = false;
    }
    customerStatusDetermined = true;
  }

  if( isGoldCustomer )
  {
    _discount = this.OrderTotal * 
      DomainSettings.Instance.GoldDiscountPercentage;
  }
  else
  {
    _discount = 0M;
  }
}
I think that this code is pretty easy as well: the CustomerStatus is determined if this hasn't been done yet, and if the Customer is a Gold Customer, we calculate the discount on the Order.
Note that we'll have to add an extra property to the DomainSettings class as well, that contains the percentage of the discount for Gold Customers:

public class DomainSettings
{
  ...
  private decimal _discountPercentageForGoldCustomers = 0.05M;

  public decimal GoldDiscountPercentage
  {
    get
    {
      return _discountPercentageForGoldCustomers;
    }
  }
}
You should also note that the Test that has been written to test the 'Gold Customer' case, checks the TotalAmountToPay property of the Order class.   This property is quite simple, and just returns the OrderTotal minus the Discount

public class Order
{
  ...
  public decimal TotalAmountToPay
  {
    get
    {
      return OrderTotal - Discount;
    }
  }
  ...
}
This functionality makes our 2nd test pass.  Now, I've already talked about  the fact that an Order should have a Status.   This means that, when a Customer confirms his Order, the Order should have the status 'Confirmed'.  Orders that have been confirmed cannot be changed anymore.  This means that it should be impossible to add or remove OrderLines from it.  However, a Customer should be able to cancel a confirmed Order.  However, once the Order is shipped, it cannot be cancelled anymore.
Knowing all this, we can say that an Order can have 3 states:

Confirmed

Cancelled

Shipped

However, this is not sufficient.  When an Order is just created, it cannot have the Confirmed, Cancelled or Shipped status.  As long as the Order has not been confirmed yet, it has the status 'Pending'.  This means that we have in fact 4 OrderStates:
Confirmed

Cancelled

Shipped

Pending
We can now start to create some unit-tests in where we will test this behaviour.  First of all, we'll create a unit-test in where we create an Order, add some OrderLines to the Order and confirm the Order.  Afterwards, we'll check if we can still add or remove OrderLines from that Order.

[Test]
public void TestConfirmOrder()
{
  Customer c = custRep.GetCustomer (1);

  Article art1 = artRep.GetArticle (1);
  Article art2 = artRep.GetArticle (2);

  Order o = c.CreateNewOrder();

  OrderLine ol1 = o.CreateNewOrderLine();
  ol1.SetArticle (art1);
  ol1.NumberOfItems = 5;
  o.AddOrderLine (ol1);

  o.ConfirmOrder();

  Assert.AreEqual (OrderStatus.Confirmed, 
    o.Status, 
    "The OrderStatus should be confirmed.");

  // Now, the Order is confirmed, so it should not be 
  // possible to still add or remove
  // OrderLines
  OrderLine ol2 = o.CreateNewOrderLine ();
  ol2.SetArticle (art2);
  ol2.NumberOfItems = 10;
 
  Assert.AreEqual (o.CanOrderLineBeAdded (ol2), 
    OrderLineAddQueryResult.NoBecauseOrderIsConfirmed,
    "It should not be possible to add an orderline now."); 
   
  // Now, just check what if the Status is correct if we cancel the order.
  o.CancelOrder ();

  Assert.AreEqual (OrderStatus.Cancelled, 
    o.Status, 
    "The OrderStatus should be cancelled.");
}
To be able to compile this test, we'll have to add some methods to our classes.
The first one that we encounter, is the ConfirmOrder method, which sets the status of our Order to Confirmed.  This means that we'll have to add a property Status to the Order class and create an enumerated type OrderStatus.
A little bit further, you can also see the CancelOrder method that sets the Status of the Order to Cancelled.
Adding these methods is a piece of cake:

public class Order
{
  ...
  private OrderStatus _status = OrderStatus.Pending;

  ...
    
  public OrderStatus Status
  {
    get
    {
      return _status;   
    }   
  }

  ...

  public void ConfirmOrder()
  {
    if( _status != OrderStatus.Pending )
    {
      throw new ApplicationException (
        "An order can only be confirmed when " +
        "it's current status is Pending."); 
    }  
    _status = OrderStatus.Confirm;
  }

  public void CancelOrder()
  {
    if( _status == OrderStatus.Shipped )
    {
      throw new ApplicationException (
        "An order that is shipped, " +
        "cannot be cancelled.");  
    }  
    _status = OrderStatus.Cancelled;
  }

}
As you can see, these methods contain some simple business-logic: a check is made if the Order can be confirmed, or can be cancelled. 
Now, I still need to implement the OrderStatus enumeration:

public enum OrderStatus
{
    Pending,
    Confirmed,
    Cancelled,
    Shipped
}
The above code is pretty obvious, but, it is not sufficient yet in order to make the test pass, or even compile.  As you can see in the test, another method is needed: CanOrderLineBeAdded.   As you can see in the test, this method does not return a simple boolean value, even though the name of the method let's you think that it would.  The reason why I choose to not return a boolean here, is very simple: instead of just knowing whether it is possible or not to add an OrderLine to an Order, I also want to know why it would not be possible.  Therefore, I've choosen to return an enumeration, which has these possible values:

public enum OrderLineAddQueryResult
{
    Yes,
    NoBecauseOrderIsConfirmed,
    NoBecauseOrderIsCancelled,
    NoBecauseOrderIsShipped
}
Then, the CanOrderLineBeAdded member method of the Order class looks like this:

public OrderLineQueryResult CanOrderLineBeAdded( OrderLine ol )
{
  OrderLineAddQueryResult result = OrderLineAddQueryResult.Yes;

  switch( this.Status )
  {
    case OrderStatus.Confirmed :
      result = OrderLineAddQueryResult.
        NoBecauseOrderIsConfirmed;
      break;

    case OrderStatus.Cancelled :
      result = OrderLineAddQueryResult.
        NoBecauseOrderIsCancelled;
      break;

      case OrderStatus.Shipped :
        result = OrderLineAddQueryResult.
          NoBecauseOrderIsShipped;
        break;
    }

    return result;
}
The purpose of this method is that the user of our class can check if an OrderLine can be added, without exceptions being thrown. This method is usefull to know for instance which UI controls should be enabled/disabled, or what message should be given to the user of the software.
But, the existance of this method does not ensures us that this method shall be used as well, therefore, we should enforce this rule in the AddOrderLine method of the Order class as well.

public void AddOrderLine( OrderLine ol )
{
  OrderLineQueryAddResult result = this.CanOrderLineBeAdded (ol);
  if( result != OrderLineQueryAddResult.Yes )
  {
    throw new ApplicationException(
      GetReasonWhyOrderLineCantBeAdded (result));
  }

  if( ol.NumberOfItems == 0 )
  {
    throw new ApplicationException ("You must at least order 1 item.");
  }

  if( ol.IsArticleSet == false )
  {
    throw new ApplicationException (
      "You must specify the article that must be ordered.");
  }

  this.OrderLines.Add (ol);

  CalculateDiscount();
}
I will not elaborate here on the GetReasonWhyOrderLineCantBeAdded member method very much.  It is sufficient if you know that this is just a private method which returns an error-message, depending on the value of the OrderLineQueryAddResult parameter.
The business rules that are in the AddOrderLine method can offcourse be avoided by simply not using the AddOrderLine method at all, and instead, using the Add method of the OrderLines property which is publicly exposed. Therefore, it should be better if we do not expose the Order collection publicly, but, for now, I'll leave it like it is.
As this is one very long post already,  I'll end it right here.  I'll keep the rest of the implementation for another article.
Please, feel free to post your comments, critics, questions, remarks.



Domain Driven Design: A Quickstart (Part 1)
2006-05-24T17:03:00.000+02:00
Introduction

Some time ago, I bought the book Domain Driven Design, tackling complexity in the heart of software.
Since reading it, I became very interested in the Domain Driven Design paradigm.   For enterprise applications, it would be ideal if you could express the core of the application (the domain layer; the part of the program that contains the business logic) in a good model.
The Object Oriented Programming paradigm provides a good way to express the model in a computer program.

So, although the behaviour can be expressed in an OO fashion, the data needs to be persisted as well.  In most cases, a relational database is used to persist the data.   Combining OO and RDBMS'es gives us the problem of the Object / Relational mismatch.  You can offcourse solve this object-relational impedance mismatch yourself by writing a DAL that nicely maps the classes of your domain model to the tables of your relational database.  In most cases, this means that you'll have to write a lot of code.  Instead of implementing this functionality yourself, you could also opt for using one of the many existing O/R mapping tools, like NHibernate or LLBLGen.
As Frans Bouma once explained in one of his blogposts, there are different types of O/R mappers.   NHibernate fits in another category then LLBLGen; In Frans' categorization, NHibernate fits in the 'Domain Approach', while LLBLGen fits in the Entity approach.
Since I'm interested in the Domain Driven approach, I've taken a look at NHibernate, and, while it's not 100% perfect, it still has a lot of advantages.  It releases you from some boring tasks (like mapping - hey, that's why it's called an O/R mapper), and takes care of some more complex tasks (caching, state-tracking, ...).

The idea of this blogpost is to provide a little quickstart in Domain Driven Design and NHibernate, by creating a piece of software for a particular use case.

The Case

My idea was to create a simple application for a shop/manufacturer.   A customer can order multiple goods at a time, and, when a customer has ordered for over 2500euro in the past 3 months, this customer is a gold customer.
When the order is shipped, an invoice has to be created for that Order.  Gold Customers receive a discount of 5% on their invoice.  On the other hand, customers that are known as 'bad payers', cannot place orders that have an order total that exceeds 250 euro.  A customer is tagged as a 'bad paying customer', when 1/3rd of his invoices have been overdue.
Let’s say that a customer can make an order by phone, and via the website of the shop.
Pretty simple, no ? :)   This is off-course not a real-world example, but it should be sufficient for the purpose of this article.

Modelling the domain

Following the Domain Driven Design principle, a model consists of entities, value objects and services. We can already extract some entities out of the given text:

Customer

Article

Order

Invoice


Another entity that is not so obvious, is the OrderLine entity.  This one is needed because a Customer can order more then one article at a time, so we need to know which Articles have been ordered, and how many of them are ordered.
For the Invoice entity, it's the same story: there must be an InvoiceLine entity that represents each 'line' on the invoice.
This means that, at this time, our model consists of 6 entities.   There are no Value objects and Services defined yet.

The entities that we've defined can be drawn in a first schema:

As you can see, a customer can have 0, 1 or more Orders, an Order contains one or more OrderLines, and every OrderLine must contain exactly one Article.
For each Order, there can be one Invoice.
If this were a database schema, this would be perfect.   However, this is an (concise) UML diagram, and the classes in this diagram should not describe how our data must be persisted, but how our application should behave.

Now, there are some things in this ‘design’ that can be improved.   If you look at the Customer and Order classes in the schema, you see that a Customer has a collection of Orders.   This is in fact correct, but, I wonder if this is necessary to express in our domain-model.
In this case, we’re more interested in knowing to which Customer a specific Order belongs, rather then knowing or getting all the Orders of a specific Customer.   To get a list of all the Orders of a specific Customer, we can always add a method in a Repository that gives us the list of Orders for a Customer, instead of giving the Customer class a collection of Orders.  (I will come back on the Repository part later).  This will simplify things a bit.   This also means that, if we have customers that have made a lot of Orders, the Customer Object for that Customer doesn’t have to hold a large collection of Order objects.
For the relationship between the Order and OrderLine class, things are a bit different.  I do not think we can give a direction to this relationship, since, we do want to know the OrderLines of an Order, since they are coupled to each other: an Order exists only because of its OrderLines.   And for each OrderLine, we do want to know to which Order it belongs.  So, this association has to be kept bidirectional.
Then again, the relationship between Order and Invoice, doesn't have to be bidirectional.  I do not even know if we should have a 'coded' relationship between these 2 entities, because I don't think that it will often occur that we need to see the invoice that is linked to an order, or, the related order of an invoice.  If we do need that, we can always get them by calling a method on the repository.  However, I will keep the link between Order and Invoice on the schema, since, they're in a way linked to each other.

This gives us the following schema:



In this schema, you can see the directions of the associations.

The next step, is to define the aggregates in the model.  An aggregate ‘clusters’ the entities and value objects that belong together.
In this case, we can define 4 aggregates: Customer, Order, Invoice and Product.
The Customer and Product aggregate only contain 1 entity, while the Order aggregate and the Invoice aggregate contains 2 entities; the Order and the OrderLine entity make up the Order aggregate, and the Order entity is the ‘aggregate root’.  The aggregate root is the only object in the aggregate, where other objects that are outside of that aggregate, may have references to.
The Invoice aggregate is very similar: it's made up by the Invoice and the InvoiceLine entity, and the Invoice entity is the aggregate root.

Once we know the aggregates, we can define the repositories for our domain model.  A repository is an abstraction which gives us references to our aggregates, and allows us to persist those aggregates.   The underlying infrastructure can be a relational database, a file, …  but our model doesn’t need to know that.   We just have to be able to get aggregates, and save them back, so the repository provides us this abstraction.
We should not create a repository for every class in our model, we should create a repository per aggregate.  In our example, it makes no sense to be able to retrieve OrderLine objects, without retrieving the corresponding Order object.
Knowing all this, we can extend our schema:



Here, you can see the 4 repositories (I've added some example operations to it), and the 4 aggregates.   I've also drawn the aggregate boundaries of the Order and the Invoice aggregate.  Since the other 2 aggregates (Customer and Product) only consist out of 1 entity, it is not necessary to draw their boundaries as well.

There is one thing that we'll need to keep in the back of our mind: we have to be able to create Invoices for Orders that are shipped and that have no Invoice yet.  It would be a good idea to create a batch-process that runs every night, and that creates Invoices for Orders that are shippend and have no invoice yet.  In other words: this would be ideally implemented as a service.

Now that we have identified the entities, aggregates and repositories that make up our domain model, we could start to put the model into code,
but, I'll keep that for another post that I hope to finish soon. :)


Is Software Development too hard, or too easy ?
2006-05-01T14:11:00.000+02:00
I've come across some rather interesting blog-articles, like this one from Scott Bellware and this one from Jeffrey Palermo.
Both articles are a reaction to this article from Rockford Lhotka.  Rockford Lhotka says in his article that software development is too hard, that we -developers- have to spend too much time doing 'plumbing work', instead of concentrating on delivering business value.
In a way, he has a point: the main point in writing a business application, is to create an application that solves the business problem, and, since time is money and business is constantly changing, it should be done as quick as possible.  Isn't this what we're all striving for ? 
However, this should not be done at all costs.   I mean, there are RAD tools available that will allow you to 'develop' an application quickly, but, if those tools are used in an inappropriate way, you'll end up with an 'application' that is a hell to maintain and to extend.
I think we've all seen those kind of applications: in a first phase, those app's do what they have to do, but, as requirements change, the code gets messier and gets hard to understand and it gets even harder to implement new functionality or change existing functionality.
This is where the opinion of Jeffrey Palermo comes in: the RAD tools allow you to build an application without requiring to know what's going on under the hood, and they make it possible that somebody who is not trained in software engineering can create an application.   However, the quality of that application will most likely be poor.
To put it in his words:
It’s too easy for an unskilled person to throw a screen together and deploy it.  It’s too easy for Joe blow to create a database application that pulls over entire tables to the client for modifying one record (but it works – initially).  It’s too easy for a newbie to get excited about a new technology and completely screw up an application with web service calls to itself and overdo sending XML to Sql Server 2000.  It’s too easy to a database guy to throw tons of business logic in stored procedures, call them from ASP and call it an application (until a skilled programmer looks at it later and has a heart attack).
The problem with RAD tools, is that everybody can now create an application that does what it should do.  It allows people that are not trained in software engineering to create an application that does what it has to do, and it's possible that the user of the application doesn't notice that the application is actually a piece of crap.  And I believe this happens all too often.
My opinion is that RAD tools can reduce the workload, but they should be used with care.

When a RAD tool is used inappropriatly to create a business application, the chances are big that the developer uses the 'Smart UI' antipattern.  This means that all the business logic of the application is put directly into the user interface.   This is off course problematic when the requirements change.  Since the business functionality is scattered throughout the user interface, the programmer who has to maintain this application will have to delve into the UI to find all the code and the related code that has to be changed.  When the application is large, it's easy to forget or overlook something that has to be changed, and it will result in a buggy application.
Or, imagine that you've build a Windows application, and once it's delivered, your customer or boss wants to have a web interface for this application as well.  When all business logic is implemented in the user interface, this means that you will not be able to just reuse that code in the web application.  The result will most likely be duplicated business logic.
That's why I believe that a RAD tool should be used with care.  In my opinion, you should use the RAD features of your development tool to build the User Interface, and that's about it.
Developing software is more then just dragging some components on a form, glueing them together by setting some properties and using wizards to get the data from the database and bind it to some kind of control.
Scott Bellware is right when he says that the RAD functionality of Microsoft's development tools encourages one to create badly designed software.  Microsoft shows in demo's how one could create an application very fast, with a very small number of lines of code with their RAD tools.  The sad thing is that there are developers attending these demo's who think afterwards that this must be the way to develop applications.  And this is not only true for developers attending these sessions.  Managers seeing these demo's can think that software development isn't that hard at all, and they also do not understand how it comes that it takes so much time developing an application.
This is not a good way of building software.  Those RAD tools and wizards are very good for giving demo-sessions (and selling the tools), but they're defenitly not showing a correct way on how to build software.
What about the maintainability and flexibility of software created in this way ? What about the ability to create unit-tests to test the functionality of the implemented business rules ?  It is all impossible with applications that are developed in this way.
For the core of the application -the business functionality- the development team should create a domain model that expresses the business problem that the application must tackle.  This means off course
that the initial development cost of the application will be higher, but, this development cost should be seen as an investment.  The model will be easier to maintain, extend and to reuse, and, by using Agile development
techniques, the customer can be involved in the development process.  By using small development iterations and having customer input after each iteration, the customer knows that the development of the application is going forward, and he can ring the alarm when he sees that the functionality of the application or the business logic is wrong.
To conclude: RAD tools provide a way to make software development easier, and because of that, one could be tempted to create an application in a quick and dirty way.  However, building high-quality software still requires skilled and educated/trained developers.  They're not only required to be able to create a good domain model.  They also have to be skilled in a way that they know for what they should and shouldn't use RAD tools.



.NET 2.0: Could not find schema information for ... part 2
2006-04-01T12:20:00.000+02:00
Today, I've been playing a bit with the new Configuration classes in .NET 2.0.
Again, I came across those annoying 'Could not find schema-information for ... ' messages.
I do not like warnings and information messages in my projects, so I had the urge to solve these issues.

I was playing a bit with the 'Settings' class in a Windows Forms application.  I added a user-scope setting, and I received this warning from Visual Studio.NET 2005:

The requirePermission attribute is not declared

After some crawling on the web, I've found an article written by Peter Richie.  It appears to be a negligency from Microsoft: it seems that the DotNetConfig.xsd schema-file is not complete.  Peter Richie has adapted this XSD file, so you can download this file and replace the original file with his one.  By doing so, I got rid of this error.
Click here for Peter's article.
I can't understand how Microsoft could be so sloppy to not deliver a correct xsd.

Then, I was still annoyed by some 'Information messages' Visual Studio gave me.  These were due to a custom configuration section for NHibernate I have in my app.config file.
This is a snippet from my App.Config file:

<configSections>
   <section name="nhibernate"
      type="System.Configuration.NameValueSectionHandler"/>
</configSections>
<nhibernate>
    <add key="hibernate.connection.provider"
         value="NHibernate.Connection.DriverConnectionProvider"/>
    ...
</nhibernate>


The 'information message' here told my that a schema definition for the element nhibernate couldn't be found.  Off-course, this is not an error, but...  I find those things annoying.

So, to get rid of those messages, I've created a simple XSD that describes this 'nhibernate' section.  (You can download this XSD here).  I've copied this xsd to the Program Files\Microsoft Visual Studio 8\Xml\Schemas\ directory.  The next step I had to do, was to include this schema in the DotNetConfig.xsd file.
So, in the same directory, edit the DotNetConfig.xsd file and add this line:

 <xs:include schemaLocation="nhibernate_configuration.xsd"/>


If you have a rather complex custom Configuration Section in your App.Config file, you can create your own XSD for it.  
You're not only going to get rid of those 'could not find schema information...' messages, but you'll also have Intellisense for your custom configuration section in VS.NET 2005 as well!

Click here for my first post about this problem.


Low key portraits with a Hasselblad
2006-03-30T19:57:00.000+02:00
The past few weeks, I (and my fellow photography students) have been playing with Hasselblad camera's in the studio.

This is a low key portrait that one of my collegue students took from me.





Unfortunately, I was not able to scan the entire picture (it is to big for my scanner), so that I cannot present it here in its original and typical square Hasselblad format.

I also took some very nice shots from other persons, but I'm not going to post them here (yet), since I do not have the permission of those persons to do so.

I really like those Hasselblad camera's.  They're great to work with and provide great quality.  I even think of buying one (a 2nd hand, because these things are expensive...)


NHibernate: where's the productivity ?
2006-03-09T22:03:00.000+01:00
I've been playing around with NHibernate the past few days, and I've encountered a rather strange bug...

I wanted to perform a rather simple HQL query.  I wanted to know the total value of the Orders that were placed by a Customer.
So, I thought that this simple HQL query would do the job:

IQuery q = theSession.CreateQuery("select sum(ol.Price * ol.NumberOfItems) 
    from OrderLine ol");

However, this didn't work...
This query did work however:

IQuery q = theSession.CreateQuery("select sum(ol.Price) from OrderLine ol")


It appeared that the query (the one with the multiplication in the sum function) that was sent to the database looked like this:

select sum(orderline0_.NumberOfItems*orderline0_.ItemPrice) as x0_0_ 
from tblOrderLine orderline0_

while NHibernate was then trying to access a result-column that was called x1_0_
This will offcourse not work, since the field has been given the alias x0_0_

After some searching, I've found out that this was a bug that also existed in Hibernate, but has been fixed in Hibernate 3.0.

So, I had to look for an alternative.
The idea came up that I could retrieve all the orderlines that belong to a specific Customer, and then, do the calculation myself.
So, I came up with this HQL query:

IQuery q = theSession.CreateQuery ("from OrderLine ol " +
     " inner join Order inner join Customer " +
     " where Customer.Id = :custId");

This didn't work as well...  An exception was thrown saying that the BY keyword was expected after a GROUP or ORDER.   However, I didn't use any group by or order by statements ?  Then, I've noticed that I've a class that's called Order, so maybe I had to escape the classname.
However, I couldn't find how to do that (if it is possible), so I've rewritten the query to something like this:

IQuery q = theSession.CreateQuery ("select ol " +
    " from OrderLine ol, Order o, Customer c" +
    " where ol.Owner = o and o.Owner = c " +
    " and c.Id = :custId");

This didn't work as well...  
The exception now said:
Could not resolve property:Id of Customer
I found this very strange, since this class has an Id property.  
After some research, I found out that the Id did not appear in my hibernate mapping file indeed.  
This is, because the Id is used as the 'id' in my mapping file, and, since the Id property is read-only in my class, I use a field access method to set this field.  This is specified in my hbm mapping file like this:

<class name="NamespaceName.Customer, NamespaceName" table="tblCustomer">
    <id name="id" access="field" column="Id"... >
...


So, what should I do next ? I didn't want to make the Id property of my Customer clas s writable.

I tried to add the Id property to my Customer mapping file, without touching the 'id' element.
So, I've added the Id property to my mapping file, but, since I've introduced the same database column twice, I had to use some attributes:

<class name="NamespaceName.Customer, NamespaceName" table="tblCustomer">
    <id name="id" access="field" column="Id"... >
    ...
    <property name="Id" update="false" insert="false">
    ...


Now I tried to rerun my query.  However, retrieving a Customer was already a problem.  I received an exception that said that the property value of the Id property could not be set via reflection. Damn.
I really don't want that somebody can set the Id of a Customer via the property...

Luckely, .NET 2.0 came to the rescue.  In .NET 2.0, you can define different access-modifiers on your property getter and setter.  So, my Customer class looked like this :

public class Customer
{
    private int id;

    public int Id
    {
       get { return id; }
    }
}

I've changed this to

public class Customer
{
    private int id;

    public int Id
    {
       get { return id; }
       private set { id = value; }
    }
}


And this finally did the trick...

I've spent something like 2 hours in getting something simple like this to work in NHibernate.  With a self-written Data Access Layer, this would have taken me something about 10 minutes I guess, to implement this functionality.
Conclusion: there's a lot of work to be done on NHibernate before I will really call it 'productive'.  However, it is a promising project though.

For more information about my quest, I refer to a topic I've opened regarding this issue on the NHibernate support forum.


Troubles with Visual Sourcesafe, looking for alternatives
2006-03-06T21:30:00.000+01:00
Today, I've encountered some rather unpleasant moments with Visual Sourcesafe.  Around 4 o'clock, it appeared that my VSS repository was corrupt. :(
Trying to restore the latest backup didn't succeed as well, since there was a problem with that tape. :(

This means I had to use the backup of last thursday...  Luckely, after some extra work, I've been able to restore most of my work.

However, I do not want to experience these problems again, so, just like Sam Gentile, I'm going to ditch VSS, and look for an alternative.

At this moment, I've 2 options in my mind:

SubVersion

Sourcegear's Vault


Some time ago, I've downloaded a trial version of Vault, and it looked ok to me.  However, I've heard that it doesn't integrate very well in VS.NET (haven't tried that yet).  
On the other hand, we have Subversion, however, I haven't worked with it before.  

Anybody who has experience with one of these 2 systems and wants to share his/her opinion ?


Formula One: The new season is coming...
2006-03-05T16:34:00.000+01:00
At last, after a long winter of F1-less Sundays, the new Formula 1 season will start next sunday.  
I find it always interesting to see during the first race of the year which teams have done their home-work, and will be the teams to beat during the season.
I bet that, for the 2006 season, Renault and Honda will be the favorites for the World Championship with Ferrari and McLaren on their heels.

Who will be world champion ?  Will Alonso extend his title, or is Schumacher able to fight back ?  Can Raikonnen, who has been close to catch the title last year and in 2003, finally clinch the championship ? 
However, I think that Jenson Button also has a chance to win some races this year...

All questions that will be answered during the next months, and the first race in Bahrein should already give a strong indication of who holds the best cards.

Anyway, I'll be supportering for Kimi Raikonnen and Jacques Villeneuve.  I just like the driving style of these 2 guys.
I hope that it will be an interesting season, with a lot of exciting duels on the track.   


To get into the F1-mood, here (18mb) is a video-clip of one of the most exciting duels in F1 history.
This video shows the last 3 laps of the 1979 French Grand Prix which was held in Dijon.  René Arnoux and Gilles Villeneuve are contending for 2nd place.  René Arnoux is driving a Renault Turbo (with a defect Turbo), while Villeneuve is driving an atmospherical Ferrari with worn out tires. (You'll see the reason for those worn out tires...).  The commentary is from the legendary Murray Walker.


It's been a while...
2006-03-01T20:15:00.000+01:00
It's been a while since I've made a post on my blog.  I'm currently busy reading the book Agile Software Development and I'm also playing with NHibernate a little bit.
I am thinking of creating a little tutorial / Quickstart about NHibernate and post it here, but I'm not sure yet.  It is a lot of work, and takes some time... :)


A 'problem' with custom configSections in .NET 2.0
2006-02-18T10:56:00.000+01:00
Yesterday evening, I was trying to port a simple .NET 1.1 test project of mine to .NET 2.0.
This project contained an App.Config file that contains a custom configuration section like this:
<configuration>
    <configSections>
        <section name="test" 
             type="System.Configuration.NameValueSectionHandler"/>
    </configSections>
    <test>
       <add key="xx" value="yy"/>
    </test>
</configuration>


When I compiled my project, I got the following error message from VS.NET:

Could not find schema information for the element test
Could not find schema information for the element add
Could not find schema information for the element key
Could not find schema information for the element value

I was really surprised...  This just worked in .NET 1.1, why shouldn't it work in .NET 2.0 ?
I spent a lot of time searching on Google, newsgroups, etc... for more information about this error and how to solve it, but I haven't found any clue.

This morning, I restarted my quest, and I was able to solve the problem.
Apparently, I had a syntax error somewhere in my code.  In the configuration file, there was nothing wrong.  Once this syntax error was solved, VS.NET didn't complain anymore.
I tried the same thing in my .NET 1.1 project: I added a syntax error in my code, and compiled.  The compiler complained about the syntax error, but not about the configuration file (which is good, because the config file is correct).

This is very frustrating.  Why is VS.NET 2005 complaining about something in the configuration file, while the configuration file is just correct ?
On top of it, this 'configuration file error' appears as the first error in my error-list.

I really lost a lot of time due to this strange behaviour of VS.NET; why is VS.NET 2005 behaving like that, which is incorrect IMHO, while VS.NET 2003 is acting like it should.
This error is very confusing and it can really take your productivity down.

Update: I've been playing with configuration-settings in .NET 2.0 again, and again, I came across this annoying error.  I've made 2 comments on this article that should provide a way to fix this.


Domain Driven Design / Entity (Yourdon-Chen) approach
2006-02-14T19:51:00.000+01:00
The last few months, I've been reading a lot in the book Domain Driven Design by Eric Evans.
The book preaches really useable things such as 'the separation of concerns', and 'expressive domain models'.  These are practices where I try to strive to, and the more I read in the book, the more this 'Domain Driven paradigm' appears to me as 'the Holy Grail' in software developmment.

However, when you want to turn theory into practice, you sometimes run into problems...

For instance, suppose you have a simple domain model for some shop.   In this domain model, you'd have a Customer entity, and this Customer has Orders.  An Order consists of one ore more OrderLines.
Suppose we should treat a Customer who ordered for more then 1000€ in the last 6 months as a 'Gold Customer'.

In a Domain Driven Design, it would feel natural to add a member to the Customer which tests this condition, and it could look like this:
public class Customer
{
    ...
    public bool IsGoldCustomer()
    {
        decimal total = 0;

        foreach( Order o in _orders )
        {
            if( o.OrderDate >= sixMonthsAgo )
            {
                total += o.TotalOrderValue;
            }
        }

        return ( total > 1000 );
    }
}


As you can imagine, this will not be very performant.  First of all, this code requires us to traverse over the entire OrderCollection of that customer.   
It could also be that the TotalOrderValue property is also a calculated value.  
This means that, for every Order who's orderdate falls within the last 6 months, we'll have to retrieve the OrderLines (suppose that the OrderLines are lazy-loaded) in order to be able to determine the TotalOrderValue of that Order.
As you can see, this means that we'll have to do a lot of query-ing and we also have to retrieve a lot of records out of the database and load them into memory...  For just such a simple check...
This is not really a best practice.

Luckely, our database is able to determine the amount of placed orders in the last 6 months for a specific customer in a much faster way, and without the need of loading a lot of objects into memory.
By using a Specification pattern, we can make use of the power that our database offers, and still have the logic encapsulated into the domain:

public class CustomerGoldStatusSpecification : CustomerSpecification
{
  public bool IsSatisfied( Customer c )
  {
    decimal total = 
       customerRepository.
           GetTotalOrderValueForCustomerInPeriod(c.Id, sixMonthsAgo, today);

    return (total > 1000);
  }
}


In this way, the logic is still encapsulated in the domain model, since the CustomerGoldSpecification class is a part of the domain, and, we also make use of the power of our database; the specification uses a method on the Customer Repository which queries the database for the value that we want.

Nice. :)

However....

If we take this logic out of our 'entity' classes, then what difference does this 'Domain Driven' approach make with the Yourdon/Chen entity approach ?
If we take the 'complex' logic and behaviour out of our domain classes, what else is left but some dumb entities that are nothing more then a data-holder, while all our logic is in specifications / managers ?

One could ofcourse say that the Specification class can be made internal, and the Customer should use this specification class like this:
public class Customer
{
    public bool IsGoldCustomer()
    {
       CustomerGoldStatusSpecification spec = 
           new  CustomerGoldStatusSpecification();

       return spec.IsSatisfied (this);
    }
}

(You can offcourse also directly access the repository from this Customer class)

Am I exagerating about this ? Is the situation I've described here, and the solution a good solution ? Is there still a difference between this approach and the Entity/Yourdon approach ?
I'd like to hear your comments and opinions.


Better performance when loading a typed dataset.
2006-02-10T19:44:00.000+01:00
At work, we had a little performance problem when we wanted to fill a rather large typed dataset that had a number of constraints defined.

Setting the EnforceConstraints property of the dataset to false before filling up the dataset, and setting it to true afterwards, resulted in an immense performance boost.
Without setting this property to false, it took minutes to load the dataset.  When we made use of this property, it only took a second or two.


Business Objects Framework - Part 3: Lazy Loading
2006-02-02T21:52:00.000+01:00
This is the 3rd part of my 'Business Objects' serie.  In this article, I'll discuss the LazyLoadCollection.  (Part 1 and 2 can be found here and here.

Introduction

Suppose you have a class Customer.  This Customer class has collection of 'Orders'.  Each Order contains a collection of OrderLines.
Now, if you retrieve one or more Customers out of the database, it is maybe not such a good idea that you retrieve all the Orders and OrderLines with it.  It is probable that  the user is not interested in all the orders or all the orderlines of each customer that you have retrieved.
If you do this, it means that a lot of objects will be loaded into memory; objects you might not need.
Therefore, it is sometimes a good idea to load this information only when you need it.  In the scenario I've described here, I think it is a good idea that, when you load a Customer out of the database you should also get his Orders.   
In most cases, you want to have an overview of the Orders of a Customer.   This means that you will need the Orders of the Customer in most of the cases.
However, you're only interested in the OrderLines of an Order, once you decide to view the details of an Order.  Here, you should only retrieve the OrderLines out of the database, when they're needed.   This is where the Lazy Loading comes in.

The LazyBusinessObjectCollection class

The Lazy Load functionality must be transparant to the user of our Order class.   This means that, the user must be able to Add, Remove and see the OrderLines of an Order just like he/she can do with a normal collection class.
Even if the OrderLines of an Order have not been loaded yet, it must be possible that  OrderLines are being added.

So, how can we do that ?  The Proxy Design Pattern offers us a way to do that.
Instead of giving the Order class a 'real collection' as a member to hold it's orderlines, we will give it a proxy object that acts as a collection.

This means that we must create a class that has all functionality of a collection.  The easy way to do so, is to create a class that is a wrapper around a Collection object, and acts as a Collection as well.
We can create a class that is a wrapper around the BusinessObjectCollection class that we've created earlier.  This wrapper class must also implement the ICollection interface so that it can act as a collection.  We also want Undo-support, so this class must implement our IUndoable interface as well.

The skeleton of our LazyBusinessObjectCollection will look like this:
[Serializable]
public class LazyBusinessObjectCollection<T> : IUndoable, ICollection<T> 
    where T : BusinessObject
{
}


Earlier, I said that the LazyBusinessObjectCollection class would be a wrapper around the BusinessObjectCollection class.  This means that the LazyBusinessObjectCollection class should have a member of type BusinessObjectCollection.
[Serializable]
public class LazyBusinessObjectCollection<T> : IUndoable, ICollection<T> 
    where T : BusinessObject
{
    private BusinessObjectCollection _collection = null;

    private BusinessObjectCollection CollectionObj
    {
        if( _collection == null )
        {
            // initialize and load the items.
        }
        return _collection;
    }

}

I've also created a property that accesses the BusinessObjectCollection member.  This property should be used everytime we access our BusinessObjectCollection from within the LazyBusinessObjectCollection class, since this property will take care that the BusinessObjectCollection is loaded if this is necessary.

To be able to populate the collection, we need something that can loads the data for us.  We want to decouple the LazyBusinessObjectCollection from the code that retrieves the items for us, since, this 'data retrieval code' will be most likely in some kind of Data Access Layer.

So, I decided to create an interface ILazyLoader
This interface looks like this:
public interface ILazyLoader<T> where T : BusinessObject
{
    List<T> GetObjects();
}


This interface defines only one method that gives us a list of BusinessObjects.  This means that the class that implements this interface is responsible for retrieving and returning the BusinessObjects.

So, we can give an ILazyLoader to our LazyBusinessCollection class.  This ILazyLoader can be provided by the constructor of the LazyBusinessObjectsCollection class, and the property that we've created earlier, can access the GetObjects method which will give the Objects that the collection must contain:

[Serializable]
public class LazyBusinessObjectCollection<T> : IUndoable, ICollection<T> 
    where T : BusinessObject
{
    private BusinessObjectCollection _collection = null;
    private ILazyLoader<T>           _loader;

    private BusinessObjectCollection CollectionObj
    {
        if( _collection == null )
        {
            _collection = new BusinessObjectCollection<T> ();

            foreach( T item in _loader.GetObjects () )
            {
                _collection.Add (item);
            }
        }
        return _collection;
    }

    public BusinessObjectCollection( ILazyLoader<T> loader )
    {
        if( loader == null )
        {
           throw new ArgumentException ("You must provide an ILazyLoader", 
                                        "loader");
        }
        _loader = loader;
    }

}


Pretty simple huh ? 

Now, an ILazyLoader can look like this:
public OrderLinesLoader : ILazyLoader<OrderLine>
{
    private int _orderId;

    public OrderLinesLoader( int orderId )
    {
       _orderId = orderId;
    }

    public List<OrderLine> GetObjects()
    {
        // Just for simplicity of the example, normally, you should 
        // use parametrized queries, etc.... Consider this as pseudo-code
        string sql = "SELECT * FROM orderlines " +
                     "WHERE OrderId = " + _orderId.ToString();
    
        DataReader dr = dbHelper.Execute (sql);
        List<OrderLine> lines = new List<OrderLine>();
        while( dr.Read() )
        {
           OrderLine ol = CreateOrderLineFromReader (dr);
           lines.Add (ol);
        }
     
        return lines;
    }
}


So, the repository or factory who gives us an Order object, is responsible for initializing the OrderLines member -which is an LazyBusinessObjectsCollection of the Order class.

We still have to implement the ICollection and IUndoable interface.  I will not put the implementation of the ICollection interface here to save some space; besides, it is pretty simple code: you can just delegate these calls to the BusinessObjectCollection property (note: make sure to use the property) of the LazyBusinessObjectCollection class.
The same applies to the implementation of IUndoable: just delegate the calls to the BusinessObjectCollection.  However, here we can use the field instead of the property, since we only have to delegate these calls if the collection has been loaded:
public void CreateSnapshot()
{
    if( _collection != null )
    {
        _collection.CreateSnapshot ();
    }
}

...



Buying Books
2006-01-27T19:09:00.000+01:00
I've bought 2 books recently.

The first one is Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Microsoft .NET Development Series).

  This is a usefull book with some interesting tips for anyone who's interested in or is busy with designing and building frameworks.  If you use FxCop, chances are that you're already familiar with most of the tips and guidelines that are in the book.  Nonetheless, this book is usefull as reference-book but you can also read it from cover to cover.  Most of the guidelines in the book are commented by people like Jeffrey Richter, Rico Mariani, etc... and these comments are very valuable as well.


The second book I've bought is Agile Software Development, Principles, Patterns, and Practices by Robert Martin.

I haven't found time to start reading this book, but due to the reviews on Amazon and other fora, I'm expecting a lot of it!  Maybe I'll post a little review on my blog about this book, after I've read it.

Again, two books that I can remove from my book whishlist

Correction: I didn't really buy the 1st book; it was rather a  present. :)



Business Objects Framework – Part 2
2006-01-21T09:54:00.000+01:00
This is the 2nd article of a serie.  The 1ste one can be found here.

In this article, I'll explain the BusinessObjectCollection class.  Before starting off with this class, I'd like to go back to the BusinessObject class first, because I want to do a little modification on that class.
Implementation of IEditableObject in BusinessObject

The IEditableObject interface is defined in the .NET framework to control the undo-functionality used by the databinding infrastructure.
There are 2 situations in where this interface is used:

If the object is a child of a collection, and this collection is collection is databound to a grid, the IEditableObject interface is used so that the user of the application gets the expected functionality.  For instance, when he creates a new row and then presses Escape on that row, the new row should not be added to the collection.

When an object is databound to the forms on a control, the IEditableObject.BeginEdit method is called when the object has been changed by the databinding.  However, the EndEdit and CancelEdit methods are not called automatically by the infrastructure, and thus, it is the responsability of the application-developer to call these methods.

Since the BusinessObject class already contains the methods defined by the IUndoable interface that are able to undo / commit any changes made to the BusinessObject, I think it is better that the application developer has no 'direct access' to the methods of the IEditableObject interface.  The application developer should use our IUndoable methods instead, and the IEditableObject interface should only be used if the BusinessObject is contained in a collection that is databound.

To achieve that the application-developer cannot call the methods of the IEditableObject directly, the IEditableObject interface should be implemented explicitly.
This is done like this:

void IEditableObject.BeginEdit()
{
   ...
}

void IEditableObject.CancelEdit()
{
   ...
}

void IEditableObject.EndEdit()
{
   ...
}


The effect of implementing the IEditableObject interface explicitly is, that the BeginEdit, CancelEdit and EndEdit methods will not appear in the 'Intellisense' list and, that these methods cannot be called directly on instances of BusinessObject.
These methods are only callable if the BusinessObject instance is cast to the IEditableObject type.

Now, the application developer that uses the BusinessObject class, is in a way forced to use the methods of our IUndoable interface if he wants undo-support.  

Now we also have to manipulate our _bindingEdit variable in the IUndoable methods instead of in the IEditableObject members:
public void CreateSnapshot()
{
    _bindingEdit = true;
    ...
}

public void CommitSnapshot()
{
    _bindingEdit = false;
    ...
}

public void RevertToPreviousState()
{
    _bindingEdit = false;
    ...
}

void IEditableObject.BeginEdit()
{
    if( _bindingEdit == false )
    {
        this.CreateSnapshot ();
    }
}

void IEditableObject.CancelEdit()
{
    if( _bindingEdit )
    {
        this.RevertToPreviousState ();
    }
}

void IEditableObject.EndEdit()
{
    if( _bindingEdit )
    {
        this.CommitSnapshot ();
    }
}


Now, we can have a look at the BusinessObjectCollection class.

Collections of BusinessObjects

We will need a class that is able to store multiple BusinessObject objects.  So, in fact, we'll need to be able to store a collection of businessobjects.
In .NET 2.0, we can use Generics, so that we'll have to create only one BusinessObjectCollection class, and in our application code, we can define what kind of BusinessObject instances this class should contain.

Since CSLA.NET was developped using .NET 1.x, the Collection classes inherited from CollectionBase.  However, with .NET 2.0, I can use the Collection<T> class as a base-class for my the BusinessObjectCollection class.  
This new Collection<T> class allows me to write less code (I do not have to write my own strong typed Add, Remove, etc... classes), and I do not have to choose in my methods whether I'll use the List or the InnerList property.   There's a subtle difference in these properties: List raises events when an item is added / removed, while InnerList does not raise those events.


The rough skeleton of the BusinessObjectCollection class looks like this:

[Serializable]
public class BusinessObjectCollection<T> : Collection<T>, 
                                                 IUndoable, 
                                                 IBindingList 
                                                 where T : BusinessObject
{
}

As you can see, the class is Serializable and inherits from Collection<T> which I just discussed.
Generics are used here so that the application-developer can indicate what kind of objects he wants to put in his collection.   However, there is a restriction: the objects that the BusinessObjectCollection can contain, must be inherited from BusinessObject.
So, the application developer can use our BusinessObjectCollection class like this:
BusinessObjectCollection<Customer> customers = 
    new BusinessObjectCollection<Customer>();

This will only compile if the Customer class inherits from BusinessObject.

Now, as I said earlier, since this class inherits from Collection<T>, I do not have to write Add, Remove, etc... methods.  If I should have used the CollectionBase class, and if I wanted strong typed Add and Remove methods, I should have written those methods like this:
public T this[ int index ]
{
    get
    {
        return (T)List[index];
    }
}

public int Add( T item )
{
    return List.Add (item);
}


Not only should I have to do this for the Add method and for the indexer, but I should 've done it for the Insert, Remove, ... methods as well.   
Now I do not have to do this, because the Collection<T> class already provides this for me.   This means that inheriting from Collection<T> saves me a lot of tedious work.

What I do have to do, is, providing extra functionality when a BusinessObject object is added to the collection.  If I should have inherited from CollectionBase, I should have been carefull whether I'll use the List or the InnerList property in my own Add and Remove methods, since the List property raises events that I can respond to if I want extra functionality.   With the Collection<T> class, I do not have to pay attention to it because this class does not have an InnerList nor List property.  It only has an Items property.

I only have to override the InsertItem and the RemoveItem methods.

Every time a BusinessObject is added to the collection, I'll need to keep track of the editlevel at which the object has been added.  This is necessary for the 'Undo' functionality of the collection.
Overriding the InsertItem method, allows me to do that:
protected override InsertItem( int index, T item )
{
    item.EditLevelAdded = _editLevel;
    base.InsertItem (index, item);
}

This means that, the BusinessObject class needs an internal member called EditLevelAdded, that keeps track of the 'editlevel' of the collection at which the item has been added to the collection.
This code also means that our BusinessObjectCollection class needs a private member _editLevel.

When a BusinessObject is removed from the collection, we will need to keep track of the BusinessObject as well, since, when the changes that have been made to our collection are undone, it is quite possible that the previously deleted business-object is to be undeleted.
This means that the BusinessObjectCollection will need a list that contains the BusinessObjects that were deleted from the collection.  To achieve this, the BusinessObjectCollection class needs a member that is able to save this collection of deleted BusinessObject instances. 
Again, the Collection<T> class is perfectly suited for this. (In .NET 1.x you'll have to create a nested type that inherits from CollectionBase that represents this collection).

Now, every time that an item is being removed from our collection, we'll have to add it to the collection that keeps track of the deleted BusinessObjects:
private Collection<T> _deletedItems = new Collection<T> ();

protected override RemoveItem( int index )
{
    // Since we do not have direct access to the item that's 
    // being removed here, we'll have to get it first.
    T businessItem = Items[index];
    if( businessItem != null )
    {
        businessItem.MarkDeleted();
        _deletedItems.Add (businessItem);
    }

    base.RemoveItem(index);
}

Since one of my design goals was to get the data access code out of the BusinessObjects, this means that we'll have to have a way to be able to tell our Data Access components which items were removed, and should be deleted in the database.
This means that we'll have to add these 2 extra methods:
public T[] GetDeletedBusinessObjects()
{
    List<T> items = new List<T> ();
    foreach( T item in _deletedItems )
    {
        items.Add (item);
    }

    return items.ToArray();
}

public void ClearDeleted()
{
    _deletedItems.Clear();
}

Now, Data Access Components can use these 2 methods of the collection to see which BusinessObjects should be deleted, and once this is done, they should also be removed from the 'deletedItems list'.
Implementing IUndoable

We still need to implement the IUndoable interface.
Implementing the CreateSnapshot method is quite easy.  We only have to make sure that we call the CreateSnapshot method of every BusinessObject that is in our collection, but, we must also not forget to create a snapshot on the BusinessObjects that are in our _deletedItems collection.
private int _editLevel = 0;

public void CreateSnapshot()
{
    _editLevel++;

    foreach( T item in Items )
    {
        T.CreateSnapshot();
    }
    foreach( T item in _deletedItems )
    {
       T.CreateSnapshot();
    }
}

The implementation of CommitSnapshot is fairly simple as well.  We just need to call the CommitSnapshot method on every BusinessObject that is in our collection and in the _deletedItems collection.

Implementing RevertToPreviousState is a bit more complex, since we might have a situation in where a deleted BusinessObject should be undeleted; for an exhaustive explanation of the functionality, I'll refer to the Expert C# Business Objects book.
This is the code:

_editLevel--;

if( _editLevel < 0 )
{
    _editLevel = 0;
}

for( int i = Items.Count - 1; i >= 0; i-- )
{
    T item = Items[i];

    item.RevertToPreviousState ();

    if( item.EditLevelAdded > _editLevel )
    {
        base.Items.Remove (item);
    }
}

for( int i = _deletedItems.Count - 1; i >= 0; i-- )
{
    T item = _deletedItems[i];

    item.RevertToPreviousState ();

    if( item.EditLevelAdded > _editLevel )
    {
        _deletedItems.Remove (item);
    }

    if( item.IsDeleted == false )
    {
        int saveLevel = item.EditLevelAdded;

        // Add the business object back to the list.
        Items.Add (item);

        if( item.EditLevelAdded != saveLevel )
        {
            item.EditLevelAdded = saveLevel;
        }

        _deletedItems.Remove (item);

    }
}


In the next article, I'll discuss the LazyBusinessObjectCollection class.



Car troubles.
2006-01-19T16:03:00.000+01:00
Yesterday evening, my car produced a very strange noise when turning.
It seemed that one of my suspensions snapped.  

Now, my car (Ford Focus) is being repared and I've received a spare-car....  A Peugeot 106.   I do like karting, and I do it alot, but I do not like to drive a kart during rush-hour.   
This Peugeot 106 is nothing more then a kart with a back-seat, and wrapped up with some silver foil.


Registration & Comments
2006-01-15T18:04:00.000+01:00
When I started this blog, you had to register before you could post a comment.  This has been changed so that you can post a comment without being registered.


Case sensitive queries in SQL Server
2006-01-13T17:55:00.000+01:00
In SQL Server, whether your database is case sensitive or not, depends on the collation that your database uses.

If you have a database that has been setup with a case insensitive collation sequence, but you want to retrieve or sort some data in a case sensitive way, you can do it like this:
SELECT * 
FROM MyTable 
WHERE aField = 'a' COLLATE Latin1_General_CS_AS

or, for sorting:
SELECT *
FROM MyTable
ORDER BY aField COLLATE Latin1_General_CS_AS

As you can see, you just have to define a case sensitive (CS stands for Case Sensitive) collation in your query.

Of course, if you have a table that contains data that should be treated in a case-sensitive way, you can create that table/columns with a case sensitive collation sequence.


Some of my pictures...
2006-01-12T20:24:00.000+01:00
I've been practicing photography for more than one year now, and I'd like to share some of my work with you.

These are 4 pictures I've taken somewhere between september 2004 and may 2005.  All of them were shot with a Nikon F55 equipped with a 28-80mm zoomlens.  I've used a T-Max 400 ISO film, except for the photo with the karts, which was shot on a T-Max 3200 ISO.

I'd like to hear your comments!










Business Objects Framework – Part 1
2006-01-08T17:43:00.000+01:00
Introduction

More than one year ago, I started reading Expert C# Business Objects by Rockford Lhotka.
In his book, ‘Rocky’ Lhotka explains us how he has developed his  CSLA.NET framework.
While his framework has some really nice features, that tackle some problems, it also has some disadvantages.


There are 2 issues in the CSLA.NET framework that are –in my opinion- a big problem:

There is data-access code inside the business object.

The business object takes care of transaction-handling.


The first issue can be resolved by factoring out the data-access code out of the business object, and putting it in a separate object.
The second issue is a bigger problem.  In my opinion, the business object should not be responsible for transaction handling, since the business object does not know the context in where it is used.   It is the client itself who should be responsible for the transaction handling, since this is the only place where the context in where the Business Object is used, is known.
(Although the framework has some disadvantages, I think the book is recommended reading material for anyone who is interested in .NET & enterprise applications).

Because of these drawbacks of the CSLA.NET framework, I’ve decided to create my own 'framework', in where I'll implement some good things of CSLA.NET (like n-level undo support, data-binding), but, try to find another solution for the things I do not like.
I also wanted to be able to support lazy-loading of collections.

I will try to explain the things I've done in order to create this set of classes in  a serie of articles on this weblog.   

N-Level Undo support

So, I already told that the CSLA.NET framework has some features that I really like, like n-level undo support.
This is a feature that I also want in my 'framework'.
Rockford Lhotka has decided to create an UndoableBase base-class that already contains all the functionality for n-level undo support. However, I've thought that it would be appropriate to create an interface that would define the contract to which all types that support n-level undo support must comply to.

This interface just defines 3 methods and looks like this:
public interface IUndoable
{
    void CreateSnapshot();
    void CommitSnapshot();
    void RevertToPreviousState();
}

If you're familiar with the CSLA.NET framework, you probable know (or you can see), that, in the UndoableBase class, a check is performed if a member of the class inherits from the BusinessBase or BusinessCollectionBase class when a snapshot is taken and when the state of an object is reverted to its previous state.  
This is a little bit 'dirty' in my opinion, since this code creates some kind of a 'circular reference'. (BusinessBase inherits from UndoableBase, and UndoableBase 'knows' about the existence of BusinessBase).
The introduction of this interface will resolve this problem:
Instead of the two checks (one for BusinessBase and one for BusinessCollectionBase), only one check will have to be performed.  The circular reference will also be gone, because the class(es) that will implement IUndoable interface, should then only check if their members implement IUndoable interface as well.

BusinessObject base class

Then, I’ve created an abstract base class BusinessObject from which all the concrete business-objects of the problem-domain should inherit from.
BusinessObject implements the IUndoable and the IEditableObject interfaces.
The latter interface is necessary if you want to support data-binding.

While mr Lhotka created 3 'base-classes' (BusinessBase which inherits from UndoableBase which in turn inherits from BindableBase), I've decided to create only one base-class from which all my business objects will inherit from.  I've done this because, at this moment, I do not see the advantage of having the other 2 base-classes.

Since the BusinessObject base-class implements the IUndoable and IEditableObject interfaces, this class is off-course responsible for the n-level undo support and for the databinding.
Apart from that, BusinessObject also contains some 'state tracking' functionality (which is necessary if you do not use an ORM-tool like NHibernate which does the state tracking for you).

The rough skeleton of the BusinessObject class looks like this:
[Serializable]
public abstract class BusinessObject : IUndoable, IEditableObject
{
    #region State Tracking functionality
    #endregion

    #region IUndoable implementation
    #endregion

    #region IEditableObject implementation
    #endregion
}


The class is abstract because it is offcourse intented that you do not use this class directly.  You should inherit your 'specific' businessobjects from this class.
The class is also marked as 'Serializable'.  This is necessary if you want to use your business objects for instance in a remoting scenario.
Another reason for the Serializable attribute will be clear soon, since Serialization is used to achieve the n-undo functionality.

I still have to discuss the implementation of this class, so let's do it right away.

State tracking

The state tracking code is quite simple.  We only need some flags and methods that take care of this.
This code is quite simple and nothing (or very little) has been changed compared with the code that is contained in the BusinessBase class of the CSLA.NET framework, so instead of commenting this code in this post, I'll refer to the 'Expert C# Business Objects' book for further information.
#region State Tracking functionality

private bool    _isNew     = true;
private bool    _isDirty   = false;
private bool    _isDeleted =false;

protected void  MarkDirty()
{
    _isDirty = true;
}

protected void MarkClean()
{
    _isDirty = false;
}

protected void MarkNew()
{
    _isNew = true;
    _isDeleted = false;
    MarkDirty();
}

internal void MarkDeleted()
{
    _isDeleted = true;
    MarkDirty();
}

protected void MarkOld()
{
    _isNew = false;
    MarkClean();
} 

public bool IsNew
{
    get
    {
        return _isNew;
    }
}

public bool IsDeleted
{
    get
    {
        return _isDeleted;
    }
}

public virtual bool IsDirty
{
    get
    {
        return _isDirty;
    }
}

#endregion


Implementing N-level undo support

Implementing the n-level undo support requires some more work and is a little bit more complicated then the state-tracking.
Just like in the CSLA.NET framework, this functionality relies heavely on .NET reflection.  (In fact, I've played copy-cat here.  Apart from the usage of the IUndoable interface, this code is almost identical as the code that Rockford Lhotka has written).

Since the CSLA.NET framework is free to be downloaded (you can get it here), I'll only post some relevant code.  

#region IUndoable implementation

[NotUndoable]
/// The stack that will keep track of all our states.
private Stack _stateStack = new Stack();

public void CreateSnapshot()
{
    Type         currentType;
    Hashtable    state = new Hashtable();
    FieldInfo[]  fields;
    string       fieldName;

    currentType = this.GetType();

    do
    {
        // Get the members of this type.
        fields = currentType.GetFields (BindingFlags.Public |
                                        BindingFlags.NonPublic |
                                        BindingFlags.Instance);

        foreach( FieldInfo field in fields )
        {
            // If this field is declared in the current type
            // and the field is undoable, keep track of it's state
            if( field.DeclaringType == currentType &&
                this.IsUndoableField (field) )
            {
               object fieldValue = field.GetValue(this);

               // If the member implements IUndoable, cascade
               // the call.
               IUndoable uf = fieldValue as IUndoable;
 
               if( uf != null )
               {
                   uf.CreateSnapshot();
               }
               else
               {
                   fieldName = currentType.Name + "." + field.Name;
                   state.Add (fieldName, fieldValue);
               }

            }
        }

        currentType = currentType.BaseType;

    }while( currentType != typeof(BusinessObject) );

    // Now, use serialization to save the state in the
    // statestack
    MemoryStream buffer = new MemoryStream ();
    BinaryFormatter fmt = new BinaryFormatter ();
    fmt.Serialize (buffer, state);
    _stateStack.Push (buffer.ToArray ());

}
#endregion


If you have a look at the code above, and compare it with the CSLA.NET code, you'll notice the slight difference.  
The implementation of RevertToPreviousState and CommitSnapshot is also almost identical to the UndoChanges and AcceptChanges methods of the UndoableBase class of the CSLA.NET framework.  Just as in the CreateSnapshot method, the only change I've made, is checking for the IUndoable interface.
The RevertToPreviousState and CommitSnapshot pop the last saved state from the stack.  CommitSnapshot just throws it away, and calls CommitSnapshot for every member of the class that is an IUndoable type, while ReverToPreviousState uses the last saved state to reset the value of all class-members to their previous state.

The [NotUndoable] attribute is a custom attribute that defines that a field that is decorated with this attribute should not be 'undoable'.
The IsUndoableField method is a private member method of BusinessObject.  This method just checks whether or not the given field is decorated with the NotUndoable Attribute.

IEditableObject implementation

The IEditableObject implementation makes use of the IUndoable functionality.
For databinding purposes, it must be possible that the state of an object is saved when a user changes something to the object.   This is necessary because the object must be reset in it's original state when the user decides to cancel the changes he has made.

We also need a flag that indicates wether or not we have to save the current state.
This is necessary because, in a databinding scenario, the BeginEdit method is called on every databound control in where you change the (databound) content.
Since it is not necessary to keep track of the changes on such a fine-grained level (we will want to keep track of the changes on a 'form level'), we control the 'state support' by this flag.
#region IEditableObject Implementation

[NotUndoable]
private bool _bindingEdit = false;

public void BeginEdit()
{
    if( _bindingEdit == false )
    {
        this.CreateSnapshot ();
        _bindingEdit = true;
    }
}

public void CancelEdit()
{
    if( _bindingEdit )
    {
        this.RevertToPreviousState ();
    }
}

public void EndEdit()
{
   if( _bindingEdit )
   {
       this.CommitSnapshot ();
   }
}

#endregion


So, that's enough typing for today.  If you have comments, feel free to post them here or to send me an email.
In the next article of this series, I'll discuss the base classes that are used for collections of BusinessObjects.

Since I have modified the CSLA.NET framework for learning purposes, the same licence applies to it as the licence that applies to the CSLA.NET framework.


Airplanes....
2006-01-05T22:01:00.000+01:00



If you like airplanes and airshows as much as I do, then, you should definitly check out this movie (39mb).  It's an advertorial for some airshow, really nice movie.


C# 3.0 Orcas : playing with LINQ
2006-01-02T17:23:00.000+01:00
I’ve been playing around with the technology preview of C# 3.0 today.  The most important new feature of C# 3.0 is –without any doubt - LINQ.

LINQ enables you to search through collections in an SQL – like way.

For instance, instead of looping through a collection to find the Persons that live in the city that has the postal-code ‘9000’ like this:

List<person> persons = new List<person>();

persons.Add (new Person("Person1", "9000"));
persons.Add (new Person("Person2", "9870"));
persons.Add (new Person("Person3", "9000"));

foreach( Person p in persons )
{
   if( p.PostalCode == "9000" )
   {
      Console.WriteLine (p.Name);
   }
}


You will be able to get the same results, by writing the code like this:

List<person> persons = new List<person>();

persons.Add (new Person("Person1", "9000"));
persons.Add (new Person("Person2", "9870"));
persons.Add (new Person("Person3", "9000"));

var result = from p in persons
                 where p.PostalCode == "9000"
                 select p.Name;

foreach( string name in result )
{
  Console.WriteLine (name);
}


You can imagine that, for complex queries, using LINQ can be an advantage since it keeps your code more readable / understandable.

In order to be able to deliver this functionality, Microsoft had to add some other features to the language:
Implicit types

C# 3.0 introduces the var keyword.  If you take a look at the LINQ code example, you’ll see that I’ve used this keyword.

With this keyword, you don’t have to declare the type of the variable.  So, when I first saw this, I thought ‘Oh no, is this the same like the ‘variant’ type in VB, and is C# going ‘the VB way’ ?
Luckely, Microsoft has defined some ‘rules’:

When declaring a ‘var’, you’ll have to initialize the variable
You cannot initialize the variable to null.

So, these restrictions save us from the ‘variant’, because, because of these rules, the type of the variable is specified by the initializer.

The var keyword can be handy in some situations.   For instance, suppose you want a Dictionary object like this:
Dictionary<CustomerKey, Customer> custs = new Dictionary<CustomerKey, Customer> ();


You’ll be able to write it in a shorter way like this:
var custs = new Dictionary<CustomerKey, Customer> ();

Extension Methods

Extension methods allow you to ‘extend’ the functionality of a class without the need to change (and recompile) that class, and, without the need to create a subclass of that class (which is not possible if the class that you want to inherit from, is sealed.

Suppose you want to extent the Person class I’ve used in the previous example using an extension method, you’ll have to do it like this:

public static class PersonExtension
{
  public static string GetPostalCodeAndName( this Person p )
  {
       return  p.PostalCode + " " + p.Name;
  }
}


An extension method is a static method with at least one argument: The first argument of the extension method must be a variable of the type that you want to extend, and, it must be preceded by the this keyword.

The extension method can then be used like this:
Person p = new Person("Person1", "9000");

Console.WriteLine (p.GetPostalCodeAndName());


Luckely, you’re not able to access the non-public members of the class in the extension method.
Anonymous types and Initializers

These 2 features are also added to the c# specification in order to make LINQ possible.   However, apart from that, I do not see why I’m going to use these 2 features, so I’m not going to discuss them here.
You’ll find more information about these features (and about the other new C# 3.0 features) on the MSDN
DLINQ

DLINQ is a MS research project that makes use of the LINQ technology.  It allows the developer to query a database using similar statements like the ones you use with LINQ instead of using embedded SQL or calling stored procedures.

I haven’t played with DLINQ (yet), but anyway, I’m a little bit sceptical on it.
From what I’ve seen, you have to specify mapping information in your ‘domain object’, so that messes things a little bit up. 
I also wonder how this will behave with a complex domain model; in applications with a complex domain model, the domain model is not a one-to-one mapping of the database.
Anyway, it’s an experimental project, and we’ll see what the future brings.

If you want to experiment with LINQ, you can get the technology preview here

Update:The C# code that used generics was not shown properly.


Happy New Year!
2006-01-02T12:02:00.000+01:00
I'd like to wish you all the best for 2006!


Improving productivity in Visual Studio.NET
2005-12-29T20:27:00.000+01:00
John Skeet has written a nice article in where he compares Visual Studio.NET and Eclipse.   As we all know, VS.NET 2005 is the first IDE brought to us by Microsoft which gives us built-in refactoring support (finally).  While this is a nice improvement, you'll learn from the article that other IDE's still have more to offer then Visual Studio.NET.

John mentionned in his article a tool, called DPack.  This is a free VS.NET add-in, which allows you to navigate through your source more quickly.

The add-in offers a 'Solution explorer', which allows you to navigate to a specific class, without scrolling through the solution explorer or the class view.
It just takes one keystroke to bring it up, and by starting typing the name of the type to which you want to go, you can quickly go to the file that contains that type.
There's also a 'Code Browser' which allows you to browse quicker through the current code-file.

DPack also offers some shortcuts which allow you to navigate through your class more efficiently; Alt-Up arrow for instance takes you to the previous method signature, and Alt-Down Arrow brings you to the next method signature.

I've tried the VS.NET 2003 version on a fairly large solution at work, and it performs quite well.

Oh, it is also able to tell you how many code-lines and comment-lines your project contains.


Self-portrait
2005-12-29T11:27:00.000+01:00
Well, I've told that this blog would also be about photography, but, until this moment, there's not even one picture present.

So, let's start off with a self-portrait I've taken 2 months ago.

   

This picture has been taken with an analog Nikon SLR camera with a 50mm lens.  I've used a Kodak Tri-X 400 ISO film.   I have printed the photo myself.

Most of my pictures are taken with an analog SLR camera, since I do not have (yet) a DSLR.
So, if I want to put them on the Internet, I have to scan them.   Since I do not own a super-quality scanner, the quality of my digital -scanned- images, is not as good as the quality of my original prints.


Avoiding SQL injection and date problems with queries in .NET
2005-12-28T11:36:00.000+01:00
I've already written a little piece about this subject a while ago on a dutch board.
Since I've seen that a lot of people are still writing embedded queries in their applications using string-concatenation, I've decided to write a little article about it on my blog.

First things first:
Writing your embedded queries using string-concatenation like this:
string sqlQuery = "SELECT column FROM table WHERE column = \'" + 
                  aVariable +"\'";
is bad practice.

It is not easy to read, it's hard to maintain, it does not offer optimal performance but, most of all, it creates a security-leak; your query is now vulnerable to SQL-injection.

The variable 'aVariable' can contain anything, and, if you do not check the contents of the variable, some unpleasant things can happen.
Suppose that aVariable contains this:
a';drop table tablename;--

Now, if you haven't checked the contents of the variable, and took some appropriate action, the query that will be executed will look like this:
SELECT column FROM table WHERE column = 'a';drop table tablename;--'

As you can see, 2 queries will be executed:
first, a select will take place, and then, a drop table statement is executed.   As you can imagine, you -or your employer- will not be happy with this.

Another problem with string-concatenation comes to the surface when you want to filter on a date.
There are numerous ways of representing a date: dd/mm/yyyy, yyyy-mm-dd, mm/dd/yyyy, etc...
So, if you use string concatenation to create a query that filters on a date, you'll have to make sure that you use the same date-notation in your query as the date-notation that your DBMS uses.

So, to avoid these date and SQL injection problems, you can ofcourse write a bunch of code that tackles these issues but...
Why don't we let the database take care of these problems ?

This can easily be achieved by using parametrized queries instead of writing the query using string contatenation.

So, instead of writing your query like this:
string sqlQuery = "INSERT INTO customer " +
                  "( custName, city ) " +
                  "VALUES " +
                  "(\'" + name + "\', \'" + city + "\')";
you can write it like this in .NET (when you make use of the SqlClient)
string sqlQuery = "INSERT INTO customer " +
                  "( custName, birthdate, city ) " +
                  "VALUES " +
                  "(@p_name, @p_birthdate, @p_city")";
Or, if you use the OleDb namespace, you'll have to write it like this:
string sqlQuery = "INSERT INTO customer " +
                  "( custName, birthdate, city ) " +
                  "VALUES " +
                  "(?, ?, ?)";

As you can see, instead of 'inserting' the variables directly into the query, we use some kind of a 'placeholder' (a parameter).

Now, we still can't execute the query, because we need to give the DbCommand that we will use some additional information about the parameters. (We need to specify the values for instance).

This is the code that is needed to execute string sqlQuery = "INSERT INTO customer " +
                  "( custName, birthdate, city ) " +
                  "VALUES " +
                  "(@p_name, @p_birthdate, @p_city")";

SqlCommand cmd = new SqlCommand(theConnectionObj);
cmd.Parameters.Add ("@p_name",     SqlDbType.Varchar);
cmd.Parameters.Add ("@p_city",     SqlDbType.Varchar);
cmd.Parameters.Add ("@p_birthdate, SqlDbType.DateTime);

cmd.Parameters["@p_name"].Value = custName;
cmd.Parameters["@p_birthdate"].Value = dateOfBirth;
cmd.Parameters["@p_city"].Value = cityName;

cmd.ExecuteNonQuery();

As you can see, the Parameters property of the DbCommand is used to give some information about the parameters that our query contains.  For each parameter, we specify the datatype and we give it a value.
Now, we do not have to worry about escaping quotes that may appear in the customers' name, we do not have to worry about the date-notation of the date of birth, we do not have to worry about possible sql statements that are injected into the query, etc... 

(Please, check the MSDN for more information about the Parameters collection, and the overloaded 'Add' methods.  It is possible to specify output-parameters, etc..).

If you use the OleDb classes instead of the SqlClient classes, you might wonder how you will be able to make the distinction between the different parameters in one query, since you're not able to use named parameters. (You'll use a question mark as a place-holder).
Well, with the OleDb classes, you'll have to add the parameters in the correct order.
So, the first parameter in your query, must also be the first one that you'll add to your 'Parameter' collection.

Parametrized queries are not only available in .NET, they're available in any serious language.   How to use them, depends from language to language, so, refer to the documentation / manual of the language you use to see how to use them.


First post...
2005-12-26T16:02:00.000+01:00
Well, I finally took the decision to jump in the 'blogosphere', so here it is, my weblog.

While the decision to blog has been taken a while ago, my initial idea was to create my own website using ASP.NET.   However, the lack of spare time to develop this site, and the costs to host an ASP.NET driven website, forced me to start a blog on blogger.com

Anyway, maybe my own website will come over time, but, in the meantime, check this weblog regularly for my views on software development, photography, etc...

Frederik Gheysels' DevLog

WinForms: DataBinding on a cancellable Dialog Form

Forcing NHibernate to cascade deletes before updates

Google Chrome

On reading books ....

Locking system with aspect oriented programming

Intro

Enter Aspects

Bring it on

Creating the Lockable Aspect

Compile time Validation

NHibernate in a remoting / WCF scenario

NHibernate IInterceptor: an AuditInterceptor

IAuditable interface

AuditableEntity interface

IAuditable interface

AuditableEntity class

AuditInterceptor

NHibernate Session Management

New Layout

Setting Up Continuous IntegrationPart II: configuring CruiseControl.NET

The ccnet.config file and multiple project-configurations

The CC.NET config file

MSBuild doesn't support my sln file format

The MSBuild XmlLogger Issue

Setting Up a Continuous Integration process using CruiseControl.NET and MSBuild.Part I: creating the MSBuild build script

Intro

Requirements

The MSBuild build-script

Skeleton of the buildscript

Clean Target

Getlatest Target

BuildAll Target

NUnit Target

FxCop Target

Executing Targets via MSBuild

using directives within namespaces

VS.NET 2008: Form designer not working on Windows Vista

Debugging the .NET framework

Cannot open log for source {0} on Windows 2003 Server

Castle Windsor and ActiveRecord

New debugging experience in VS.NET 2008

MSDN RampUp

MS LEAP Programme, yet another rant.

Auto-Formatting in VS.NET 2005 does not work anymore

Cleaning a Keyboard

C# 3.0: new language features

XSD Schema for configuration of Log4Net

NHibernate & MS Access: problems with autonumber fields

Counting in SQL Server: SELECT COUNT(*) != SELECT COUNT(columnname)

Dependency Injection versus Service Locators

NHibernate Session Management in Domain Driven App's

Article: NHibernate best practices with ASP.NET

Split

.NET 1.1: Problems when selecting rows from a DataTable using an aggregate filter

Tagliatelle - scampi

Oudenaarde by Night

DDD: implementing persistence using NHibernate

Introduction

The Database Schema

NHibernate configuration

NHibernate mapping files

Integrating NHibernate in the project

Creating Repositories for our Domain classes

Using NHibernate in the client application

Meet My Mom

Lambda expressions in .NET

Tagged

Left- and RightPadding in SQL Server

Shelfari Bookshelf

VS.NET 2005: XML View of a Typed DataSet

Official owners

High Key

Nested Transactions in SQL Server

Savepoints to the rescue

Aspect Oriented Programming in .NET

Changing the default access modifier when adding a new class in VS.NET 2005

Session on Unit Testing & TDD

VS.NET 2003 not supported on Vista ?

Collections in Business Entities

`IAuditable` interface

`AuditableEntity` interface

`IAuditable` interface

`AuditableEntity` class

`AuditInterceptor`