Baseball is very much a statistics-oriented game. Consider fielding statistics: putouts (PO), assists (A), errors (E) and others. These stats need to be stored:

On the database side, that results in three tables: GameFieldingStats, SeasonFieldingStats, and CareerFieldingStats. Each has the same set of fields to store the statistics (PO, A, and E); the differences are . . .

→ Read More: Operator overloading your domain model with interfaces and base classes]]> One of the challenges in rewriting my online baseball game is dealing with enormous amounts of data that needs to be stored as aggregates, and coming up with a domain model and data mapping pattern that works. In this blog post, I’ll outline how I addressed some of those issues.

The Data Model

Baseball is very much a statistics-oriented game. Consider fielding statistics: putouts (PO), assists (A), errors (E) and others. These stats need to be stored:

• Per game, for each player who played in the game, for each position he played (key fields: game, player, position)
• Per season, for each player, for each team he played for, for each position he played (key fields: season, player, team, position)
• Career, for each player, for each position he played (key fields: player, position)

On the database side, that results in three tables: GameFieldingStats, SeasonFieldingStats, and CareerFieldingStats. Each has the same set of fields to store the statistics (PO, A, and E); the differences are in the key fields for each, as outlined in the diagram below. (Note: For the remainder of this post, I’ll include only the first two of those tables to keep things short.)

Writing the domain model for each of these tables is quite easy. The following snippets shows the class declaration for each, including Castle ActiveRecord attributes. Note that these classes inherit from a base class, EntityBase<T>, which in this project is a requirement for all domain objects.

[ActiveRecord("bb_gamefieldingstats", Lazy = true)]
public class GameFieldingStats : EntityBase<gamefieldingstats>
{
    //...
}
[ActiveRecord("bb_seasonfieldingstats", Lazy = true)]
public class SeasonFieldingStats : EntityBase<seasonfieldingstats>
{
    //...
}

Use cases, interfaces, base classes, and operator overloads (whew!)

Now that I have these classes, I want to use them! After each baseball game is simulated, a number of GameFieldingStats records are created to reflect the statistics of that game. I want to add those stats to the player’s SeasonFieldingStats. I could access the similar properties in each class (PO, A, E) and add them together, but that’s not what I want. I want to do this:

GameBattingStats gbs = new GameBattingStats();
SeasonBattingStats sbs = new SeasonBattingStats();
// use cases follow
SeasonBattingStats combined = sbs + gbs;
SeasonBattingStats removed = sbs - gbs;
sbs += gbs; //!!

It’s easy enough to do that using operator overloads in C#. To make that work, I need all fielding stats classes to inherit from a base FieldingStats class that implements the operator overloading. I’m going to take it one step further and add an IFieldingStats interface. The class diagram below shows how this was done.

