-
-
A large part of the .NET literature out there encourages you to use DataSet object to streamline data across the tiers of a distributed application. The DataSet is serializable; easy to use; provided with an effective object model; can be saved to/restored from XML; can contain a schema; is stateful (i.e., preserves a history of changes). And so forth.
There's nothing bad with this. But when you have distributed apps spanning over one or more machines (AppDomains would suffice) .NET Remoting comes up like it or not; implicitly or explicitly.
There's nothing bad with .NET Remoting too. However, when a DataSet object is remoted (or simply serialized to any stream) the .NET runtime serialization infrastructure gets into the game.
The DataSet object implements ISerializable meaning that it provides for its own serialization format and data layout. And it does that using plain XML. (Not even blanks and tabs are removed.) As a result, when you remote a DataSet you are actually passing data using a large chunk of data made after a verbose schema--the DiffGram. No matter you use a binary channel and formatter.
This point is well addressed in the following KB article. Which, in turn, references an MSDN Magazine article of mine for further details. Both articles illustrate some workaround, the best of which I believe is using a compact-formatter that just zips everything being transferred.
The good news is that this seems to be fixed in 2.0. A new property--RemotingFormat--on DataSet and DataTable objects makes possible for you to interact with the implementation of ISerializable and choose a binary format to optimize performance in .NET Remoting scenarios.
Note that the same bad thing occurs if you store DataSet objects to ASP.NET Session with the session state configured to work out-of-process.
-
-
I had an idea--making some of the new cool ASP.NET 2.0 features available to the 1.x audience too. I started implementing the idea through my MSDN Magazine articles, specifically in the Cutting Edge column. Thus far I wrote about personalization, image management, themes, cache dependency. Future articles may revolve around master pages and Web Parts.
Feedback is excellent. Great.
Next step is (would have been?) stuffing it all into a book adding a few more chapters with real-world and advanced scenarios (i.e., DHTML programming with ASP.NET, HTTP handlers, modules). Publishers are enthusiastic at first but then soon realize that the book could hardly be out before this September, subsequently facing a potentially short lifetime: six months?
Rumors, in fact, say that the first quarter of 2005 is considered a good time for the final 2.0 platform. Let's assume this is correct, and let's assume that MS makes the announcement the Friday night or in the week of an important conference.
Are you really ready to jump on the 2.0 bandwagon the next Monday? How long do you realistically think will it take to step up to the new platform? I believe that with the exception of those who adhere to early-adopter programs, "normal" people will wait at least 3 to 6 months to take the plunge. And this amount of people is a huge number.
Are you ready to drop 1.x applications to start working (and re-design them, actually) with the 2.0 platform? (Which is great, indeed.)
Do you think you need (and invest on) more advanced 1.x education and, why not, training? You can maintain and enhance current projects while positioning yourself well for the next big release of your apps.
Let me hear your thoughts!
-
-
I've spent five years of my youth studying Greek literature, history, and trying to grab the basics of the ancient, classic Greek language. (No chance to put hands on the modern, today's language. Greek developers, are they different?)
This post, though, is neither about the Greek alphabet, nor about my favorite airline.
The alpha in the title refers to the PDC build of Whidbey. As you may have guessed already, the beta in the title stands for the upcoming (summertime?) Beta 1 of the .NET FX 2.0. What's the delta for?
What's the real delta between the PDC build and the March04 Tech Preview? And, more importantly, what's gonna be the delta between the Tech Preview and the Beta 1?
Unfortunately, I'm not a member of the team and can only share an opinion based on my (limited) hands-on experience. I'm revising the chapters of my "Introducing ASP.NET 2.0" and although I can feel on my skin a fairly large delta between PDC and March04 Tech Preview (BTW--they're giving it away at DevConnections, here in the wonderfully warm Orlando), I can easily manage it.
Tuus far I'd say that Web Parts is the area with more changes--same big picture, several changes in the implementation. Master pages are nearly identical. Data source controls underwent some adjustments and renaming.
As for Web Parts, they made connecting two Web parts on a page really a snap. Thanks guys. Great job!
Thoughts? Measurements?
-
-
Although already highly ranked on Amazon, my book Introducing ASP.NET 2.0 from MS Press won't ship until next July. Where July is now a real deadline and not just a faint idea. I'm revising all the chapters right now.
PS: wouldn't it be nice to know a little more on the mysterious rules that generate the Amazon books ranking? A book that is far from shipping is ranked 83,000 and was 745,000 a week ago. Another book of mine Building Web Solutions with ASP.NET and ADO.NET available since February 2002 (2+ years) with pretty good sales (in this economy) is now ranked 41,000. It shouldn't be a cumulative set of criteria, isn't it?
-
-
Cleve pointed out:
I hear tell that in ADO.NET 2.0 the DataTable is now a first class citizen and supports serialization along with other DataSet features.
Correct. In 2.0, the DataTable implements the IXmlSerializable interface and provides the ReadXml/WriteXml methods that could only be emulated in 1.x.
Serializing a DataTable to and from Web service methods is possible now. Now? In 2.0, I mean. In addition, I've seen (but not tested yet) a RemotingFormat property that when set to a nonzero value serializes the DataTable object in a binary (that is, non XML) format. I'm not sure what "binary format" exactly means. Anakrino fails showing the code of the key method and I'm unable to have .NET Reflector even work on 2.0 assemblies. However, binary format is something that explicitly replaces the pure XML serialization format (remains the default) in use so far.
-
-
A few years ago I wrote a couple of NTFS article for MSDN. Many times I was going to update them to .NET but I never started the project. Anybody using NTFS specific features and wanting/needing it done the .NET way?
-
-
This is a recent question I've found in my inbox.
Both the DataSet and the DataTable implement ISerializable. Why can't a DataTable be returned from a Web
Service? I've come across some pretty vague explanations through Google and MSDN but I'm determined to understand the true technical reason why.
The reason relates to the class that ultimately handles the XML (de)serialization of any .NET type used with a Web service method. This class is XmlSerializer and serializes .NET types to XML. It is fairly different from a .NET formatter and designed to serve different purposes. XmlSerializer is NOT designed to persist the state of an object (like formatters do), but simply to move a snapshot of the constituent data of the object. For this reason, it only moves public members and doesn't even attempt to handle circular references.
XmlSerializer is a class specific of the .NET Web service implementation and could have been kept private as well. You should not use it as an XML formatter. (Looks like a similar class will make its debut with Whidbey.) Because it is not a formatter, XmlSerializer doesn't know anything about the ISerializable interface. In fact, XmlSerializer and formatters push two (radically) different models of serialization with different purposes and features.
So what's XmlSerializer all about? It just transforms any .NET type used as an I/O parameter of a Web service method into an XSD type and vice versa.
In terms of practical features, XmlSerializer doesn't handle circular references and skips over protected and private members. This is its default behavior. According to this, neither the DataSet nor the DataTable are good at
serializing through the XmlSerializer. So why is it supporting only the DataSet? It's a sort of exception.
The XmlSerializer works with simple classes (no circular refs) and with classes that implement IXmlSerializable
(an interface not fully documented in v1.x). The DataSet does implement it; the DataTable does not.
For details, look for the types.cs file in the SSCLI v2 (sscli\fx\src\xml\system\newxml\serialization path) to have an idea of what types are really supported. There are a few more "exceptions" than just the DataSet.