Przeprowadzam migrację aplikacji win32 Delphi VCL napisanej w Delphi 2010 do architektury wielowarstwowej.
Aplikacja w szerokim zakresie wykorzystuje ExpressGrids (TcxGrid) przez devexpress do wiązania danych.

Zaprojektowałem warstwę danych na podstawie struktury Entity, używając obiektów dbContext i Data Transfer.Udostępniam operacje CRUD za pośrednictwem WCF przy użyciu szablonów T4 opartych na modelu danych encji.

To wszystko działa dobrze, klient Delphi z powodzeniem komunikuje się z usługą WCF, aby wymieniać obiekty przesyłania danych.

Problemem jest,jak mogę utrzymać funkcjonalność wiązania danych? Skłaniam się ku napisaniu metody usługi, która zwraca ogólną tabelę danych lub zestaw danych. Czy mogę przekonwertować wyniki instrukcji linq na zestawy danych, tabele lub widoki? Nie jestem pewien, czy mogę powiązać Expressgrids z tablicami obiektów (WCF zwraca zbiory jednostek, ale Delphi widzi tablice). Czy ktoś miał doświadczenie w tego typu interoperacyjności?

EDYTOWAĆ

Mam usługę danych zwracającą DataSets, ale zgadnij co? Zestaw danych xml z .net nie jest zgodny z Delphi (co najmniej w 2010 r.). Udało mi się go uruchomić, używającPrzykład Gekko (zmodyfikowany) , ale nie będzie to praktyczne ze względu na złożoność zapytań, które musielibyśmy uruchomić od klienta. Nasze opcje są teraz, aby pozostawić siatki tak, jak są aż do ukończenia BLL i rozpocząć nowy projekt, aby ponownie napisać klienta w C # (jako aplikacja internetowa lub Windows) lub napisać ogólną wtyczkę Grid używając RemObjects Hydra, osadzać w formularzach z siatkami - próbując to teraz zrozumieć.

Aktualizacja Zrezygnowałem z implementacji Gekko DataSet na rzecz pisania własnego, studiując format xml wymagany przez TClientDataSet w Delphi. Po stronie serwera zaimplementowałem usługę, która zwraca zgodny ze standardem xml TClientDataSet w postaci tablicy bajtów. Na kliencie Wczytaj to do TStringStream, a następnie załaduj strumień do komponentu TclientDataSet. Używam tego do małych kolekcji, aby zapewnić wyszukiwanie i powiązanie danych, podczas gdy rozwijamy rozwiązanie Hydra.

Xml jest z grubsza zgodny z tym formatem:

<code>"2.0">
  <METADATA>
    <FIELDS>
      <FIELD attrname="ID" fieldtype="i4"/>
      <FIELD attrname="Status" fieldtype="string" WIDTH="10"/>
      <FIELD attrname="Created" fieldtype="date"/>


<ROWDATA>
    <ROW RowState="4" ID="1" Status="Code1" Created="20130707" Made="20130707T21:37:55341" Stopped="00:00:00000" Volume="1174" IsReady="TRUE"/>
    <ROW RowState="4" ID="2" Status="Code2" Created="20130707" Made="20130707T21:37:55341" Stopped="00:00:00000" Volume="2149" IsReady="FALSE"/>
</code>

To jest jednym z niewielu źródeł informacji w formacie xml.

Wiem, że pytanie jest stare, ale doceniłbym wszelkie spostrzeżenia na temat interoperacyjności i migracji starszych kodów.

Dzięki