zaterdag 18 februari 2006

A 'problem' with custom configSections in .NET 2.0

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.

dinsdag 14 februari 2006

Domain Driven Design / Entity (Yourdon-Chen) approach

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.

vrijdag 10 februari 2006

Better performance when loading a typed dataset.

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.

donderdag 2 februari 2006

Business Objects Framework - Part 3: Lazy Loading

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 ();
}
}

...