Die ganze Frage wurde umgeschrieben, um klarer zu werden.
Neues Projektdesign:
Hier kann ich Dataset verwenden - kein Problem, aber ich würde gerne den Vorteil von Entity Framework gegenüber Dataset in detaillierterer Erklärung kennen. Ich habe Artikel über das Entity-Framework gelesen, und ich habe gesehen, dass die Leute aus folgenden Gründen EF-over-Dataset besser kennen gelernt haben.
Ich würde gerne wissen, ob dies immer noch Vorteile sind, die ich in meinem Fall mit EF erreichen kann - datenbankbezogene Aktionen werden immer mit gespeicherten Prozeduren durchgeführt:
EF ist viel sauberer und viel einfacher zu pflegen und zu programmieren. Abfragen gegen den EF ObjectContext werden immer gegen die Datenbank
Da die Zuordnung zwischen Ihren Objekten und Ihrer Datenbank deklarativ anstatt in Code angegeben wird, können Sie die Auswirkungen auf den Code, den Sie in Ihren Anwendungen ändern müssen, minimieren, wenn Sie Ihr Datenbankschema ändern müssen Das System bietet eine Abstraktionsebene, die hilft, die App von der Datenbank zu isolieren. Die EF kann daher einen großen Teil des Codes ersetzen, den Sie sonst selbst schreiben und verwalten müssten (Was ist, wenn das Design für gespeicherte Prozeduren geändert wurde?)
Die EF wurde speziell strukturiert, um den Prozess der Zuordnung von Abfragen / Formungsergebnissen von Gebäudeobjekten und der Verfolgung von Änderungen zu trennen.
DataSets saugen, besonders in einem WCF-Szenario (sie fügen viel Overhead für die Handhabung der In-Memory-Datenmanipulation hinzu) - & gt; bedeutet EF mit WCF ist besser in der Leistung?
1. EF ist viel sauberer und viel einfacher zu pflegen und zu programmieren gegen - & gt; & gt; Kannst du das ausarbeiten? .. ist das wegen # 2 unten?
EF ist ein Object Relational Mapper (ORM) und generiert automatisch Objekte, die zu Ihrem Datenbankschema gehören, wie in # 2 beschrieben. EF ist eine Out-of-Box-Abstraktion für Ihre Datenzugriffsebene und implementiert in der aktuellen Version ein Repository-Muster. Dies bietet Ihnen Vorteile wie LINQ, CRUD-Operationen für Objektdiagramme und das, was das EF-Team als bewährte Methode für den Zugriff auf Daten über .NET erachtet.
Die Out-of-Box-Funktionalität und die einfache Integration in die Datenbank (insbesondere SQL Server) können die Wartung und das Programmieren erleichtern. Es gibt jedoch Situationen, in denen die Verwendung eines ORM möglicherweise nicht die beste Option ist und Sie vorsichtiges Urteilsvermögen verwenden sollten. Hier sind einige Szenarien, in denen Sie darüber nachdenken, kein ORM zu verwenden (insbesondere wenn Ihr Team keine aktuellen Kenntnisse in EF hat): begrenzte Datenabfragen, nicht komplexe Anwendungen, komfortables Schreiben oder Verwenden Ihrer Datenzugriffsebene, Ihr Bewerbungsschluss ist aggressiv usw. andere Optionen, die ich unten erwähnt habe.
2. Wenn Sie Ihr Datenbankschema ändern müssen, können Sie die Auswirkungen auf den Code minimieren, den Sie in Ihren Anwendungen ändern müssen - & gt; & gt; Was geschieht, wenn Parameter und zurückgegebene Felder einer gespeicherten Prozedur geändert werden? EF noch minimieren die Auswirkungen?
Ja, EF wird basierend auf der EDMX-Datei generiert, die einfach eine XML-Datei Ihres Datenbankschemas ist. Dazu gehört auch das Aktualisieren von Objekten, die Ihren gespeicherten Prozeduren zugeordnet sind (HINWEIS: Dies gilt nicht, wenn Sie zuerst Code verwenden, bis EF6 freigegeben wird). Sie können eine gespeicherte Prozedur ändern, und EF kann das aktualisierte Schema übernehmen und Ihren Code aktualisieren. Allerdings müssen Sie Ihren Code dort reparieren, wo Sie Methoden für gespeicherte EF-Prozeduren aufgerufen haben, und die Parameter haben sich geändert. Sie können auch etwas LINQ to SQL verwenden, wenn Sie sich mit EF nicht wohl fühlen und gespeicherte Prozeduraufrufe als Objektmethoden bereitstellen.
3. DataSets saugen, besonders in einem WCF-Szenario (sie fügen viel Overhead für die Handhabung der In-Memory-Datenmanipulation hinzu) - & gt; & gt; Kannst du mehr erklären?
"DataSets saugen" ist offensichtlich eine generische Aussage. Sie verwenden DataSets für die Zwecke, für die sie bestimmt sind und die mit Daten im Speicher arbeiten, die .NET verwenden. Da sich DataSets im Speicher befinden, werden sie bei einfachen CRUD-Vorgängen als ineffizient betrachtet. Es wird empfohlen, gespeicherte Prozeduren und Datenleser zu verwenden (stellen Sie sicher, dass sie geschlossen werden, wenn Sie Daten lesen), um effizient Daten mit der SQL-Datenbank zu lesen.
Neben EF gibt es noch andere Möglichkeiten:
Machen Sie es selbst - Schreiben Sie gespeicherte Prozeduren, verwenden Sie Datenleser und ordnen Sie sie POCO-Objekten zu
Verwenden Sie eine dynamische Bibliothek - Dapper, ServiceStack ORM Lite, Einfache POCO, Einfache Daten, Massive
Verwenden Sie LINQ to SQL - Leichtere Datenzugriffsebene (nur für SQL Server)
Andere ORMs - NHibernate ist eine erstklassige Wahl.
Dies ist, um auf Jonathans Antwort zu DataSet zu antworten. Da ein Kommentar zu kurze Inhalte zulässt, stelle ich es daher als Antwort dar.
Das ist alt, aber bis jetzt, mit EF6 und EF dotnet core, sehe ich, dass es immer noch gültig ist, diesen Punkt zu diskutieren.
Ich finde Meinungen zu diesem Thema und erreichte schließlich diesen Beitrag. Ehrlich gesagt stimme ich Jonathan mit DataSet nicht zu.
Zur Antwort auf "Da DataSets im Speicher sind, werden sie als ineffizient betrachtet, wenn einfache CRUD-Operationen ausgeführt werden". Ich glaube, EFs DbContext ist ebenfalls im Speicher und die Offline-Datenverarbeitung ist nicht nur für DataSet gedacht, sondern auch für LinQ2SQL und EF. Eine einfache CRUD-Operation kann mit DataTableAdapter und CommandBuilder ausgeführt werden, Sie müssen keine einzelnen SQL-Anweisungen schreiben. DataSet ist Teil von ADO.NET, wir können nicht sagen, ADO.NET empfiehlt Stored Procedure oder etwas anderes, es muss alle Möglichkeiten des Zugriffs auf die Datenbank unterstützen, tatsächlich greift DataSet nicht auf Datenbank, DataTableAdapter, DataReader, DbCommand zu.
Wenn Sie typisiertes DataSet von Visual Studio verwenden, sehen Sie es in der Zuordnung von gespeicherten Prozeduren und im Stapelbetrieb weit überlegen als EF. Mein Projekt hat 5000 gespeicherte Prozeduren und die Zuordnung zu EF ist mühsam, EF löst viele Arten von Fehlern aus, wenn die Deklarationen nicht von EF unterstützt werden. Auf der anderen Seite ermöglicht Typed DataSet, sehr kleine Details des Mappings gespeicherter Prozeduren zu steuern und für Ihren Bedarf zu biegen. Bei Stapeloperationen können Sie mit Tabellenadaptern steuern, wie viele Anweisungen gleichzeitig gesendet werden können. Wie steht es mit EF? 1 zu 1, Stellen Sie sich vor, Sie müssen 10000 Datensätze importieren, ich habe einen Vergleich für dieses Szenario gemacht, es gibt keine Möglichkeit, es schnell in EF-Weise zu machen. Wenn die gespeicherte Prozedur geändert wird, geben Sie mir 30 Sekunden, um das DataSet zu reparieren, entweder neu zu generieren oder manuell zu reparieren. Du wirst es in EF nicht schneller finden.
EF ist schneller als ADO.NET mit DataSet. EF fügt viel Overhead hinzu, um ExpressionTree zu analysieren, auszuwerten und eine SQL-Anweisung zu erzeugen, bevor ADO.NET zur Aktualisierung der Datenbank verwendet wird. Unter EFs Haube befindet sich ADO.NET.
Das Einzige, was ich bei DataSet als unpraktisch empfunden habe, ist, dass DataRow nicht POCO ist. Es ist schwierig, sie zu serialisieren, sie in WCF zu saugen, wenn Sie sie DataContract zuordnen müssen, Sie können EFs POCO direkt als Datenkontrakt verwenden.
Bei Projekten, die Sie mit vielen Daten, Massenaktualisierungen und gespeicherten Prozeduren bearbeiten müssen, sollten Sie sich von EF fernhalten. Ich habe EF zu viele Versuche gegeben, mit Enterprise-Projekten zu spielen, aber irgendwann musste ich TypeDataSet für alle verwenden. Ich suche immer noch nach Meinungen, weil ich immer noch hoffe, dass EF in der Lage sein wird, meine Bedürfnisse zu beantworten. Ich mag die Einfachheit des Ansatzes von EF, aber im Vergleich zu Typed DataSet ist es immer noch zu jung.
Tags und Links .net entity-framework visual-studio-2012 dataset strongly-typed-dataset