Nabend,

Eine WPF-App als Frontend mit Datenzugriff via Entity-Framework ist relativ schnell gemacht.
Wenn die Datensätze auch editierbar sein sollen, dann darf der SQL-String aber kein JOIN sein.
Oder vielleicht will ich eine CSV Datei einlesen und diese in Tabellen der DB speichern.

Worauf ich hinaus will ist, ADO.NEt gilt inzischen als veraltet, aber wenn es um solch simplen Sachen wie CSV einlesen geht, komm ich nicht dran vorbei?
Ich kann mir aktuell nicht vorstellen, dass man sich im Designer Code der edmx Datei zu schaffen macht?

Dann ist es auch so, dass, die Tabellen aus denen die Datensätze gezogen werden sollen, müssen beim Anlegen eines Entity-Models bekannt machen.
Und nur auf diese Tabellen kann ich via LInQ oder SQL zugreifen. Ich kann bisher aber nicht sehen, dass die Datensätze, die via SQL gezogen werden, irgendwo lokal auf der Clientseite zischengespeichert werden, vergleichbar mit Dataset.

Ein Object, vergleichbar mit einem Dataset, wird man im Entiy Model nicht finden, soweit klar.
Es muss doch aber irgendwas anderes geben, um dieses Prinzip der lokalen Datenhaltung zu behalten?

Zitat:

Wenn die Datensätze auch editierbar sein sollen, dann darf der SQL-String aber kein JOIN sein.

Das ist eher ein prinzipielles Problem relationaler Systeme. Wenn Zugriffsbibbliotheken änderbare Joins anbieten dann muß man meißt auch genauer definieren was man da genau haben will. Generisch fast nicht möglich ohne irgendwelche Überraschungen beim konkreten Verhalten.

Zitat:

Worauf ich hinaus will ist, ADO.NEt gilt inzischen als veraltet, aber wenn es um solch simplen Sachen wie CSV einlesen geht, komm ich nicht dran vorbei?

Jeder DB Zugriff erfolgt letztendlich über ADO.Net (für mich ist das Connection, Command, DateReader etc. und nicht Dataset und Konsorten das ist wiederum eine der Abstraktionsschichten auf ADO.Net) und die ist damit natürlich nicht veraltet. Man macht sich mittlerweile nur nicht mehr so oft selbst die Hände schmutzig und schaltet irgendeine Abstraktionsschicht (meist einen ORM) dazwischen. Eine DB Zugriffs Schicht erscheint mir für einen simplen CSV Zugriff totaller Overhead es ist ein simples File das man auch mit einem simplen Filezugriff auslesen und danach interpretieren kann.

Zitat:

Es muss doch aber irgendwas anderes geben, um dieses Prinzip der lokalen Datenhaltung zu behalten?

Du machst eine Abfrage und erhälst dazu eine ObjectQuery die an einem ObjectContext hängt. Beides zusammen ergibt im weitesten Sinne die Entsprechung zum DataSet/DataTable. Wüßte jetzt nicht was da fehlen sollte?

Da du von CSV, Datenbanken etc. sprichst aber eigentlich nicht sagst was dein Problem ist rate ich mal das du irgendwas aus der Ecke BulkTransfer oder Datensynchronisierung probierst. Dann würde ich bestätigen das da sowohl die DataTable/DataAdapter als auch die EF Abstraktionsschicht eher nicht für gedacht sind.

Für jemanden der das eigentliche Problem nicht erkannt hat(O Ton), hast Du dir viel Zeit genommen, Wozu?

Ich wollte weitere Informationen aus dir rauslocken. Da keiner geantwortet war die Wahrscheinlichkeit hoch das es nicht nur ich nicht verstanden habe(und vermutlich scheiterte es nicht am Problem sondern an der Art der Formulierung). Hat offensichtlich nicht funktioniert.

mmgg hat folgendes geschrieben :

Für jemanden der das eigentliche Problem nicht erkannt hat(O Ton), hast Du dir viel Zeit genommen, Wozu?

Mit solche Antworten wirst Du niemanden motivieren, Dir weiterhin zu helfen ...

Hätte beschreiben sollen wie ich csv in DBs einlesen will?
Stell dir vor, meine Frage ist vom Typ X vs. Y!

Dass R.Jansen die Antwort nicht gut findet, na klar, was sonst.
Dass alle anderen nun kollectiv beleidigt sind, glaub ich nicht.
Dass es allen anderen an Motivation mangelt glaub ich nicht.

Es wird niemand antworten, daran hab ich keinen Zweifel.

Was zu tun bleibt, diese Frage mal quer durch andere Foren zu stellen, um zu sehen wie weit das reicht, daran liesse sich viel ablesen

Wie wäre es denn, wenn Du versuchst, genauer zu beschreiben, was Du möchtest? Oder zumindest mal sachlich auf das eingehst, was Ralf geschrieben hat? Zu viel verlangt?

Und wenn jemand Dir antwortet, diesem jemand eine Antwort zu geben, von der Du weißt, dass sie ihm nicht gefällt, ist undankbar und unfreundlich. Und ja, sowas hält auch andere davon ab, Dir zu antworten.

@Ralf, muss etwas zurückrudern, hab nicht gesehen dass du auch geantwortet hattest.
Wenn es dir also tatsächlich darum ging bessere beschreibung zu kriegen, dann bitte.

Es geht mir nicht um was von beiden ist besser oder schlechter .
Das Entity-Model scheint mir bis jetzt etwas zu sein wodurch das Erstellen eines Datenbank-Frontend nochmal vereinfacht wird.
Es scheint aber auch nur brauchbar solang es nicht um komplexere Aufgaben geht.

Es gibt keien CSv die ich einlesen will.
EIne CSV einzulesen soll hier nur ein fiktives Beispiel sein, für alle möglichen tasks bei denen man auf eine ADO Datable zurückgreifen würde.
Wenn ich Entity Model wähle, statt ADO, ist eine Datatable erst mal nicht verfügbar.
Jetzt könnte man sagen, 'dann bid doch ADO eben auch mit ein' , kann man sicher machen, macht aber nur Sinn wenn das Entity Model nichts vergleichbars zu bieten hat?
Das weiss ich nicht.

Dann Thema JOIN-SQL-Strings
Datensätze die auf einen JOIN basieren anzuzeigen, geht ohne weiteres mit dem Entity-Model. Wenn aber zumindest die n-Seite editierbar sein soll, weiss ich nicht wie das unter Entity gehen soll? Das ist zwar unter ADO auch ein grosser Aufwand aber möglich.

Gruss Jochen

Zitat:

Es scheint aber auch nur brauchbar solang es nicht um komplexere Aufgaben geht.

Die Abstraktions geht bei EF (oder jeden anderen ORM) weiter als bei klassischem ADO.Net daher geht einem schonmal (zumindest gefühlt) die Kontrolle verloren. Insbesondere dann wenn man vorher gewohnt war im Zweifel das SQL noch selbst zu optimieren. Lösungerfahrung in klassischem ADO.Net ist in EF meist wenig hilfreich. Es braucht andere Wege. Wenn du gewohnt bist eine Blick aufs SQL zu werfen dann sieh dir mal LinqPad an. Dort kann man wunderbar sein eigenes EF Model anbinden, dagegen arbeiten und nachschauen was den tatsächlich für SQL generiert wird.

Zitat:

Jetzt könnte man sagen, 'dann bid doch ADO eben auch mit ein' , kann man sicher machen, macht aber nur Sinn wenn das Entity Model nichts vergleichbars zu bieten hat?

EF funktioniert anders. Aber man bekommt eigentlich alles irgendwie hin was man auch mit DataTable und Konsorten machen könnte. Um beim csv nach Database Beispiel zu bleiben, mit einem DataAdapter würdest du eine DataTable aus einer Quelle befüllen dann den RowState der Daten ändern um dann die Daten über einen anderen DataAdapter in ein anderes Ziel schreiben zu können. In EF hängt die Connection zur Datenbank am Context genauso wie die Entitäten. Also würdest du die Daten über einen Context laden die Entitäten vom Context detachen und dann deren EntityKey auf null setzen. Jetzt kannst du die Entitäten an einen anderen Context attachen (der für das Ziel steht) und saven. Ähnlich aufwendig da beide Systeme nicht dafür gedacht sind zwischen Systemen zu verschieben sondern primär eben dazu den Änderungszustand gegenüber einem System nachzuhalten.

Zitat:

Datensätze die auf einen JOIN basieren anzuzeigen, geht ohne weiteres mit dem Entity-Model. Wenn aber zumindest die n-Seite editierbar sein soll, weiss ich nicht wie das unter Entity gehen soll? Das ist zwar unter ADO auch ein grosser Aufwand aber möglich.

Man(oder zumindest ich) würde in EF dann eher keine Joins benutzen. Die braucht man eigentlich in diesem Umfeld auch für so etwas meist nicht. Wenn du eine Entität irgendwo anzeigst und du möchtest Daten aus einer anderen Entität mit anzeigen sind die Beteiligten ja üblicherweise Referenziel gekoppelt. Die Referenz bildet man im Context nach und erhält dann eine Navigational Property an den Entitäten über die man dann auf die Daten der anderen Entität zugreifen kann. Beispiel - Ich habe Bestellungen von Kunden diese Bestellungen will ich irgendwo anzeigen habe aber nur die KundenID in der Bestellungen Tabelle die sich nicht zum anzeigen eignet man möchte natürlich gern den Kunden Namen. In Ef fängt man dann nicht an sich die zusätzlich benötigten Daten ranzujoinen (so das man mit wenig Aufwand Bestellungen updatebar hält) sondern man zieht sich die zusätzlichern Daten einfach über die Navigational Properties. An ein Grid würde man einfach Bestellungen binden und sich denn Kundennamen über Bestellungen.Kunden.Name an einen Spalte binden.

Deiner letzten Antwort würde ich so begegnen wollen.

Die meisten Schulungsanbieter bieten ADO.NET immer noch an. Und wenn es dabei ist, dann sogar als 2. oder 3. Stufe die man innerhalb des Kurses nehmen muss,
um dann EF zu passieren.

Wenn jemand sagen würde, der Grund dafür ist der, dass ADO weiterhin die bessere Wahl ist(für das Datenbank-Frontend(X)) ? Unter der Prämisse, dass ich auf JOINS nicht verzichten will, will weiterhin Beziehung setzten zwischen den lokalen Tabellen im Dataset, will auch einigermassen flexible sein, denn in ein Objectquery lassen sich nur Daten ziehen die ich vorher beim erstellen(Entity-Model) festgelegt hab.

Liegt er dann völlig daneben?

Nein. Wenn du Kontrolle willst, hier über das konkret verwendete SQL, musst du Abstraktionsschichten weglassen oder du fängst an gegen die Abstraktionsschicht zu arbeiten. Und wenn man bei EF die Abstraktion weglässt ist man halt bei klassischem ADO.Net. EF kapselt ja auch nur ADO.Net mit einer netten OO-Schicht. Wenn man sich dem mit einer relationalen SQL nahen Denke nähert erscheint die womöglich sogar hinderlich während diejenigen die bereits vollständig mit einem objektorientierten Ansatz großgeworden sind ohne eher verloren wäre.

Da im Kern aller Datenbanktechniken in .Net immer letztlich Connection, Command, DataReader etc. steckt finde ich es auch richtig wenn man die in einer Schulung zuerst behandelt. DataTable, DataAdapter, Tableadapter etc. sind da eher optional und sollte Alternativ zu EF behandelt werden aber sicher nicht als Voraussetzung. Ich würde mich aber nicht wundern wenn Microsoft das für seine MOC Schulungen trotzdem erzwingt.

Kontrolle will ich vielleicht auch manchmal.
ABer hier gehts mir um Möglichkeiten. Mittelständler(zumindest meine Erfahrung) wollen meist mehr als nur ein FE das Daten anzeigt, die hier und da editierbar sind.
Ich schreib das so, weil ich glaub die ohne weiteres, dass mit EF auch alles ghet was mit ADO möglich ist, aber:

Nehmen wir an, es soll dem User möglich sein, im FE von andern DBs daten zu ziehen die nicht die STandard DB sind. Er wählt also z.B aus einer Dropdown den Servernamen, dann den Db Namen usw.
Codseiteig stingzusammensetzten und Daten holen.
Unter EF kann ich den String auf dieselbe Weise zusammensetzten, aber das/der Context ist doch festverdrahtet.
Das was zu tun wäre, um dies auch unter EF zu machen. wär das nicht ungleich grösser Aufwand.

