Hallo,

ich würde gerne Entity Framework in einer Universal App nutzen.
Ich habe schon öfter damit gearbeitet aber immer wenn ich versuche mit Nuget die Verweise einzubinden kommt da folgende Fehlermeldung:

Das Paket "EntityFramework.Commands 7.0.0-beta4" konnte nicht installiert werden. Sie versuchen, dieses Paket in ein Projekt zu installieren, das sich auf ".NETCore,Version=v4.5.1" bezieht, das Paket enthält jedoch keine Assemblyverweise oder Inhaltsdateien, die mit diesem Framework kompatibel sind. Wenden Sie sich an den Paketersteller, um weitere Informationen zu erhalten.


Ich habe gelesen, dass in Zukunft EF 7 in einer Store App auf eine lokale SQLight Datenbank zugreifen kann, ich will allerdings auf einen SQL Server im LAN.

Gibt es irgendeine Möglichkeit EF in einer Universal App zu nutzen?
Falls nicht, welche Alternativen gibt es? Ich dachte da an einen WCF Dienst, auf den ich über die Store App zugreifen kann der dann mit EF auf die Datenbank zugreift.

LG Schafschaf

Zitat:

Falls nicht, welche Alternativen gibt es? Ich dachte da an einen WCF Dienst, auf den ich über die Store App zugreifen kann der dann mit EF auf die Datenbank zugreift.

Das ist der wohl präferierte Weg. Veröffentliche deine Daten über eine Webservice API (bevorzugt REST) so das du keine direkte Datenbank Abhängigkeit im Client hast.
Das was da für einen EF7 Nachfolger geplant ist ist wohl mehr für einen begrenzten Offline Anwendungsfall gedacht. Ob das ein vollwertiges Ding wird würde ich eher bezweifeln.

Ehrlich gesagt würde ich das auch eher nicht wollen. Ein direkter Zugriff auf eine veröffentlichte Datenbank von einem mobilen System? Klingt nach Security Alptraum.

@Ralf Jansen

Ok, so werde ich es auch machen
Dabei stehe ich vor einem neuen Problem:
Ich möchte in dem WCF Dienst in Verbindung Mit Entity Framework Späte Bindung nutzen.
Dabei bin ich jetzt soweit, dass ich eine Klassenbibliothek mit dem Code First-Code habe und die Methoden Add, Update und Delete im WCF Dienst.
Nehmen wir mal an ich hätte im Entity Framework die Objekte Schüler und Lehrer definiert.
Da möchte ich nicht für jedes Objekt, was ich adden, updaten oder deleten will eine eigene Methode definieren.
Deshalb habe ich eine Oberklasse für alle Definiert (DataObject hab ich sie genannt), von der alle Code First Objekte erben.
Die Add, Update und Delete Methoden bekommen nun - wenn nötig - ein DataObject als Parameter.
Nun soll es so sein, dass dann zur Laufzeit entschieden wird welches vererbte Objekt da drinsteckt, was übergeben wird.
Kann ich da in den Code First Klassen Add Edit und Delete Methoden definieren, dass sich die Objekte quasi selbst zur Datenbank hinzufügen?
Ich hoffe meine Beschreibung ist einigermassen nachvollziehbar ^^
LG Schafschaf

Keine Ahnung was du in diesem Kontext mit später Bindung meinst.

Zitat:

Da möchte ich nicht für jedes Objekt, was ich adden, updaten oder deleten will eine eigene Methode definieren. Deshalb habe ich eine Oberklasse für alle Definiert (DataObject hab ich sie genannt), von der alle Code First Objekte erben.

Warum? Es ist üblicher guter Stil für verschiedene Domänen verschiedenen Modelle zu haben. Model 1 das EF Model zum persistieren von Daten. Das hat man automatisch die üblichen Methoden wie add, delete, update an seinem DBContext. Sehe keinen Grund da irgendwelche weiteren zu schreiben. Und Model 2 das das Übertragen wird und nur aus Daten besteht. Mehr läßt sich ja auch nicht übertragen daher selhe ich da auch keinen Grund dieses Model mit Methoden zu versorgen. Man muss noch zwischen dem übertragenen Modell und dem EF Model mappen und an der Stelle sollten eher irgendwelche Funktionalitäten greifen und nicht an einer konkreten Modelklasse.

@Ralf Jansen

Mit der späten Bindung mal ein einfaches Beispiel:
Ich habe zwei Tabellen: Schüler und Lehrer.
Auf einer Maschine läuft SQL Server und der WCF Dienst mit EF.
ich dachte dass ich dann auf dem Server eine Klassenbibliothek mit den EF Klassen erstelle und da in die Schüler und Lehrer Klasse jeweils eine Add-Methode hinzufüge wo die sich quasi selbst adden.
Schüler und Lehrer werden von Data Object abgeleitetet. Die Add-Methoden in schüler und Lehrer werden der von Data Object überschrieben.
IM WCF Dienst stelle ich dann eine Add Methode für den Client bereit, bei der Data Object übergeben wird. Wenn ich diese EF Bibliothek dann im Client benutzte, halt ohne EF, nur um die gleichen Objekte bekannt zu machen, kann der Client einfach Add(DataObject) aufrufen. Der Add Methode kann ich dann Schüler, Lehrer oder sonstwas übergeben, der Server addet dann das Richtige. Dann brauch ich keine Daten zu mappen und habe nur eine Add Methode im WCF. Dann brauche ich nicht AddLehrer, AddSchüler etc.
So hab ich mir das vorgestellt.
Ich habe deinen Lösungsansatz nicht ganz verstanden, wie soll ich das denn machen ohne im WCF Methoden bereitzustellen?

Zitat:

Ich habe deinen Lösungsansatz nicht ganz verstanden, wie soll ich das denn machen ohne im WCF Methoden bereitzustellen?

Wenn Schüler und Lehrer Klassen sind dann hat Lehrer einfach eine Property mit einer Liste von Schüler Objekten. Wenn ich also einen Schüler dem Lehrer hinzufüge ändere ich das Lehrerobjekt und zum speichern auf dem Server sende ich einfach wieder das Lehrer Objekt zum Server. Wen der Schüler selbst neu war würde ich den vorher über seinen Endpunkt angelegen.

Es wären also 2 Server Calls. Einmal zum Schüler anlegen und 2.tens um den Schüler einem Lehrer zuzuordnen. Ganz nach dem REST Schema habe ich also einfach die Endpunkte für meine Resourcen (Lehrer, Schüler) und rufe die Standard Http Methoden auf. Einen PUT für den Schüler und ein POST für den Lehrer (Solang du dich im Rahmen des Frameworks bewegt siehst du das aber nicht).

Du denkst wahrscheinlich an einen SOAP Webservice da bist du aber wieder ein Dienst 2.ter Klasse auf deinem Windows Endgerät. Es mag mit SOAP gehen die ganze Geschichte ist eher für REST gedacht.