Roger Alsing Weblog

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.

Pretty slick IMO.

//Roger

I have added the Caramel code generator to my public repository at google code.
http://code.google.com/p/alsing/

Please note that this is very very alpha and not actually useful yet.

Before it can be used I need to finish the template support and fully implement the DB meta data importer.

But if you are interested in this kind of stuff and want to help out building it, please let me know.

I’ve been working some more on the UML editor for Caramel.
I’ve added comment elements and relations to the editor now:

For those who havent read my earlier posts:

Caramel is a hybrid between old school code generators and Entity Mapping tool.
You can also plug in your own node types in the meta tree, and thus allowing you to generate pretty much whatever you want.

My intention is to release it with built in support for the most common O/R Mappers so you can build your domain models for NHibernate, NPersist etc in Caramel.

And I might also add some simplistic web page support so you can generate edit/list pages for the mapped entities.

Anyway, here are some new screenshots.

Summary:

Template Editor:

Class Designer:

//Roger

As some of you might know, I’ve been working on a class designer (Albino horse) off and on for a while now.

I’ve also started to work on a code generator where the class designer will be used.
The code generator will be a sort of hybrid between old school DB code generator and Puzzle ObjectMapper.

You will be able to edit domain models and table models just like ObjectMapper, but you can also add your own kind of nodes, making it possible to extend the generator for pretty much whatever you want.
Eg. you could add nodes for different types of web pages and map entities to those and genereate entire apps.

Enough talking, a picture says more than , all the blabbering above

Very very alpha’ish screenshot of the generator:

Once I’ve added a bit more functionallity and cleaned it up a bit I will publish it on codeplex.

Patrik Löwendahl blogged about using C#3 features in .NET 2 via VS.NET 2008 a few days ago:
http://www.lowendahl.net/showShout.aspx?id=191

There are quite a few of the new features that works straight out of the box.
However, Linq does not, alot of the code that Linq uses is simply not present in the .NET 2 BCL.

So, inspired by Patriks post I opened up an old custom Linq engine that I wrote a while back and spiced it up and adapted it for .NET 2.
I also added a few of the standard list extensions such as “Take” “Skip” etc.

The code can be found here:
www.puzzleframework.com/Roger/LinqForNet2.zip

And before you get all excited, this is only Linq to objects, NOT Linq to SQL….

The code supports the following Linq constructs, features and list extensions:

• from (ok ok, I didn’t have to code anything for that)
• where
• join
• groupby
• orderby
• select
• Take
• Skip
• TakeWhile
• SkipWhile
• Distinct
• Deferred execution

Enjoy : - )

 //Roger

I’ve been digging through the ObjectDataSource today and I was trying to figure out how they created the datasource instance from the type name.

Now some clever reader might say “I know, I know, Type.GetType(string)”… But that’s wrong..
Type.GetType(string) requires full type names with assembly name and the whole shebang.

The ObjectDataSource is able to create instances w/o all that information.
So after a while of digging I found a precious gem, hidden in System.Configuration:
“BuildManager.GetType(string)”

Very very nice

I can now inherit ObjectDataSource and fetch the type via buildmanager and then call NAspect to proxy the type and get an AOP enabled datasource.

Thats all for now, just wanted to share this one

I’ve finally seen my own Linq support Live
Untill now I’ve only been emitting NPath quereis and verified that NPath is correct.

The reason I havent tested it live untill now is that I only have my gaming machine to develop on atm. the dev machine is dead.

Anyway, I’m trying it against NWind MS Access DB right now and it works like a charm.
I can even run fairly complex queries, even if it takes a bit of time on MS Access.

var res = from cust in ctx.Repository<Customer>()
          where
          cust.Orders.Any(
                 order => order.OrderDetails.Sum(
                     detail => detail.UnitPrice * detail.Quantity
                                                ) > 1000)
          orderby cust.CompanyName
          select cust;

This lists all customers that have atleast one order with the order total of 1000$.
I was a bit nervous before and thought that maybe it will fail.. even though the NPath looks correct and the NPath to SQL generator have been working fine for the last 3 years

I’ve added a bit more Linq support for NPersist today.

The nice thing is that we can “cheat” in our Linq provider, we can transform our Linq queries into NPath queries.
Thus, I don’t have to touch the wicked SQL generation.
I just have to produce valid NPath, which is pretty similair to Linq.

Just look at the following code:

private string ConvertAnyExpression(MethodCallExpression expression)
{
    string fromWhere = ConvertExpression(expression.Arguments[0]);    
    if (expression.Arguments.Count == 1)
        return string.Format(”(select count(*) from {0}) > 0″, fromWhere);
    else
    {
        LambdaExpression lambda = expression.Arguments[1] as LambdaExpression;
        string anyCond = ConvertExpression(lambda.Body);
        return string.Format(”(select count(*) from {0} and {1}) > 0″, fromWhere,anyCond);
    }
} 

Thats all the code that we needed in order to support “list.Any()” and “list.Any(x => ….)”
This both makes the Linq provider easier to build, and it makes it way easier to unit test it too.
We simply have to compare the result with an expected NPath string.
Like this:

string expected = "select * from Customer where ((Customer != ?))";
string actual = res.Query.ToNPath();
Assert.AreEqual<string>(expected, actual);

So I think we have most of the standard query elements in place now.
I just have to add support for a few more things inside NPath, things like “skip”, “is” etc.

The old ObjectMapper 2000 was and still is a great tool and I have used it in lots of projects to generate and map my entities.
But one thing that is clear, is that it was way way too complex for most users, it had more settings than the space shuttle and could be a real PITA in some cases.

So me and Mats have talked about adding mapping support inside VS.NET, much like the Linq to SQL mapping designer.
We haven’t actually decided exactly how it’s going to work yet, so there is not much to get excited about for now.

Anyway, I’ve started to build a visual class designer for it.
The control will be possible to use for any kind of Windows Forms project and will not be bound to Object Mapper.

Screenshots:

Main view and overview overlay:

Zoom in and out:

 Expand / Collapse:

Custom styles:

 I’ve also added some auto layout code to it, but it’s based on spring algorithm, which isn’t very good for class diagrams.

Well, if anyone is interested in some colaboration on this one let me know.
I figure that a decent UML’ish designer could be useful for more than us.
The plan is to release the designer as a standalone project anyway.