Stop, Drop, and Roll

  • Article

A couple of weeks ago, I made a post that I thought some sort of client side data structure, which was designed to store projections of a domain model instances (both in memory and persisted in a data store), was a necessary part of any O/R framework. My conjecture was that this was required due to the current limitations of the mainstream programming languages with respect to dynamic typing in addition to the fact that most client side caches provide a common set of services which can be applied to both tuples and object graphs.

Amazingly enough, I was flamed by both camps – the dataset crowd and the O/R guys, which is quite a feat. However, surprising to me, was how polarized this issue had become.

Obviously, either I was not correct, not clear about my points, or some in the development community didn’t want to hear what I said.

This entry is an effort to clear up my original post – if you still don’t agree, please feel free to flame away.

So – my original points were:

  1. Projections, whether over relation tables or objects graphs are a very important cog of most enterprise applications.
  2. None of the .net languages or Java have a good way of natively exposing or storing the results of the projection. Hence, types like DataRow exist.
  3. Existing relation caches (for example, like the DataSet) offer a number of services which are interesting to both tuples and object graphs.

There is no doubt in my mind that #2 from above will change long term. Even some of the work coming out of Microsoft shows that better solutions are being worked on. For example.

But as of today, it seems like current O/R frameworks have an inherent weakness with projections. The two most popular existing solutions I have seen is to support dynamic instantiation or return object arrays. My belief is utilizing a client side relation cache (for example – like the DataSet) is superior to the latter in almost every case or to the latter in cases where this is going to cause type inflation (MyPartialCustomer) or when clean updateability is required.

I would also push back of the DataSet crowd with some similar arguments. First, you may not believe it, but O/R frameworks are designed to take care of a lot of code that you currently have to write yourself. Second, do you really like the DataSet (i.e. The API and architecture) or do you like the rich services it provides which in most cases are the same services required by a good O/R framework? My guess is that in most cases it is the services.