| 

.NET C# Java Javascript Exception

1
Hallo

Bei mir kommen langsam Zweifel hoch. Wir haben hier eine Anwendung, eher fast ein Framework, das mit einem eigenen geschriebenen OR Mapper arbeitet. Ich will nun testen ob ich Module (PlugIns) mit EF und nHibernate nutzen kann. nHibernate macht keine Probleme. Das Modul läuft.
Aber das mit EF bringt mich langsam an den Rand der Verzweiflung.

Da das ganze über WCF transportiert wird nutze ich Self-Tracking Entities. Diese sind mit dem Attribut [DataContract(IsReference = true)] gekennzeichnet. Collections offenbar mit [CollectionDataContract]. Wenn ich nun die Anwendung starte kommt die Meldung das die Basisobjekte auch mit [DataContract(IsReference = true)] gekennzeichnet sein müssen. Das ist schon mal ganz blöd. Aber na ja, man macht es halt.

Jetzt habe ich mal die 100 Klassen angepasst und die Anwendung startet. Die Meldung kommt nicht mehr, dafür funktioniert alles andere nicht mehr.

Versuche ich da etwas zu realisieren was nicht angedacht ist? Einerseitz muss ich das Attribut [DataContract(IsReference = true)] einsetzten von wegen Navigations Eigenschaften die Backreferenzen erzeugen. Anderseitz funktioniert dann alles andere nicht mehr.

Soll ich es sein lassen?
News:
08.03.2012
GENiALi 2,5k 1 2 8
1 Antwort
1
ich habe zwar noch keine konkreten Projekte mit dem EF durchgeführt (meine Präferenz ist NHibernate), aber nach allem was ich über Self Tracking Entities gelesen habe, erscheinen mir diese nicht geeignet für Serviceorientierte Architekturen. Ich konzipiere Service Layer normalerweise zustandslos unter zuhilfenahme einfacher POCO's. Insbesondere das Lesen und Aktualisieren von Daten sind bei mir in der Regel getrennte Zuständigkeiten. Beim Lesen sorge ich dafür, dass mein Objektbaum komplett gefüllt ist. Beim Schreiben persistiere ich wieder den gesamten Objektbaum. Ich nehme es hierbei auch in Kauf, dass Daten weggeschrieben werden, die gar nicht geändert wurden. Der Performance-Verlust hierbei ist meines Erachtens vernachlässigbar, es sei denn es wird eine Massendatenverarbeitung durchgeführt (aber dafür sind ORM's eh nicht die richtige Wahl). Sobald ein WCF-Service auch von einer nicht-.NET-Anwendung konsumiert werden soll, verbietet sich der EInsatz von Self Tracking Entities sowieso.
11.03.2012
luedi 2,1k 1 9
Ich habe mir jetzt auch eigene POCO's gebaut. Ich Wrappe sie einfach immer wieder ins entsprechende EF Objekt. Aber die Lösung gefällt mir nicht. Na ja. Erfahrung habe ich nun gesammelt. Ein Greenfield Projekt würde ich wohl mit EF und WCF machen. Aber ein bestehendes erweitern, dass würde ich nicht mehr machen.
GENiALi 11.03.2012
@ GENIALi: POCOs werden hier doch als DTO eingesetzt, wodurch die Layer von einander getrennt und die Wartbarkeit erhöht wird. Macht es - ausser in Quick und Dirty Lösungen - Sinn, die Entitäten als Cross Cuttings Concerns bis ins Frontend durchzuschleifen?
judgy 13.03.2012
@judgy: Wenn man MS Best irgend was anschaut, dann werden z.B. die POCO's und die STE durchgereicht. Genau das will ich ja eigentlich. STE und POCO's sind ziemlich abgepseckte Objekte. Wenn man ein Greenfield Projekt hat kann man ohne Probleme mit POCO's und STE's arbeiten und zudem den WCF nutzen. Aber sobald man Basisobjekte eines bestehenden Projektes angewiesen ist, dann ist fertig damit.
GENiALi 13.03.2012

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH