TechShorts

I was working on a WinForm app that connected to a MS Access database. Yeah, Access sucks but I didn't have a choice in the matter. The app itself is used to import a bunch of CSV files into the Access database. It is more of a utility program and it has going through several variations, from being a simple hand driven command line tool to being GUI driven. The command line version was all hand controlled. I had to go in and update configuration files to point to the CSV files and the MDB database. That got old fast so I decided to make a GUI version that would allow me to pick the MDB file and each of the CSV files to import. Picking and using the CSV files was easy, it was changing the connection string for the MDB that proved to be the hardest. I am using strongly typed datasets in VS2005. If you have ever worked with them you find out soon that the connection string gets saved with the project in the app.config file, even if it is a seperate DAL dll project. My guess is

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 ba

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.

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. 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

I am sick of working with databases, they all suck.  I can generalize this to any type of data store, they all suck. OK, they don't really suck but I sure have seen a lot of database designs that do.  I am tired of working with applications that have lots and lots of large tables, tables with lots and lots of fields.  Of course all the fields but the primary key are nullable because you might not always need that extra address field but it is there, just in case. And don't get me started on compound primary keys.  If I see tables with compound primary keys then I am trying to get off of that project. What if we have to change the database, add a field, remove a field or just plain rename a field?  Well that just broke the application, not just the code you own but the code in a module you never heard of that the reporting team is using.  Why can we not update schema's without worrying about causing the build to fail? And what about all the boiler plate code needed to commun

Those are the words spoken to me by my son. He was playing with his GI Joe (one of the fake all plastic ones) when he accidentally pulled off its head. Oops! This sucks because now I have to retape the head on evy time it falls off. Of course the real GI Joe's head wouldn't have come off so easy. Growing up we used to regularly abuse them by dropping them off of roofs, blowing them up with fire works, running them over with the car, etc. and they always survived. These cheap plastic ripe offs, well they just suck.