Maxim,
Thanks. I came to the same conclusion about how to deal with changes
to your schema. Being able to reference XML fields or relational
columns using strongly-typed syntax seems like a great way to produce
more reliable and somewhat more readable code.
However, I have to (slightly) disagree with you on your statement
about Datasets not reflecting Database Tables. While I agree that
Datasets can be a powerful way to manage XML documents, what I have
found in practice is that Datasets were really designed by Microsoft
to handle XML that is derived from "relational" schemas. There are
numerous newsgroup threads that mention the problems of trying to
represent pure XML hierarchies that have certain nesting patterns such
as the same child type in two independent parent nodes. While this is
well-formed XML and is perfectly legal in XML Schema, the internal
parser that the Dataset class uses when you try to read this XSD into
the Dataset designer will fail to read the document and display an
error.
One engineer at Microsoft has admitted that this is a shortcoming (or
bug) in the way the Dataset was designed. He claims that they are
working on a more general-purpose Dataset and corresponding parser for
..Net Framework 2.0. But we'll have to wait and see. I have decided
to ONLY use the dataset when I need to bind some portion of my XML
data to either a GUI control such as a grid or combobox, or to one or
more relational database tables. I lose the ability to iterate
through rows and columns as easily as you can in a dataset but again,
if I'm doing something that really needs the XML in a dataset, I can
easily construct one by pointing the constructor's input parameter to
a subset of my XMLDocument as its input stream.
Meanwhile, I manage my pure XML data hierarchy with .Net's MSXML
classes, i.e., an XMLDocument class and a corresponding XMLSchema.
This tends to work out great for me. Meanwhile I still have full
control of my XML data including schema validation, input, output,
traversal, etc. I even populate my comboboxes with static data that I
get from my schema's simpleType/restriction/enumerations by reading
the schema into an XMLDocument and getting the list of simpleTypes.
This tends to work out great as well since all of my XML fields that
are qualified by validation lists can now be maintained in a single
XSD. I spent lots of time trying to figure out how these enumerations
were stored in a Dataset only to conclude (from some postings) that
the Dataset does not store these in a data structure. The only way to
validate against these restrictions is to use a ValidatingReader
against the original XSD file or XMLSchema object.
I'm finding that if I stick to the lower level XMLDocument and
XMLSchema objects and try to avoid the dataset, I'm able to handle
much more complex XML Documents and maintain a true hierarchical
structure to my data. You can always go back to a relational schema
using XSL to transform your data to whatever normalized form you need.
I'm guessing that people in the Java/Open Source world that work with
XML also tend to work at a lower level and don't get caught up with
fancy classes like the Dataset. However, there are some cool projects
like Hibernate and Castor out there that seem to be gaining popularity
for Object-Relational mapping with XML.
I agree that the Dataset is very powerful for manipulating
XMLDocuments that are derived from relational data and synchronizing
them with relational databases. I've played with the synchronization
through the DataAdapter and other various ADO.Net objects. I just
found that there are some serious limitations if you're working with a
more hierarchical (as opposed to relational) schema, which is exactly
what I'm working with on my project. This was not necessarily my
decision the government (DOJ, in my case) is promoting a schema
developed by a large consortium of agencies that simply would not work
with the 1.1 Dataset. My mobile client app manages multiple XML
Documents but I'm trying to completely avoid any kind of relational
database on the client side and use Web Services to get the data over
to the server.
Regards,
Norm
Maxim V. Karpov said:
Norman,
One miss understanding is that Datasets reflect Database layout of tables.
It is not true. I would start with designing your strongly typed dataset
with all fields included. Of course, while developing your app dataset
schema might change but we have the same issue with components method
signatures. What do we do? We add new method with new parameter list!
Maxim
[
www.ipattern.com do you]
Norman Katz said:
Hi Kevin,
As an aside, do you think that (architecturally), it can be
dangerous to use strongly typed datasets (at least early in a
project's lifecycle) since the schema naming conventions might change,
requiring a recompile of source code? I think the workaround is to
use annotations so that the original "logical" names of the elements
and attributes can be preserved. But that's still a workaround. I
understand that a strongly typed dataset is (in theory) more robust
from a code coverage and testing perspective, not to mention that it's
much easier to just code since you're using a priori object member
names.
My main concern is projects where the schema is a work-in-progress and
not totally solidified. Obviously, you want to spend lots of time in
the design phase so you can iron this out but it's not always feasible
for many projects.
Thanks for your (or others') opinion.
Norm
(e-mail address removed) (Kevin Yu [MSFT]) wrote in message
Hi Duane,
The simplest way to changed the name of the column is to change the
DataColumn.ColumnName property after filling the dataset.
ds.Table[0].Column["dptnum"] = "DepartmentNumber";
However, if you want to change the field name in a strong-typed Dataset
schema, you have to do the following 3 steps:
1. Modify the name of the column in the XSD. You can modify in either in
the design view or in the Xml, just like the following.
<xs:element name="DepartmentNumber" type="xs:string" minOccurs="0" />
2. If the DataAdapter was generated by wizard, please set the TableMappings
property of it. In the Table Mappings dialog box, set the mapping from
"dptnum" to "DepartmentNumber". Or you can use the following in code:
this.sqlDataAdapter1.TableMappings.AddRange(new
System.Data.Common.DataTableMapping[] {
new System.Data.Common.DataTableMapping("Table",
"Table11",
new System.Data.Common.DataColumnMapping[] {
new System.Data.Common.DataColumnMapping("dptnum",
"DepartmentNumber")})});
3. Fill the Dataset with the DataAdapter.
If anything is unclear, please feel free to reply to the post.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