Wenn ich jetzt noch dazunehme, dass Daten von 3 bis 4 Tabellen gezogen werden sollen, diese nun auch in relation gesetzt werden sollen, also Dataset und darin die Relationen setzten, dann seh ich nicht wie das auch mit Objectquery möglich sein soll?

Sobald Dynamik rein kommt also du Strukturen erst zur Laufzeit kennst (wenn du das gemeint hast), dann ist ein stark typisierter Ansatz nicht mehr hilfreich. Es ist ja einer der zentralen Aspekte bei ORMs durch konkrete Typen Programmiersicherheit schon zur Compilezeit zu gewinnen. Wenn es bekannte Strukturen nicht gibt kann man auch keine frühzeitig definieren und ohne Entitäten bleibt beim Entity Framework nicht mehr viel hilfreiches über. Wenn es einfach verschiedene DBs sind mit bekanntem Modell dann öffne einfach den entsprechenden Context mit einem passenden Connectionstring.

Es war weiter oben davon die Rede , dass prinzipiell alles was mit ADO möglich ist, auch mit EF möglich ist. Das wollte ich noch etwas aufdröseln.
Man gehe davon aus, es gibt ein DBContext.
Aufgabe ist aber die Daten zu analysieren, eventl zu modifizieren, danach daraus z.B. Diagramme darstellen, bevor sie überhaupt angezeigt werden.
Mit EF, soweit ich sehen kann, müsst ich mir sowas wie eine DataTable mit DataRows selber machen?

Da noch keiner geantwortet hat probier ich es nochmal.
Bei konkreten Problemen könnten wir hier konkret helfen. Bei so allgemein gehaltenen Fragen geht es fast nur philosophisch und ich versuch es mal mit einem allgemeinen Ratschlag bezogen auf das was ich glaube zwischen den Zeilen zu lesen.

Mit dem Ansatz es geht mit DataTable so, wie geht das genauso in EF wirst du nicht weit kommen. Denn der Ansatz mit DataTable geht am besten eben mit DataTable. Nach Ähnlichkeiten suchen um es dann ähnlich zu machen wird immer nur zu suboptimalen Lösungen führen die vermutlich immer schlechter sind als dort wo man diesen Ansatz gelernt hat. Um zu lernen wie es in EF geht kann ich dir nur raten es zu benutzen, dabei Erfahrungen zu sammeln und möglichst die alten Erfahrungen zu vergessen bzw. zu ignorieren. Wenn du denn Punkt erreicht hat in EF zu ~denken~ ohne gleichzeitig gedanklich nach DataTable zu übersetzen bist du an der Stelle zu entscheiden ob EF die Sorte von Framework ist die bei der üblichen Sorte von Problemen die du hast hilfreich ist oder nicht.
Ich weiß das ist verdammt schwer. Bisherige Erfahrungen ~verlernen~ um sich beim machen neuer Erfahrungen nicht zu behindern ist so ziemlich das schwierigste Problem dem man als Programmierer begegnet.

Ich will es auch nicht weiter strapazieren.
Stelle dir vor für meine vorherige Antwort hab ich eine Stunde gebraucht, hab nach Fragestellung gesucht um dir doch noch was rauszuziehen.

Ich hab einfach gehofft Du könntest mir eine Beschreibung geben ala - Wenn ich jemandem ADO abstrakt beschreiben wollte, der vorher den Vorgänger verwendet hat,
dann würd ich sagen, man braucht für die Standard aufgaben 5 Objecte. Object 1, ist dafür da, Object 2 dafür ... usw. Wenn es um ein JOIN-SQL geht würde noch ein 6tes dazukommen.
Mit Object 2 lässt sich was machen, was mit dem Vorgänger nicht möglich war. INSERT,DELETE,UPDATE ist etwas komplexer, aber dafür bla bla.

nach dieser Beschreibung wird er ADO nicht anwenden können aber hat eine Vorstellung, kann es in Relation setzten zu seiner bisherigen Anwendung.