Ist CodeFirst für Großanwendungen gedacht?

Ich habe Entity Framework, insbesondere EF 4.1, gelesen und bin diesem Link gefolgt ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-). framework-4.aspx ) und die Anleitung zu Code First.

Ich finde es ordentlich, aber ich habe mich gefragt, ob Code First nur eine Lösung für eine schnelle Entwicklung sein soll, bei der Sie ohne viel Planung sofort einsteigen können, oder ob es tatsächlich für Großanwendungen gedacht ist.

Ich kann einige Kritiker da draußen haben, aber als ich einige dieser Posts von Hanselman und Gutherie las und dann Julia Lermans Buch über Entity Framework las , hatte ich eine WIRKLICH schwierige Zeit mit Code. In den vielen Jahren, in denen ich Anwendungen erstellt habe, bin ich viele Wege gegangen, die sowohl vom Prozess als auch von der Auswahl abhängig waren, und ich habe festgestellt, dass ich beim Erstellen einer Anwendung viel erfolgreicher bin, wenn ich eine datenzentrierte Sichtweise einnehme.

Ich spreche hier von Branchenanwendungen. Dies ist, wenn Sie ein Geschäftsproblem oder einen Geschäftsprozess haben, hinter dem eine Softwarelösung stehen muss. Sie haben Daten, die auf irgendeine Weise verwaltet werden müssen. Es ist besser, Ihre Daten zu kennen, wie sie sich auf sich selbst beziehen und wie sie im Unternehmen verwendet werden. Aus diesem Grund modellieren Sie diese Daten und erstellen anschließend eine Anwendung / Lösung. Wenn Sie nach meiner Erfahrung die Anwendung mit den Daten nachträglich erstellen, wird irgendwann etwas ausgelassen, und Sie haben einige Umgestaltungen (in vielen Fällen - MAJOR-Umgestaltungen).

Kleine Anwendungen mögen eine Ausnahme sein, aber ich werde weiterhin meinen datenzentrierten Ansatz verwenden.

Ich verstehe nicht, warum CodeFirst in großen Unternehmensprojekten nicht verwendet werden kann. Ich werde sagen, dass ich EF CodeFirst in mehreren Projekten verwende, eines, bei dem die Datenbank von meinem EF CodeFirst-Modell generiert wird, und das zweite, bei dem EF CodeFirst einer vorhandenen Datenbank zugeordnet wird.

Wie effektiv CF in einem großen Projekt ist, hängt meiner Erfahrung nach stark davon ab, wie stark Ihre Datenschicht von Ihrer Geschäftsschicht abstrahiert ist.

In einem meiner Projekte ruft die Business-Schicht die Datenbank beispielsweise direkt über linq auf. Ich verwende Linq, um meine Datenbankebene zu abstrahieren, und verwende CodeFirst, um meine POCOs dem Datenbankschema zuzuordnen. In diesem Fall vereinfacht CodeFirst das Beibehalten von Unterschieden zwischen DB-Konventionen (Beziehungs- und Tabellennamen) und meinen C # -Klassennamen erheblich. Außerdem kann ich Datenbankänderungen vornehmen, ohne die Interaktion meiner Business-Schicht mit der Datenbank erheblich beeinflussen zu müssen.

In einem anderen Projekt habe ich den Datenbankzugriff jedoch in ein nicht generisches Repository-Muster abstrahiert, und die Get * -Methoden meines Repositorys sind ausschließlich für die Ausführung von Abfragen in der Datenbank verantwortlich und geben reale Objekte (nicht IQueryable<T>s) zurück. In diesem Fall konvertieren die Repository-Methoden DB-Entitäten in POCO-Entitäten. In diesem Fall bietet CodeFirst für Sie weniger Vorteile, da die CodeFirst-POCOs nur von kurzer Dauer sind und schnell in C # -Klassen der Geschäftsschicht konvertiert werden.

Letztendlich hängt es davon ab, wie das Team strukturiert ist und wie gut das Team (oder die Senioren) mit den Nicht-DBA-Ingenieuren zurechtkommt, die Datenbankschemata ändern, und wie stark sich Schemaänderungen auf Ihre Codestruktur auswirken werden. Da CodeFirst einer vorhandenen Datenbank zugeordnet ist, ist es für mich ganz einfach, eine Eigenschaft einem neuen Spaltennamen neu zuzuordnen, ohne dass dieser Eigenschaftsname global umbenannt werden muss. Dies ist insbesondere dann von Bedeutung, wenn Sie von einem Namen sprechen für ein Datenbankfeld anstelle einer C # -Eigenschaft. Es ist für mich auch trivial, Code-Unterstützung für neue Datenbankfelder hinzuzufügen, ohne meine C # -Entitäten komplett umgestalten zu müssen (einer der Gründe, warum ich EF CodeFirst von einer vorhandenen Datenbank aus Linq-to-sql überlassen habe).

Code First ist nicht für Großanwendungen geeignet. Der Turnaround bei der Entwicklung großer Apps ist sehr groß.

Typischerweise ist der Lebenszyklus Ihrer Business-App wie folgt:

1. Version 1 ist in Produktion
2. Version 2 ist in der Beta
3. Version 3 befindet sich in aktiver Entwicklung
4. Version 4 ist in Planung.

