Web Service学习经历
比较好的文章：
1。http://www.15seconds.com/Issue/010430.htm
2。http://www.15seconds.com/issue/010530.htm
3。http://aspnet.4guysfromrolla.com/articles/100803-1.aspx
深感有用的片断摘录：
Some Closing Notes on XML Serialization
There are a few subtle details with XML serialization that are important to know about when working with Web services that accept complex data types. Realize that XML serialization:
- XML serialization can only be applied to classes that contain a public default (parameterless) constructor. If you create a class in the Web service that does not have a public default constructor, the Web service will still compile, but when attempting to generate the proxy class on the client's end you'll receive an error message.
- Read-only class properties are not serialized. That is, if a property in the class has only a
getaccessor, and not asetaccessor as well, the property will not be serialized. - Only public properties and fields are serialized. Private properties are not serialized.
- To serialize a strongly-typed collection of objects, have the class derived from
System.Collections.CollectionBaseadding anAdd()method and an indexer. (See this article for more information.) Alternatively you can send an array of the specified type.
XML Serialization Frequently Asked Questions
The following is a list of questions commonly asked on the microsoft.public.dotnet.xml newsgroup about XML serialization in the .NET Framework.
Q: Why can't I serialize .NET Framework classes like exceptions and fonts?
A: The XmlSerializer is primarily designed with two goals in mind: XML data binding to XSD compliant data structures and operation without any special code access privileges. These two goals work against the XmlSerializer as a general-purpose object persistence solution for some kinds of objects.
General purpose serialization may require accessing private fields, by-passing the framework's standard object construction process, and so on, which in turn requires special privileges. The SoapFormatter from the System.Runtime.Serialization.Formatters.Soap namespace provides an alternative that is not subject to these restrictions, but requires full trust to operate. It also produces an XML format, a generation of which is customizable using the attributes in the System.Runtime.Remoting.Metadata namespace.
The BinaryFormatter from the System.Runtime.Serialization.Formatters.Binary namespace can also be used as a mechanism to provide simple object persistence and transport for situations where XML serialization does not meet your needs.
Q: How can I serialize classes that were not designed for XML serialization if I do not want to use the SoapFormatter?
A: You can design special wrapper classes that expose or hide fields and properties from the XmlSerializer.
Q: How do I serialize collections of objects?
A: The XmlSerializer throws an exception when the collection contains types that were not declared to the constructor of the XmlSerializer. You can:
- Declare the types to the serializer by passing in a Type[] with the types to expect within the collection.
OR
- Implement a strongly-typed collection derived from System.Collections.CollectionBase with an indexer matching the Add() method.
Q: Why aren't all properties of collection classes serialized?
A: The XmlSerializer only serializes the elements in the collection when it detects either the IEnumerable or the ICollection interface. This behavior is by design. The only work around is to re-factor the custom collection into two classes, one of which exposes the properties including one of the pure collection types.
Q: Why can't I serialize hashtables?
A: The XmlSerializer cannot process classes implementing the IDictionary interface. This was partly due to schedule constraints and partly due to the fact that a hashtable does not have a counterpart in the XSD type system. The only solution is to implement a custom hashtable that does not implement the IDictionary interface.
Q: Why do exceptions thrown by the XmlSerializer not contain any details about the error?
A: They do contain all the information, but it's stored in the InnerException property of the exception thrown, which is usually an InvalidOperationException. In general, one should always call ToString() on caught exceptions to get the full details of the exception.
Q: What aspects of W3C XML Schema are not supported by the XmlSerializer during conversion of schemas to classes?
A: The XmlSerializer does not support the following:
- Any of the simple type restriction facets besides enumeration.
- Namespace based wildcards.
- Identity constraints.
- Substitution groups.
- Blocked elements or types.
Q: Why doesn't XSD.exe support the schemaLocation attribute on imports and includes?
A: The W3C XML Schema recommendation describes this attribute as a hint, which can be ignored by processors that can use alternate means to locate schemas. XSD.exe only uses schemas that are specified through the command line to convert schema A.xsd, which imports schema B.xsd.
xsd.exe /c A.xsd B.xsd
Also, the wsdl.exe application, considered a sister application to xsd.exe, can be downloaded from the Web. If you do this and use the wsdl.exe, you would follow schemaLocation hints in imports and includes.
Q: What are the differences between the XSD to runtime type mapping used by XML serialization and those used by ADO.NET or XSD validation?
A: The mappings from W3C XML Schema types to runtime types used by the dataset and schema validation are described in the Data Type Support between XML Schema (XSD) Types and .NET Framework Types topic.
This mapping is different from those used when XML serialization attributes are specified on the fields and properties of a class. Each of the XML serialization attributes has its mapping from objects to W3C XML Schema types defined in the description for the DataType property for that class. This includes the descriptions of the SoapAttributeAttribute.DataType property , SoapElementAttribute.DataType property, XmlArrayItemAttribute.DataType property, XmlAttributeAttribute.DataType property, XmlElementAttribute.DataType property, and XmlRootAttribute.DataType property.
A major difference is that the Gregorian dates, such as xs:gMonth and xs:gYear, are mapped to strings by XML serialization, whereas validation maps them to DateTime objects. Another difference is that the DTD-based list types, such as IDREFS and NMTOKENS, are mapped to strings by XML serialization while validation maps them to arrays of strings. The xs:duration type is also mapped differently in XML serialization compared to schema validation. XML serialization maps them to strings, while validation maps them to TimeSpan objects. The xs:integer type is specified as a number with no upper or lower bound on its size. For this reason, neither XML serialization nor validation map it to the System.Int32 type. Instead, XML serialization maps the xs:integer to a string while validation maps it to the Decimal type that is much larger than any of the integer types in the .NET Framework.