a) Einen Datensatz zum Bearbeiten holen.
Lesen: Dazu wird VFP angewiesen den aktuellen Datensatz einer View in eine DBF im Temp-Ordner zu kopieren.Danach liest .NET über den VFPOleDB-Treiber und den OleDBReader die DBF in eine DataTable. Das Businessobjekt VFPRecordBase belädt aus dieser seine Properties.
Schreiben: Das BO genieriert aufgrund der geänderten Properties einen SQL-UPDATE-Befehl und schickt diesen an VFP. Analog wird beim Löschen und Anlegen verfahren.
b) Einen Cursor zur Anzeige holen
Dazu formuliert das BO auf Basis seiner Properies ein SQL SELECT, das an VFP geschicht wird.Danach liest .NET über den VFPOleDB-Treiber und den OleDBReader die DBF in eine DataTable. Das Businessobjekt vom Typ List<VFPRecordBase> legt eine Liste an und befüllt diese mit VFPRecordBase-Objekten.
Vorteil: keine weitere Installation/Administration von Komponenten (Webserver)
Nachteil: wg. COM-Kopplung ist die .NET-Seite auf 32 Bit festgelegt.
Das ganze Konstrukt ist weiterhin für den Desktop gedacht.
Es sollte jedoch möglich sein, auf .Net-Seite einen Webservice anzubieten. Damit könnte das Konstrukt auf einem Server laufen (in 32 Bit), der Client (Konsument des Webservice über WCF) ist aber unabhängig: 64 Bit, Silverlight, im Browser oder außerhalb, alles geht.
Dem Cloud-Computing steht damit nichts mehr im Wege. Aber das ist eine ganz andere Baustelle.
Obwohl: Microsoft pusht das ganze jetzt über seine Azure-Plattform...
Keine Kommentare:
Kommentar veröffentlichen