Saturday, February 09, 2008

DataSets - Love em Hate em

I have a love-hate relationship with DataSets.  On the one hand they are easy to use and contain lots of built in functionality.  On the other hand they are abused by almost everyone but at the same time severely under utilized, meaning that I rarely see anyone use most of the features available.

I get the feeling that the majority of developers that use DataSets have blinders on:  DataSets are only useful for reading and writing data to the database.  End of story.  If you are an ASP.NET developer you absolutely refuse to use them and use DataReaders only.  And in the last three years I have not seen too many applications that use the typed DataSets that can be created in Visual Studio 2005.

I don't like using DataSets because I prefer to use NHibernate or ActiveRecord to interact with databases.  But lately I have been having a change of heart as I have been delving more and more into using DataSets in the application I am currently working on.  There is a lot of functionality baked into DataSets that I have been overlooking and since I have been working with the strongly typed DataSets generated by VS 2005 I have to ask myself why I need to recreate it with POCO's.

The way I am looking at DataSets now is not as an in-memory relational database but as a highly versatile data structure that handles a lot of things I need it to handle:  Relationships, constraints, databinding, serializable and data error information.  Sometimes I see it as being nothing more than a collection of Hashtables, each Hashtable being another collection of Hashtables.  And the fact that there is a designer to work with it makes it better.

I worked on a home grown messaging system project, the message object orginated as an XSD that got converted to C# classes using the xsd.exe tool.  The tool didn't work to well (this was in .NET 1.1) so all the names and name spaces were so screwed that most of the classes had the name space in the class name.  Intellisense really sucked at times.  Me being who I am I started trying to figure out a simpler message object when it donned on me that a DataSet would have been a perfect fit for what they were doing.  A .NET 1.1 DataSet serialized to XML was ugly but in 2.0 it got a much needed face lift.   You should have seen them laugh at me when I suggested switching the message object out.  "You dummy, DataSets are for Databases!!  Ha Ha Ha, we're writing SOAP messages!" 

Yeah, I left that place.

When it comes to data binding DataSets can't be beat.  WinForms have been especially built for binding to DataSets.  One thing I wished that would be easy to do is to bind one DataSet to another without using  form.  Currently I have a form that has two user controls, each with its own DataSet that require data in one form to update data in the other.  I am working on a way to databind the two DataSets together, currently the form is manually updating the data in the other DataSet as it changes.  I want to pull all the code out of the forms and create a Database Synch Service.

A lot of the data validation I have seen in OPA's (other peoples apps) has been in the form.  Typcially if an error occurs a nice little pop-up shows some nasty message then either won't let the user save the data or reverts it back to a previous value.  DataSets have a way to set a Row and Column with a specific error message which can be used by the form to indicate there is an error.

As for the actual validation, I want to create a dictionary of methods  to validate the DataTables and DataColumns.  The validators would take the row, column and DataSet being validated and the validation errors will be entered using the rows SetColumnError method.

Still though, DataSets are going to become mute when Linq comes out.  Maybe.

Tuesday, February 05, 2008

Value Objects as Measurement Objects

So I was reviewing PEAA looking to see if Fowler had come up with the idea of Measurment Objects, that horse I've been kicking around lately.  I found that he has a couple of close patterns:  Value Object and Money.

Value Object:  A small simple object, like money or a date range, whose equality isn't based on identity.

Money: Represents a monetary value.

According to Fowler Value Objects are light weight and almost primative types.  They should also me immutable since they have no identity.  He also suggests that in .NET structs could be used as Value Objects.

The money pattern looks like a special case of a Measurement Object with the UnitOfMeasure being set to currency (currency being USD or Euro).

I see the usefulness of using structs but there is the boxing issue if we implement them with interfaces.

I will have to ponder on this.

Monday, February 04, 2008

Measurement Objects

In my previous post I described setting up a database to track measurements.  I ran into problems quickly with the data model and I could see that it was going to become a convoluted mess pretty quick.  So I want to take a step back and look at it from an application point of view.

What I want is a way to track an objects measurements.  I need a system that is easy to understand, any one looking at an object should readily understand what each measurement property is and what units it is in.  The system should accommodate almost any existing system of measurement but at the same time it needs to be simple.  Brain dead simple.

Measurement Object Diagram
What I am thinking is to start out with a abstract base class for our Measurement Object.  It has an ID that can be an int, string or Guid, take your pick.  The Text property is the string representation of the Value, Value being in an abstract class that extends MeasurementBase.

I think that it is important to seperate the actual Value into another class of Type T.  This allows us to create collections of MeasurementBase objects and add MeasurementBase<T> objects to it.  I am still struggling with this idea as it totally blows apart expectations on what a Value is (is it an int?  a DateTime?), but this is the reason I stuck the Text property on the MeasrumentBase.  The Text property takes care of the conversion of the string representation to the actual Value.

Already this is getting complicated.  What is it I'm trying to do here?

My ultimate goal is to have the means to convert a measurment from one system to another.  The objects themselves should take care of the conversion.  The way I have seen it in the past is to have conversion code scattered throughout the entire application layer, including the UI and the data access layer.

This is one of those ideas that is on the tip of my neurons, I know it has been solved before but I haven't found it.  And every time I start working on it I naturally want to drop into the Database thinking frame of mind.

I need to review some of the Enterprise Patterns, see if it already exits.