Implementera datatjänster med LINQ

Project LINQ har fått enormt mycket uppmärksamhet efter PDC05. Med LINQ tar Microsoft ett steg närmare object-relational mapping och lämnar DataSet och tabeller som projektion på en relationsdatabas. Med LINQ kan man på lika smidigt sätt implementera en data service som du kunnat med DataSet, fast nu även med typinformation i kontraktet.

Har du skickat ett DataSet från en web service någon gång så kanske du lagt märke till att bara klienter som kan skapa just ett DataSet kan anropa din tjänst. Så här ser nämligen WSDL kontraktet ut:

<s:element name="GetMeetingRequestDSResponse">
  <s:complexType>
    <s:sequence>
      <s:element 
minOccurs="0" maxOccurs="1" name="GetMeetingRequestDSResult">
        <s:complexType>
          <s:sequence>
            <s:element ref="s:schema" />
            <s:any />
          </s:sequence>
        </s:complexType>
      </s:element>
    </s:sequence>
  </s:complexType>
</s:element>

 
[WebMethod]
public DataSet GetMeetingRequestDS()
{
 return new DataSet();
}

Typinformationen kommer i runtime och kan enbart konsumeras av ett DataSet. Det gäller även typade DataSet, vilket självfallet inte borde vara fallet eftersom typinformationen är känd i o m att det finns ett schema definierat.

DataSet är det idag enklaste och mest effektiva sättet att med Visual Studio och .NET Framework (Out Of the Box) skapa en datastruktur med innehåll från en relationsdatabas. Tyvärr så är det inte lämpligt att använda i en tjänstebaserad arkitektur, eftersom man inte bygger tjänster för att de ska konsumeras av en viss typ av plattform. Man vill ju ha ett teknikoberoende vilket man bara får om typerna som ska skickas över nätet kan definieras enligt WSDL.

En objektstruktur i .NET kan serialieras till en datastruktur som är kompatibel med WSDL. LINQ ger samma stöd som du får från DataSet för att populera en datastruktur fast för en godtycklig objektstruktur.