(Nah, I don't really believe that, but it's a good title, no? DataSets have there place, just not as publically visible Business Objects or from publically accessible WebServices.)
Barry Gervin commented on my "quick bash at DataSets" and that I didn't explain my reasonining. In his post, Barry commented on Harry Pierson's statement that one shouldn't use DataSets in a Web Service because they aren't compatible with non .NET Platforms. Barry says, "This isn't true. A DataSet is just XML." Well, of course it's XML, but if I say, hey take this sentence, it's in the ASCII character set (who care's if it isn't English) Le "DataSet" n'est pas votre ami si vous faites des Services de Web. Well, Barry can understand that, but I no hablo French. ;)
DataSets are bowls, not fruit. Do you really want to return bowls?
A DataSet is an object, right? But it's not a Domain Object, it's not an "Apple" or "Orange" - it's an object of type "DataSet." A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It's an object that knows a LOT about the Database. But I don't want to return bowls. I want to return Domain Objects, like "Apples."
"Use Strongly Typed DataSets," you say. "They are the same as Objects, and look how intellisquish works now!"
No, they still aren't Domain Objects, a Strongly Typed DataSet is just a bowl with a picture of an Apple on it. "Look there's an Apple INSIDE - we've broken it down into columns!" DataSets are a shoddy replacement for a good Domain Model (and that includes Strongly Typed DataSets).
Barry has a very good argument for the use of DataSets on his site, and I won't go through his list agreeing and disagreeing with various points. I will say this, however, it seems that his arguments support the use of DataSets in a Data Access Layer - not in a Business Object Layer. THAT I would support. Additionally I understand the usefulness of DataSets in a classic (intranet) Client-Server WinForms app with lots of DataBinding.
Returning DataSets from a publically accessible Web Service is a BAD IDEA©.
Now, why shouldn't we return DataSets from WebServices? DataSets and their serialized XML format includes a pile of information that has little to do with the Domain Model itself. DataSets may be DiffGrams, they may or may not include schema, and they represent "Sets of Data." They are an object of one type, DataSet. Whether there is a Java version of a DataSet object available doesn't matter. They are late-bound by nature, as even a Strongly Typed DataSet encapsulates conversion of types back and forth from SqlDataTypes to typical CLR types and calls to Rows["Apple"]. DataSets are the Class equivalent of an Variant - an Object that can be any kind of Object - only serializable as XML. Returning an object of type DataSet or Typed DataSet via publically accessible Web Service would succeed only in confusing a Java person, stymying any chance of interop, and giving them more ammo to use against .NET.
To be clear, I WOULD architect a system that included DataSets if I felt that they provided an exceptional value. I'm just promoting that folks BE AWARE of the ramifications of their decisions.
Tagential aside: There's some yummy best practices up on TheServerSide.NET. Here's my favorites:
- Using a DataReader vs. a DataSet: The DataReader was of course faster. It was faster by 16% in this particular case.
- SQLDataReader vs. OleDBDataReader: Going with native drivers is always better. The SQLDataReader was 115% faster than going through OLE.
- DataReader Column Reference - By Name, Ordinal, or GetString(): The order of speed? dr[0] was the fastest, followed by dr["ProductName"], followed by dr.GetString(0) as it has to do the conversion.
- Inline (DataReader) vs. Controls (DataGrid): The inline script was 233% faster than a DataGrid component.
Hosting By
