Partager via

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.

Comments

  • Anonymous
    March 28, 2005
    It really should be obvious to everyone by now that neither the O/R nor the Dataset approach is sufficient to model real businesses. Just go ask somebody off the street what sort of behavior a purchase order has. Or think about why you shred that purchase order into rows in 14 different tables. We'll always need the relational view for reporting, but when your writing the processing part of the application, it's a different story. It's all about messages, documents, services, and business processes.
  • Anonymous
    March 28, 2005
    The comment has been removed
  • Anonymous
    March 28, 2005
    Andrew

    I'm having a litle trouble following you. What exactly is 'dynamic instantiation'?

    That said I really stuggle to see how caching tuples on the client (in a DataSet) is really going to help an O/R framework? Perhaps you can explain your thinking a little more?

    Cheers
    Alex
  • Anonymous
    June 02, 2009
    PingBack from http://patiochairsite.info/story.php?id=30128