[DataContract] Klasse SerialisierungsProblem?



  • in meiner WCF anwendung hab ich ein problem mit einer
    DataContract Klasse:

    [DataContract]
        class MSAccessDatabase
        {
    
            ADODB.Connection dbConn;
            string strDBName;
    
            [DataMember]
            public ADODB.Connection Connection
            {
                get { return dbConn; }
                set { dbConn = value; }
            }
    
            [DataMember]
            public string DatabaseName
            {
                get { return strDBName; }
                set { strDBName = value; }
            }
    
        }
    

    Der client meldet http server respones problem, liegt an dem ADODB.Connection, was wohl zecks serialisierung rumspakt?

    Später will ich auch ein ADODB.Recordset zum client schicken.. wird aber wohl ehr schwer, weil diese ja die Abfragen daten in verbindung mit einer datenbank zurückgibt, und die datensätze ja nich speicehrt... wie könnte ich sowas lösen?

    Eine alternative wäre, wenn ich Datanbank verbindungen bzw. recordset auf dem server anlage, und nur die einzelen datensätze hin und her schicke??? 💡



  • Um Himmels willen... Du kannst doch nicht einfach irgendwelche Datenbank-Verbindungs-Objekte in der Welt hin und herschicken, ganz egal welche Technologie du benutzt...
    Aber um auf WCF-Ebene zu bleiben: Das dürfte daran scheitern, dass ein Connection-Objekt nicht serialisierbar ist (wie bzw. warum auch...). Alle DataMember eines DataContract müssen auch serialisierbar sei, sonst funktioniert das nicht. Selbst wenn du es irgendwie serialisieren könntest, würde es dann aber noch ganz andere Probleme geben...

    Was du da machst ist sowieso totaler Quatsch. DataContracts verwendet man nur für die reinen Daten die ausgetauscht werden müssen. Für die Funktionalität bzw. Operationen die dein Service anbietet gibts dann eben den ServiceContract.



  • ja der unterschied zwischen serviceCotnract udn Datecontract hab ich verstanden, hab mich hier bischen verhudelt.

    Ich werden nun die ganzen datenbank verbinduen und deren recordset, für jeden clietn auf dem server belassen, und nur die feld daten der einzelen recordset mit datacotnract übertragen;M)

    EDIT: Auf der Remoting basis, könnte ich aber Datenban verbidungs objecte via MBR auf dem client anlegen oder???



  • BorisDieKlinge schrieb:

    ja der unterschied zwischen serviceCotnract udn Datecontract hab ich verstanden, hab mich hier bischen verhudelt.

    Mir scheint es zudem das du keine große Erfahrung mit Mehrschichtenarchitektur hast, kannst mir aber gerne wiedersprechen.

    Ich würde auch unter .Net 3.0/3.5 die DAL separieren, und Datenobjekte von der Logik wie diese zu lesen/schreiben sind trennen (Dann hast du in der Regel auch die Anforderungen von WCF besser erfüllt, zumal man dann die Datenbank bei Bedarf noch wesentlich leichter austauschen kann).

    cu André



  • ne habe kaum erfahrung, ich versuche mich erst seit 2 tagen mit WCF;)
    Wollte einen kleine MSAccess Database Remote server basteln;)

    Ich suche schon verzweifelt nach einem einfache beispiel LINQ SQL WCF Applikation. Kennt jemand ein gutes?



  • Wollte einen kleine MSAccess Database Remote server basteln;)

    Nimm doch einen "richtigen" SQL Server, dann musst du nicht basteln.
    Z.B. wäre die Express Version des MS SQL Server 2005 geeignet.

    Warum sich das Leben noch schwerer machen, wenn sowiso schon schwer ist...



  • BorisDieKlinge schrieb:

    ne habe kaum erfahrung, ich versuche mich erst seit 2 tagen mit WCF;)
    Wollte einen kleine MSAccess Database Remote server basteln;)

    Mit dem Beispiel kann ich dir leider nicht dienen, aber eine Anregung mitgeben:

    Nehmen wir mal an du hast unter anderem Adressen in deiner Datenbank. Dann könnte man, u.a. um WCF-Konform zu bleiben, diese erstmal als Datenklasse ansehen (Sprich sie besteht nur aus den teilen die für die Datenhaltung relevant sind (z.b. Id, Name, Vorname, Straße, PLZ, Ort). Diese wird dann dein [DataContract] für Adressen.

    Das Lesen/Schreiben etc. bekommt eine andere Klasse zugeordnet, die dann Funktionen bereitstellt um eine oder mehrere Adressen auszulesen oder wegzuschreiben (GetAddressById...). Wenn ich das auf WCF übertrage könnte dies wohl ein Servicecontract werden. Wobei ich das lieber in ein Interface verschieben würde (Vorteil: Bei einem austausch der der Datenbank muss nur diese Klasse angepasst werden). Diese Klasse hat auch keine DB-Spezifika die nach Außen gegeben werden, und jede Zugriffsfunktion stellt sicher das mit dem Ende der Funktion die DB-Connection geschlossen wird.

    Sorry, ich habe zwar theoretisches WCF-Wissen, beschäftige mich mit C# aber nur privat und dann eher bezogen auf WPF. Ich baue zwar grade eine komplexere Anwendung, aber werde diese erst in einen späteren Schritt auf WCF anpassen (Ich hoffe das ich das dank sauberer Schichtentrennung dann mit relativ geringen Aufwand nachziehen kann).

    Grundsätzlich wird in jeder meiner WCF-Quellen ohnehin empfohlen niemals mit Objekten direkt sondern mit Interfaces zu arbeiten (Meine Quellen sind vor allem Bücher aus den Verlagen Apress und Wrox).

    cu André



  • naja Datencontract'e muss man ja als objekt analgen:)

    es gibt also definitv keine möglichkeit LINQ mit MSAcess DB zu verbinden?

    Habe ein LINQ SQL beispiel gefunden, aber das arbeit nur mit nem SQL Server.. bisher sind die ganzen daten in Access Datebanken angelegt.. sonst würd ich es mit nem SQL SErver versuchen



  • es gibt also definitv keine möglichkeit LINQ mit MSAcess DB zu verbinden?

    http://forums.asp.net/t/1191530.aspx

    Ich würde, wenn Du schon eine lokale, datei basierte DB willst (wie access eine ist), dir empfehlen MS SQL Server Compact zu nutzen. Ansonsten wie gesagt MS SQL Server Express.



  • schade:(


Anmelden zum Antworten