Indigo + GridView + Dataset interoperability
Tnks.
Tnks.
Dataset will definititely not be interoperable, and as a best practice, i would not recommend to use to pass data between layers if you need interoperability. Please note that datasets are good solutions when you control both sides of the system and you will never need to expose your service layer to other systems. Although, also pay attention to which kind of channels you're going to use, since serialized datasets are really expensive in bandwith, so the decision may be hard.
What you need are data contracts. You need to Type your data and normalize the contract for the results you're returning. Probably you will need a kind of Messaging Mapper pattern where you map your internal datasets to data contracts in the service layer.
asp.net 2.0 supports binding to custom structures, as i understand, so it shouldn't be a problem to implement this.
If you're new to data contracts, check this out. Maybe it helps.
Ok thank you for your answer.
I have already seen some things about data contracts, but there's still some key points that i do not understand. For example is it possible to return a strongly typed collection like the new Collection<T> and still retain the interoperability with other platforms (what kind of wsdl is generated in this case ?), or returning a list from a trully soa webservice means that we should use only arrays with objects defined by datacontracts ? What is the best way ?.
What i'm targeting here is a trully SOA indigo service that can be consumed by any client that complies with the WS* specs. The main purpuse is to make binding to data objects the easiest possible for .net clients, but still retain the interoperability requisites for other clients.
References :
http://blogs.msdn.com/kcwalina/archive/2005/09/23/Collections.aspx
Tnks in advance
yep. That's a good question. It has to do with the way XmlFormatter serializes data contracts.
Imagine you have this:
[DataMember()]
public Collection<User> Team;
[DataMember()]
public IList<User> Friends;
[DataMember()]
public List<User> Family;
That would create this schema for the wire:
<xs:complexType name="User">
<xs:sequence>
<xs:element minOccurs="0" name="Team" nillable="true" type="tns:ArrayOfUser" />
<xs:element minOccurs="0" name="Friends" nillable="true" type="xs:anyType" />
<xs:element minOccurs="0" name="Family" nillable="true" type="tns:ArrayOfUser" />
</xs:sequence>
</xs:complexType>
<xs:element name="User" nillable="true" type="tns:User" />
<xs:complexType name="ArrayOfUser">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="User" nillable="true" type="tns:User" />
</xs:sequence>
</xs:complexType>
So basically, in answer to your question: it depends of the way you specify it. If you use an IList or IDictionary, for example, it will generate an XmlAny.
Please remind.. any will be "interoperable".. but.. if won't be typed. so your consumer may not know what to send there, right ?
The greatness of this.. is that even the client is WCF, it doesn't know IList, since it will use the same public schema than other systems. So, in a case of an IList, WCF will generate an "object" type on the proxy.
I think there's a better way than what i do to check this out, but i can't find how. I use "SvcUtil AssemblyName" and then i check output.xsd . You find a better way, please let me know.
hope i helped..
regards
Any type that implements IEnumerable, IEnumerable<T>, ICollection, Collection<T>, ... has a collection contract.
All of these types are polymorphic in the XSD, we emit them as ArraryOfXXX.
This pattern is completely interoperable.
thanks