OK, after having gone to nearly all of the articles & posts related to this very interesting topic: I find TDS an extreme powerful and also scalable programming model, absolutely. Therefore, the comments I have here are mostly from a comment I posted on Clemens' weblog ...
If I now want to share the data inside an TDS across boundaries - e.g. through a Web Services interface - I have several options. 1) Just pass back an instance of the TDS schema-based class back from your WebMethod. That is easy but always emits the Schema embedded. Is this bad? Well, there might be some cases ... 2) Just serialize the TDS to stream without any schema, just the data (serialized InfoSet) and return this one. Is this bad? Well, in some cases ... Additionally, the thing with interoperability is homehow a weak argument. The WSDL of a TDS-enabled Web Service always exposes the schema - so it is just not my fault that Axis or any other SOAP toolkit currently does not have a magic wizard DataSet class, but they are definitely able to understand me and work with me and my data.
Actually, when exposing TDSes through a Web Services interface I do not have to care about supplying the client with the TDS class - they get generated from the WSDL.
To come to a conclusion, I just want to say that there might not be *the* way for using and passing TDS. I like them because they ease the programming with databases and smoothly fit into the Web Services picture, IMHO.
Cheers,
Christian
How exactly does one go about using a TDS effectively in a different project, given that the DataColumns are marked as internal?
Say I have the folowing solution with three projects:
MySol
* DAL
* Entities
* Web
If I create all my TDS in the Entities project, how will I be able to reference the DataColumn properties from within the DAL or Web project? This appears to me to be a major drawback of using TDS - at least as VS.NET generates them.
Thanks,
Oskar
Hi Oskar. These are declared internal because what you really want to use from extrenal components aree the "public" properties that each row exposes whihc are essentially the columns that you are looking for. So why hide the columns themselves? I asked Mike Gunderloy and he came up with a reasonable explanation: To keep that columns access logic in one place. SOunds reasonable to me..
The probem I have with that is that if you want to bind a grid, say in the presentation layer to a TDS from a different project, you have no access to the column names, like you do from inside the assembly, which means you have to resort to using strings (which get checked at runtime) rather than the lengthy but compiler safe myDS.myDT.myCol.columnname syntax. I have run into some other issues related to this as well, but don't remember them at the moment....
Hi
I do not share your concern about the layers thing
If you give a closer look at the DNA diagram you will find
the Business Entity declaration.
Those Entities meant to be state-full and move through the tiers.
DataSet or Typed DataSet is one of the classic Business Entities.
You shouldn’t be worry about them if you dealing with smart client
and if you dealing with web client they always can be serialized to XML.
Any way I do not like the current implementation of Typed DataSet but
I do like their idea.
Hi what is differnet beetween Typed Dataset and Component Class. As typed Dataset is .xsd file but one senior person using Component class means .cs file and saying that this is Typed Dataset
Hey, Roy! You are THE man! Your simple observation is very very clever! Share Schemas, not Classes!! Good work!