| 

.NET C# Java Javascript Exception

3
Hallo,

ich greife über einen WCF-Dataservice auf Daten einer Datenbank zu.
Ich schreibe meine LINQ-Anweisungen also gegen eine Klasse vom Typ "DataServiceContext".

Befindet sich meine Software im lokalen Intranet, möchte ich alterntaiv aber auch direkt auf die Datenbank zugreifen können und meine LINQ-Anweisungen direkt gegen die Entity-Framework-Objekte schreiben (Bei Enity Framework also gegen ObjectContext).

Leider haben ObjectContext und DatServiceContext keine gemeinsame, brauchbare Basisklasse.

Liebe Grüße

Silvia
Wie könnte ich das realisieren ohne meine LINQ-Anweisungen doppelt schreiben zu müssen?
News:
16.07.2012
Silvia1963 320 1 2 7
gfoidl 9,4k 3 5
2 Antworten
2
Hallo,

arbeite in der Anwendung gegen ein Repository das "vereinheitlicht" IQueryable<T> zur Verfügung stellt. Das Repository leitet dann intern die Abfrage (also die Expression<Func<T>>, usw.) entweder an den DataServiceContext od. den ObjectContext weiter.

Anders ausgedrückt: Schau dass du im Code nur eine Stelle hast, an der die Unterscheidung zwischen den Contexten stattfindet.

mfG Gü
16.07.2012
gfoidl 9,4k 3 5
Ich kann Dir leider nicht 100%ig folgen.
Wenn ich eine Anweisung schreibe wie:

var x = from m in context.Mitarbeiter
where m.name ='heinz'
select m;

wie kann ich da den Context zentral unterscheiden ?
Silvia1963 16.07.2012
1
Indem context das Repository darstellt und in diesem Repository wird dann entweder auf den DateServiceContext weitergeleitet od. der ObjectContext direkt verwendet.

Im Repository muss hier nur ein IQueryable<Mitarbeiter> als Eigenschaft vorhanden sein (bzw. allgemeiner IQueryable<T>), der Rest von der Query kann gleich bleiben.
gfoidl 17.07.2012
1
@gfoidl: Interessehalber: Wie handhabst Du das Testing Deiner Repositories? Setzt Du bei Offenlegen des IQueryable<T> wahrscheinlich verstärkt auf Integrationstests, oder? Bei einem FakeContext laufe ich ja Gefahr, gegen einen QueryProvider UnitTests auszuführen, der Dinge unterstützt, die mein realer Context nicht kann. Typischerweise ist der FakeContext ja LINQ2Objects.
Ich bin mittlerweile dazu übergegangen einen Layer zwischenzuschieben, der Repositories anbietet, die nur noch IEnumerable<T> und nicht mehr IQueryable<T> sind bzw. anbieten. Wie ist Deine Erfahrung? Diskussion in d. Lounge?
ffordermaier 17.07.2012
1
Bei "normalen" Repositories gebe ich meist IList<T> zurück und wenn ich es ganz testbar haben will, so injiziere ich dem Repo eine IUnitOfWork und dann lässt sich das super Mocken (mit Moq).
Die konkrete IUnitOfWork ist dann z.B. der DbContext vom EF 4.x

Im Beispiel von Silvia reicht das Repo die Anfragen nur weiter und beinhalten keine Logik dich ich unbedingt testen würde und hier kann das Repo auch durch einen Mock ersetzt werden.

Allerdings würde ich hier auch ein "normales" Repo verwenden und das Beispiel dementsprechend umändern zu:
var x = mitarbeiterRepo.GetByName("heinz");
gfoidl 17.07.2012
0
@gfoidl:
Ich habe das Repository-Pattern mal gegoogelt und arbeite mich in der Sache mal ein. Diese Möglichkeit ist bisher an mir vollkommen vorbeigegangen.
Danke für Deine Hilfe.
17.07.2012
Silvia1963 320 1 2 7

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