Object Relational Mapping can help Domain Driven Design

In the book Domain Driven Design, Eric Evans promotes something called a ubiquitous language. The idea behind a ubiquitous language is that you have a consistent terminology that is used everywhere. Both business and technical experts should find and use this terminology in their conversations, and the terminology should appear directly in the source code, the database schema and also any written documentation. I guess he's basically saying that the language of the domain should be present and consistent throughout the entire "problem and solution space". This means that we don't have to work hard to translate between mental models.

I like this idea. It seems to eliminate redundent and duplicated terminology therefore making things simpler and less ambiguous. If you think about it, the language directly represents the concepts of the problem, so it makes sense to nail it down and use it consistently.

I'm striving to adopt this approach. One of my first problems is that I've been a little bit slack in keeping my database schema in check with the my domain objects. ReSharper doesn't automagically refactor my table names when I rename classes, so getting ubiquitous with my language requires more discipline 8-) So far I've tended to put this kind of thing off for a "rainy day". This is a bad habbit because rainy days don't seem to happen in my job. To make matters worse, it's going to be really tedious looking through all the classes and all the tables and columns working out where the language used is "out of date" or inconsistent. Or is it?

Today I realised something that's going to help me. I'm currently using NHibernate to map between by domain objects and my database. It occurred to me that the mapping files make a great single place to check that the language used in the database and objects is consistent. I reckon I can put a few hours aside to scan through the mapping files making note of any columns and tables that are named incorrectly. I can then simaltaneously write database update scripts and tweak the mapping files so that the database schema is corrected. How's that for getting a little leverage out of those hbm.xml files? 8-)

I guess this idea might be obvious to some, but I think it *is* going to be a useful when it comes to checking that language truly is consistent across databas objects and domain classes.

Business Objects to DataSets and XML

If you use business objects in your .NET applications, you may find yourself in situations where you need to extract data from these into another representation. One example might be if you use some reporting software that expects to bind to datasets rather than business objects. I've been looking around for solutions to this problem, and here's what I've found so far. Please feel free to give any comments/success stories or alternatives if you know of them.

Option 1)
Rockford Lhotkas CLSA library has a class called ObjectAdapter. This flattens an object into a dataset. It doesn't follow relationships, and I think it's read only. But, it's a good start from the looks of things. I took the code out of his book, but if you google it I'm sure you can come find something downloadable.

Option 2)
There's a few folk talking about something called UI Mapping (a term coined by Paul Wilson who makes WilsonORMapper and soon the WilsonUIMapper). This is basically taking objects and mapping them to UI widgets. Whilst a UI mapper won't necessarily help you get objects into datasets, it has caused people to think about this kind of problem. One project that I think looks promising is NView (http://blogs.wdevs.com/phirephly/). This is not a UI Mapper as such, but a tool to allow you to map from one conceptual view to another. You can easily map from an object graph to a dataset, for example. Also, the view can be bi-directional, which means that 2-way databinding is possible. I tweaked the example source code and was generating heirarchial datasets from objects in 7 lines of code.

Option 3)
What I've been doing in the past is using some home grown code to convert an object graph into XML. I then use this to create reports using XSLT. It might not be great for all needs, but so far it's been handy for web based invoices, purchase orders, letters and that kind of thing. The code works using reflection to walk an object graph and write out XML. It also allows you to specify a fetch plan so that it doesn't export the entire object graph. I can't share this code, but it wasn't too hard to write based on the power of reflection. You may wonder why I didn't use just make my objects XML Serializable - personally I find this tricky in many cases because you have to do a bit of tayloring to make your classes suitable.

I've not tried the above approaches in a commerical project yet, although I especially like the look of #2. A while back I was talking to Thomas Tomiczek who works on Thonas EntityBroker product. If I remember correctly their product also uses a kind of ObjectAdapter/ObjectView to allow mapping of objects to grids/GUI. Has anyone used this, any opionions to report back?

Blog Moved!

I'm now using Blogger.com to host my blog. I decided that I don't have time to continue my own blog engine. I've basically swiped all the content over manually, so sorry if things look a bit messy! You shouldn't need to update your RSS client, since I've just had the old page output the new feed! Does that make any sense!