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!