Unfortunately, by doing this, I can no longer have GameFieldingStats and SeasonFieldingStats inherit from my domain object base class, EntityBase<T> (since C# doesn’t allow multiple inheritance of classes). To resolve that, I made FieldingStats into a generic class, and had it inherit from EntityBase<T>. The class diagram shows the adjusted model.

The operator overloads are implemented on the generic FieldingStats<T> class, as follows:

public static T operator +(FieldingStats<t> fs1, IFieldingStats fs2)
{
    if (fs1 == null)
        throw new ArgumentNullException("fs1");
    if (fs2 == null)
        throw new ArgumentNullException("fs2");
    T fs3 = new T();
    fs3.A = fs1.A + fs2.A;
    fs3.E = fs1.E + fs2.E;
    fs3.PO = fs1.PO + fs2.PO;
    return fs3;
}

So far, so good. Everything compiles, and on paper it works. But how do we test it?

Unit testing: does it work?

To test this, I wrote the following unit tests.

[TestFixture]
public class FieldingStatsTests
{
	[Test]
	public void AddFieldingStatsTests()
	{
		GameFieldingStats fs1 = new GameFieldingStats();
		fs1.PO = 1;
		fs1.A = 2;
		fs1.E = 3;

		IFieldingStats fs2 = new GameFieldingStats();
		fs2.PO = 100;
		fs2.A = 200;
		fs2.E = 300;

		IFieldingStats fs3 = fs1 + fs2;
		Assert.AreEqual(fs3.PO, (fs1.PO + fs2.PO), "Adding FieldingStats yields incorrect PO");
		Assert.AreEqual(fs3.A, (fs1.A + fs2.A), "Adding FieldingStats yields incorrect A");
		Assert.AreEqual(fs3.E, (fs1.E + fs2.E), "Adding FieldingStats yields incorrect E");
	}
}

All tests pass!

By combining the base classes, interfaces, generics, and operator overloads, I can now add and subtract domain objects from each other, and my code has become much more readable. It wasn’t obvious how to do it at first, but once the pieces fell together, it made perfect sense.

I took the test and scored a 75 out of 100 (without cheating, mind you), and was told I may make a great addition to Magenic. Unfortunately, I live in New York, and I’m not relocating. Besides, I just put in my resignation with my current employer so I can go back to independent consulting, so I’m not exactly on the market for full-time employment… but more on that another day.

If you were parsing a list of states, it might look like this:

Alabama, Alaska, Arizona, Arkansas

There’s an easier way to handle these simple needs: create a CollectionToString() method. This method would accept an IEnumerable and, using reflection, read a property and return a delimited string. Of course, you choose the property and delimiter.

Note that we have two versions of this method: one which accepts an IEnumerable, the other which accepts an object. This is done to avoid the necessary typecasting in your code, since Eval() returns everything as an object.

For some time I have been toying with the idea of rewriting WORW to support a generic repository service that would work with any O/R mapper, much like the logger and cache services work over different underlying libraries. By removing the static classes and singletons and adding a provider model for the O/R wrapper element, you would be able to instantiate multiple instances of a “Registry” class, a class which provides a set of services (Repository, Cache, Logger, etc.) based on a given configuration criteira.

As a test I wrote up a simple project (with unit tests!) as a proof-of-concept, using WORM and NPersist as underlying O/R mappers. The WORM part worked fine. The NPersist part almost worked — however, I believe the errors are related to using NPersist’s not-too-well-documented XML provider, . . .

→ Read More: A repository that works with multiple O/R mappers — is it possible?]]> A recent post on the WilsonORWrapper Google group talked about making WORW multi-database aware by removing static classes and singletons. Well, I’ve kind of been thinking of something similar lately…

For some time I have been toying with the idea of rewriting WORW to support a generic repository service that would work with any O/R mapper, much
like the logger and cache services work over different underlying libraries. By removing the static classes and singletons and adding a provider model for the O/R wrapper element, you would be able to instantiate multiple instances of a “Registry” class, a class which provides a set of services (Repository, Cache, Logger, etc.) based on a given configuration criteira.

As a test I wrote up a simple project (with unit tests!) as a proof-of-concept, using WORM and NPersist as underlying O/R mappers. The WORM part worked fine. The NPersist part almost worked — however, I believe the errors are related to using NPersist’s not-too-well-documented XML provider, not errors with the O/R mapper provider itself (NPersist does initializes properly, which indicates at least something is working right).

If you’re interested in seeing this little stub of a project, download the source (27.5kb). I’ve dubbed it NRepository right now, not for any reason except it’s the first thing that came to mind. Let me know what you think, and whether you think it’s worth pursuing such a project.

This method may have interest to people who don’t use WilsonORWrapper, so here’s an extracted version of the code that does the comparison.

With that, if you had a Name class in your code that had two properties, First and . . .

→ Read More: Use reflection to compare the properties of two objects]]> In an update to WilsonORWrapper, I added a method which takes two objects of the same type and compares the properties of each, returning a value reflecting the results of the comparison. Any value other than zero would indicate that at least one property on the objects are not equal.

This method may have interest to people who don’t use WilsonORWrapper, so here’s an extracted version of the code that does the comparison.

using System;
using System.Reflection;

public static class ObjectHelper<t>
{
	public static int Compare(T x, T y)
	{
		Type type = typeof(T);
		PropertyInfo[] properties = type.GetProperties(BindingFlags.DeclaredOnly | BindingFlags.Public);
		FieldInfo[] fields = type.GetFields(BindingFlags.DeclaredOnly | BindingFlags.Public);
		int compareValue = 0;

		foreach (PropertyInfo property in properties)
		{
			IComparable valx = property.GetValue(x, null) as IComparable;
			if (valx == null)
				continue;
			object valy = property.GetValue(y, null);
			compareValue = valx.CompareTo(valy);
			if (compareValue != 0)
				return compareValue;
		}
		foreach (FieldInfo field in fields)
		{
			IComparable valx = field.GetValue(x) as IComparable;
			if (valx == null)
				continue;
			object valy = field.GetValue(y);
			compareValue = valx.CompareTo(valy);
			if (compareValue != 0)
				return compareValue;
		}

		return compareValue;
	}
}

With that, if you had a Name class in your code that had two properties, First and Last, you could do something like this:

Name n1 = new Name();
n1.First = "Brian";
n1.Last = "DeMarzo";

Name n2 = new Name();
n2.First = "Brian";
n2.Last = "DeMarzo";

int result1 = ObjectHelper<name>.Compare(n1, n2);
// result1 == 0 because n1 and n2 have equal properties

n1.First = "Alyssa";
// change the first name, so n1 should no longer equal n2

int result2 = ObjectHelper</name><name>.Compare(n1, n2);
// result2 != 0 because n1 and n2 do not have equal properties

Code like this came in handy in my project where I use FileHelpers (see my blog entry from earlier today), where I was able to compare a class loaded from the database (using an O/R mapper) with a class loaded from a text file (using FileHelpers). Since the O/R mapper and FileHelpers used the same class, using this comparison method to determine if the objects were “equal” let me determine whether or not the data loaded from the database was different from the data in the text file.

Even though it used reflection, there wasn’t a huge performance hit, either. Sure beats writing manual comparison methods, which could take a while when you have a few dozen classes!

Here’s a sample of the XML I needed to incorporate:

The typical solution is to write your own collection class (FilespecConfigurationElementCollection), inheriting from ConfigurationElementCollection, and ensuring your Filespec object inherits from ConfigurationElement. I figured there has to be a better way — and there is.

I wrote a generic version of ConfigurationElementCollection, which you can use to avoid writing the custom collection class. The code that follows is the generic class, the Filespec object I used, and the property declaration from my ConfigurationSettings class (as described in Phil’s previously mentioned article).

Note one key part of this implementation: You must override the ToString() method of your custom ConfigurationElement class to return a unique value. The generic ConfigurationElementCollection uses the ToString() method to obtain a . . .

→ Read More: Simplify configuration with a generic ConfigurationElementCollection class]]> I’ve been using Phil Haack‘s Custom Configuration Sections in 3 Easy Steps for some time now, and my configuration file management has never been happier… until I needed to read a collection of configuration elements.

Here’s a sample of the XML I needed to incorporate:

<importer>
	<filespecs>
		<add type="EmployeeCSV" path="d:\import\employees.csv" />
		<add type="OrderCSV" path="d:\import\orders_*.csv" />
	</filespecs>
</importer>

The typical solution is to write your own collection class (FilespecConfigurationElementCollection), inheriting from ConfigurationElementCollection, and ensuring your Filespec object inherits from ConfigurationElement. I figured there has to be a better way — and there is.

I wrote a generic version of ConfigurationElementCollection, which you can use to avoid writing the custom collection class. The code that follows is the generic class, the Filespec object I used, and the property declaration from my ConfigurationSettings class (as described in Phil’s previously mentioned article).

Note one key part of this implementation: You must override the ToString() method of your custom ConfigurationElement class to return a unique value. The generic ConfigurationElementCollection uses the ToString() method to obtain a unique key for each element in the collection.

// The ConfigurationElementCollection<t> provides a simple generic implementation of ConfigurationElementCollection.
[ConfigurationCollection(typeof(ConfigurationElement))]
public class ConfigurationElementCollection</t><t> : ConfigurationElementCollection where T : ConfigurationElement, new()
{
	protected override ConfigurationElement CreateNewElement()
	{
		return new T();
	}
	protected override object GetElementKey(ConfigurationElement element)
	{
		return ((T)(element)).ToString();
	}
	public T this[int idx]
	{
		get { return (T)BaseGet(idx); }
	}
}
// The Filespec class is an example of a custom configuration element.
// Note that we inherit from ConfigurationElement, and use ConfigurationProperty attributes.
public class Filespec : ConfigurationElement
{
	public Filespec()
	{
	}
	[ConfigurationProperty("path", DefaultValue="", IsKey=true, IsRequired=true)]
	public string Path
	{
		get { return (string)(base["path"]); }
		set { base["path"] = value; }
	}
	[ConfigurationProperty("type", IsKey=false, IsRequired = true)]
	public FilespecType Type
	{
		get { return (FilespecType)(base["type"]); }
		set { base["type"] = value; }
	}

	public override string ToString()
	{
		return this.Path;
	}
}
// Finally, our ConfigurationSettings class (only part of the class is included).
// Note how we use the generic ConfigurationElementCollection.
public class ConfigurationSettings : ConfigurationSection
{
// ...
	[ConfigurationProperty("filespecs", IsRequired=true)]
	public ConfigurationElementCollection<filespec> FileSpecs
	{
		get { return (ConfigurationElementCollection</filespec><filespec>)this["filespecs"]; }
	}
// ...
}

If you’re using a number of ConfigurationElementCollections, this is a great way to simplify your code.