Dave Burke : Freelance .NET Web Developer specializing in Online Communities

The Summer of Disconnected Data Love

Deliberating over various disconnected data architectures, chosing one, and then pouring all of my attention into making it work has been an awakening experience to me.  Disconnected Data Love.  This distributed architecture is a beautiful thing and makes new areas of development in Rich Client and Mobile applications possible in my future.  The data model has many flavors and can use a wide range of technologies:  ADO.NET DataSets, Business Objects, CSLA, ORMapping, Extensible Database File System approaches like Base4.NET, etc.  But at the end of the day you have to build a product.  You have to pick an approach and go with it.  Picking it is the hard part. (Actually, building a disconnected data model regardless of what approach you chose is definitely tricky, but the decision is still hard!)

So in my first Smart Client application I am going with ADO.NET 2.0 DataSets.  I've investigated every technology I listed above, and I get the DataSet approach.  I can use it to build my app and deliver a great product to my company in the shortest amount of time. 

Part of my decision was based on available resources to study and anchor my approach.  There were not many working examples out there, granted, but the DevDays 2004 IssueVision Smart Client application from Vertigo Software had all of the functionality and with the source that was enough to get me on my way.  I re-watched all of the IssueVision Smart Client Track videos on the DVD, studied the source, ran the app over and over again.  And things started to make sense to me.  I liked it.

I'll be blogging on the details.  This post is to describe the decision of going with the ADO.NET DataSet model.  One point I'll make now is that ADO.NET 2.0 makes this model a much more productive approach than attempting to make it work with ADO.NET 1.0.

Comments (4) | Post RSS RSS comment feed

Posted on 6/25/2005 4:42:00 AM by Dave Burke
Categories: .NET
Tags:

Related posts

Comments (4) -

6/26/2005 3:48:19 PM Permalink

How big are your datasets, Dave? I'm working on a project for which management has expressed a strong interest in 'disconnected data' scenarios, but we're talking about tables with up to 5000 rows, all of which would need to come down to the client.

Are your datasets that big?

mabster |

6/26/2005 3:56:58 PM Permalink

Mabster, (Great handle, btw).  5000 rows?  No, nothing close, not for primary data objects, anyway.  I'm anticipated a few megabytes for the client dataset, most likely.  I'll be taking every step to keep that as small as possible, of course, but it will be a couple megs at least.  Remember, you're not sending down the entire dataset, just CHANGES, both from the client and the server.  Overall packet traffic would be relatively small.

daveburke |

6/26/2005 4:27:50 PM Permalink

Yeah, the fact that you're only passing deltas around helps a lot.

I'll certainly be interested to hear how you structure the classes involved in data-access. We've gone the 'web services to cheat remoting' way - returning datasets with a GetXXX method, and pushing changes back to the server with an 'UpdateXXX' method.

At the client end I've created some 'agent' classes which talk to the web service, and don't make two hits to the server's 'get' method with the same parameters if they're within five minutes of each other (rudimentary caching). But this way of doing things is no good if we want disconnected data.

I took a (*very*) brief look at the Enterprise Library from MS, but that's pretty deep for our two-person, relatively-new-to-dot-net-but-well-versed-in-Delphi team. Smile

mabster |

6/26/2005 4:33:57 PM Permalink

I hear ya, Mabster Man!  This disconnected data stuff is fascinating, but makes you think too much in putting the pieces together. Smile  Most examples I found out there were way more complicated than I thought they needed to be, which is why I went with the IssueVision approach of a Subject class passing off to a WebServicesLayer class that hits the Web Service.  I'll be blogging on the synchronization approach, which can be complicated, though I think my model is pretty straightforward.  Good luck with your decision-making!

daveburke |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke