Mostly C#, DDD and Akka.NET

Month: July 2008

OK, I’ve had it with the serializers in .NET.
All of them are lacking atleast some features that I need.

XML serializer can not handle circular references.
Soap serializer can not handle generics.
Binary serializer is decent but will crash and burn if your class schema change (this applies to all the others to).

And then we have all those WCF thingies, but they require contracts/interfaces.

So I got tired of this mess and I’ve finally rolled my own XML serializer.

My serialzier supports:

Circular references

Generic lists

Error resolution

Clean XML format

The error resolution works by raising events so that the developer can either ignore errors or resolve fields and types himself.

I have also added a default resolver that will handles missing “backing fields”

I’m using this serializer in Caramel Studio for the save file format.
So even if the model for my Caramel classes changes, you will still be able to load the files and you will only lose some settings.

Currently lists will be treated in a special way, so only content of lists is serialized, any other custom state in a list will not be serialized.
I will add support for this later.

Multi dimentional arrays are not supported yet.

Work in progress:

I will make it possible to substitute types on serialization and deserialization, so that you can serialize graphs of proxy objects and then deserialize the same graph again by letting your proxy factory create the instances for you.

In Jimmy Nilsson’s book “Applying Domain Driven Design and Patterns” he writes about a project of his called “NWorkspace”, which is a kind of abstraction layer for O/R mappers.

The concept is to let your Repositories only talk to the workspace abstraction, making it possible to swap underlying mapper.

The biggest problem with such abstraction is querying, there have never existed a standard way to make queries for domain models in .NET.
So you end up abstracting the querying mechanism too, and that in turn forces you to create translators from your own query model to the underlying mappers query model.

Now days we have Linq.
Linq allows us to create queries in a standardized way against domain models.

So, yesterday I decided to try to make a Linq based abstraction layer in the spirit of NWorkspace.(Note: My project is simply a ripoff from Jimmy’s concept, there is no relation to the real NWorkspace)

First I had to pick some different persistance tools, so I decided to go with NHibernate, LinqToSql and DB4O (object DB for .NET)

Once I had selected the persistence tools I started writing my abstraction layer.
It turned out to be really easy to implement, one interface with five methods:
LinqQuery[of T] //creates a Linq query
Add(T) //attaches a transient entity to the workspace
Delete(T) //removes a persistent entity from the workspace
Commit() //commits all changes to the persistent store
Rollback() //discards all changes

I then created an implementation for each of the persistence tools for my interface.

So now I can pass instances of my workspace into my repositories and make them operate almost agnostic of what persistence tool I use.

I say “almost” because there are a bit too many differences between the tools when it comes to query support and entity design.

LinqToSql is far from being POCO / PI, and even if NH and DB4O are both POCO’ish, there are still differences.

There are also differences in the Linq support, so you can not always run the same type of queries against the different workspace implementations.

But all in all, it turned out really nice, making the Repository design much cleaner.
As long as you adapt your domain model for whatever persistence tool you use and don’t use too complex queries, the most of your repositories and business logic can remain unchanged.