Darüber hinaus gibt es andere anwendungsübergreifende Kommunikationsbrücken, geplante Aufgaben, die Integration von Drittanbietern sowie Webservices für verschiedene Kommunikationsgeräte wie Mobiltelefone usw.

Schließlich verwendet Code First den ObjectContext von Entity Model, und ältere EF, die EDMX generierten und ObjectContext mit EntityObject verwendeten, waren für alles ausreichend. Sie können die Textvorlage leicht anpassen, um Code zu generieren. Die Methode zum Erkennen von Änderungen ist bei der Implementierung von ObjectContext langsamer, aber anstatt einen Proxy zu generieren, hätte das EF-Team die Geschwindigkeit zum Erkennen von Änderungen leicht verbessern können, anstatt den Code zuerst neu zu erfinden.

Automatisierte Migration

Automatisierte Migration hört sich theoretisch gut an, aber in der Praxis unmöglich, wenn Sie erst einmal live gehen. Es ist nur gut für das Prototyping und die Entwicklung einiger schneller Demos.

Code First Migration ist in einem solchen System überhaupt nicht geeignet. Version 1 und Version 2 sprechen höchstwahrscheinlich mit derselben Datenbank. Bei Version 3 und Version 4 handelt es sich normalerweise um eine Staging-Version mit einer anderen Datenbank.

Datenbank zuerst

Database First ist ein praktischer Ansatz. Es ist einfach, SQL-Skripte zu vergleichen, zu visualisieren und zu warten. DBAs können problemlos damit arbeiten.

Textvorlagen

Wir haben unsere eigenen Textvorlagen zum Abfragen und Erstellen von EDMX und ObjectContext mit wenig benutzerdefinierter Implementierung erstellt, die Leistungsprobleme behebt. Es gibt mehrere Anwendungen mit mehreren Versionen, die problemlos mit derselben Datenbank kommunizieren.

Für mich ist das Klicken mit der rechten Maustaste auf die .tt-Datei und das Klicken auf "Benutzerdefiniertes Tool ausführen" der mit Abstand schnellste und einfachste Schritt, als Klassen zu schreiben, das Modell zu konfigurieren und zu erstellen.

In der Regel wurde die Datenbank für große Projekte bereits erstellt. Entweder weil es sich um eine ältere Datenbank handelt oder weil sie von einer kompetenten Datenbank zur Leistungssteigerung erstellt wurde. Der einzige Vorteil von CodeFirst besteht darin, dass Sie nicht die Entities von EF, sondern die POCOs verwenden möchten.

Es klingt für mich so, als ob "Code First" für die Verwendung von EF mit "agiler" (Harfe nicht zu viel in diesem Begriff, ich meine nicht unbedingt die Methodik) und Greenfield-Apps gedacht ist, für die Sie keine haben vorhandenes Datenmodell oder vorhandene Daten; Die Art von App, die Sie auch mit Django, einem PHP-Framework oder Rails verwenden können, um die Richtlinien des Frameworks zu befolgen, bei denen normalerweise das Datenmodell als Teil des Codes erstellt wird, anstatt eine Anwendung um ein herkömmliches Datenmodell zu erstellen Microsoft Umgang mit Dingen.

Um die Frage zu beantworten, würde ich nein sagen. Wenn Sie bereits über vorhandene Daten verfügen und eine entsprechende Anwendung erstellen, ist Code First weniger sinnvoll. Und ich habe EF noch gar nicht so oft verwendet, geschweige denn Code First EF. Es scheint sich um einen locker gekoppelten Ansatz für Code zu handeln, der immer vorteilhaft ist. Angenommen, Sie können Code First verwenden und die Klasse dann immer noch auf ein vorhandenes Datenmodell verweisen (anstatt gezwungen zu sein, das Modell zu generieren), dann könnte der Code First-Ansatz dennoch helfen, ordnungsgemäß abstrahierten und testbaren Code zu schreiben, ohne all den üblichen Aufwand für die Verwendung Entity Framework (dh die generierten Metaklassen).

Ich würde bei wirklich großen Projekten sagen, Code-First macht keinen Sinn.

Wenn das Projekt wirklich umfangreich wird, haben Sie häufig eine strikte Trennung der Bedenken. Sie können nicht dieselbe Person haben, die C # -Code schreibt, Datenbankdesign, HTML / CSS schreibt und visuelles Design in Photoshop ausführt. Stattdessen wird das Datenbankdesign von einem Datenbankadministrator (oder zumindest von einer engagierten Person, die ihren Job kennt) durchgeführt.

Da die Datenbank von einer Person entworfen wurde, die mit der Datenbank, den SQL- und Administrations- und Datenbankentwurfstools vertraut ist, ist es seltsam, wenn diese Person Entity Framework verwendet.

Darüber hinaus bin ich mir nicht sicher, ob Entity Framework leistungsfähig genug ist, um die Datenbank ordnungsgemäß zu entwerfen. Was ist mit Indizes? Einschränkungen? Ansichten?

Code first ist auch für große Systeme geeignet: Untersuchen Sie das Modell nach der Erstellung und ordnen Sie es mit der fließenden API neu zu, bis Sie ein DB-Modell erhalten, das Ihnen gefällt.