Binary Serialization of Datasets - Problems Solved in .NET 2
If you've ever used ADO.net Datasets to pass large amounts of data around via Remoting, you've probably hit the performance problem described in this article. The problem arises because the binary serialization of datasets is hugely inefficient, and results in bloated data payloads being passed between your servers.
Most people use datasets because it's easy to get up and running with them; I don't like them, precisely because they're bloated and inefficient (in .net 1.x at least), and because they're not truly object oriented: custom collections (inherit from CollectionBase or ReadOnlyCollectionBase) of objects are easy to implement, efficiently serialized (and so faster over the wire), and are much more elegant.
That said, MS have improved the performance of the binary serializer in .net 2.0, and it looks like there's quite a performance improvement over previous versions.
posted by Adam Young @ 10:45 am
3 comments
3 Comments:
Adam,
2 points.
How do you easily implement type safe collections that don't cast to the object type?
How do you easily implement relationships between collections in the same way as a DataRelation?
Enjoy!!
Hello Noel, good to see you're still banging the VB / non-OO drum.
IMO Datasets are there if you don't understand / can't be bothered / don't have time to implement a proper OO solution to moving your data around and using it in your app. Anything you can do with a dataset, you can do with a custom collection, including databinding. At the end of the day, the Dataset is there to provide a RAD solution. However, we both know that RAD does not equal quality.
As for your point about casting (I assume you're alluding to performance), well that may be true in the current 1.x release of .net, but things will change when 2.0 comes out. Also, as I'm sure you're aware, both regular and strongly-typed Datasets convert back and forth between the database type systems, and the .NET CTS, which equals overhead - more so than using an object model. Couple this with the fact that, returned from a web service, you wind up with a sh*t-load of XML on the wire that you don't want and don't need (the diffgram, the schema, etc), and which you can't control. Note also that Datasets are not XSD compliant, so you won't be able to interop with other platforms. Returned from a Remoting endpoint, you wind up with the bloating problem I described in the post that prompted you to make comment.
Implementing an object model is how you build relationships between collections... unlike having a bunch of unrelated Datasets floating around in your app, you build a model of the relationships. Collections don't exist in isolation. A Supplier will contain a collection of Contacts, each Contact contains a collection of Addresses, etc. The model is built on analysis of the system, and you will do this using a UML class diagram (yep, that's what they're for).
The Dataset is an implementation of the "Table Data Gateway", and "Row Data Gateway" patterns (Datasets are roughly equivalent to a Java WebRowSet). These patterns work best when you have simple CRUD / transaction based processing (i.e. a simple, small-scale business domain to model, where each entity in your app exists in isolation and will have at most 4 methods to create, read, update and delete). Also, the gateway patterns are there to shield the domain logic from the database design - useful if the database is constantly changing, as it inevitable will early in a development.
So when would I recommend using a Dataset. To get you up and running quickly; a simple demo in a presentation; when the business rules haven't been worked out or the domain model is changing.
It's all about using the right tools for the job. I used to be very anti datasets, and always wrote my own custom objects. That was until I had a project where I needed diffgram support. Saved a lot of code using datasets there!
Post a Comment
<< Home