Data Binding mit EF Core

Beginnen Sie die Support Desk-Datenkonsole, indem Sie entscheiden, welche Objekte für eine Sitzung und welche für einen Datenbankvorgang aktiv sind. Wisej.NET-Formulare behalten den Benutzerstatus bei, aber ein Entity Framework-Datenbankkontext sollte eine kurze Arbeitseinheit darstellen.

Das serverseitige Programmiermodell fühlt sich vertraut an, da Steuerelemente, Ereignishandler und Bindungsquellen zusammen bleiben. Geben Sie dem Context nicht die gleiche Lebensdauer. Erstellen Sie es für eine Abfrage oder Änderung, speichern Sie es bei Bedarf und entsorgen Sie es dann, anstatt es als Schnittstellenstatus beizubehalten.

Separater Sitzungsstatus, Schnittstellenobjekte, einzelne Anfragen und Datenbankarbeit. Ein erwarteter Vorgang kann in einem anderen Thread fortgesetzt werden und ein Context ist nicht threadsicher. Wenn es in einer langlebigen Form gehalten wird, bleiben verfolgte Entitäten auch noch lange nach dem Vorgang erhalten, der sie benötigt.

Verwenden Sie AddDbContextFactory als Standard, damit Suchen, Suchen, Speichern und Löschen jeweils einen neuen Context besitzen können. Ein langlebiger Modal-Editor-Context ist eine bewusste Ausnahme: Halten Sie ihn privat, schützen Sie den Zugriff und entsorgen Sie ihn, wenn dieser Editor geschlossen wird.

Registrieren Sie die Kontextfabrik beim Abhängigkeitsinjektionsanbieter mithilfe der konfigurierten Verbindungsinformationen. Überbrücken Sie diesen Anbieter mit Wisej.NET, damit Seiten dieselben registrierten Dienste auflösen. Beschränken Sie die Diagnoseeinstellungen auf die Entwicklung und vermeiden Sie die Einführung eines zweiten konkurrierenden Service-Containers.

TicketQueryService speichert die Fabrik, keinen gemeinsamen Context. Jede Methode erstellt und entsorgt ihren eigenen Context, bevor sie zurückkehrt. Dies verhindert, dass die nachverfolgten Änderungen eines Benutzers einen Context mit der Abfrage eines anderen Benutzers teilen, und verhindert den gleichzeitigen Zugriff auf diesen Context.

Behalten Sie ausgewählte Datensätze, Filter, ausstehende Bearbeitungen und Bindungsquellen in ihrer Sitzung bei. Die gemeinsame statische Speicherung eignet sich nur für wirklich gemeinsam genutztes unveränderliches Material, beispielsweise Referenzdaten. Eine Hintergrundoperation erstellt auch einen eigenen Context, anstatt den Status des Formulars zu übernehmen.

Count demonstriert die gesamte Betriebsgrenze. Der Ladeschutz verhindert eine zweite Übermittlung, während ein neuer Context die Tickets zählt. Wenn die Datenbank nicht verfügbar ist, erklärt der freundliche Fehler den Fehler und die abschließende Bereinigung stellt die Schaltfläche für einen weiteren Versuch wieder her.

Erstellen Sie die Lösungsebenen und die Factory-Registrierung, lösen Sie dann den Abfragedienst von einer Seite aus und führen Sie die asynchrone Zählung aus. Beziehen Sie die Design-Time-Factory mit ein. Ihre Überprüfung sollte in der Lage sein, zu identifizieren, wo jeder Context erstellt und entsorgt wird, ohne dass es irgendwo einen statischen Context gibt.

Definieren Sie das Support-Desk-Schema, bevor Sie sich auf datengebundene Bildschirme verlassen. Das Entity Framework-Modell verbindet Schnittstellenerwartungen mit Datenbankregeln. Durch die Konfiguration von Beziehungen, Indizes und Parallelität wird der Vertrag bewusst überprüfbar gemacht, anstatt ihn versehentlichen Standardeinstellungen zu überlassen.

Schauen Sie sich die Fehler an, die das Schema verhindern muss: eine nicht indizierte Warteschlangensuche, zwei Agenten, die ein Ticket überschreiben, und eine manuell gepatchte Datenbank, die von der nächsten Version abweicht. Jedes Problem erfordert ein anderes Modell oder eine andere Migrationsentscheidung.

Halten Sie das Ticket im Mittelpunkt der Entitätsbeziehungen, mit kleinen Suchentitäten und Kommentaren als Detail. Der optionale Agent- und Versionswert hat unterschiedliche Bedeutungen. Verwenden Sie ein separates flaches Listenelement für das Raster, anstatt das gesamte Diagramm anzuzeigen.

Verwenden Sie einfache Anmerkungen, sofern diese ausreichend sind, und erfassen Sie die Konfiguration der Produktivdatenbank in OnModelCreating. Die fließende Konfiguration drückt Längen, erforderliche Werte, Indizes, Genauigkeit, Standardwerte und Beziehungsverhalten zusammen aus und hält Datenbankzuordnungsentscheidungen nah am Context.

Erfordern Sie einen begrenzten Titel und konfigurieren Sie RowVersion für Parallelität. Erstellen Sie Indizes rund um die von der Anwendung tatsächlich durchgeführten Suchvorgänge, einschließlich Status und Fälligkeitsdatum. Durch das explizite Löschverhalten wird die Auswirkung auf verwandte Datensätze zu einer überprüften Entscheidung und nicht zu einer Überraschung.

Das Update stimmt sowohl mit der Ticket-ID als auch mit der ursprünglich gelesenen Version überein. Wenn ein anderer Agent diese Version geändert hat, stimmt keine Zeile überein. Entity Framework meldet einen Parallelitätskonflikt, der es der Anwendung ermöglicht, den Konflikt zu erklären, anstatt stillschweigend die Arbeit einer anderen Person zu ersetzen.

Überprüfen Sie eine Migration wie jede andere Quelländerung, bevor Sie sie anwenden. Die Entwicklung kann die überprüfte Migration direkt anwenden; Der Produktivbetrieb erhält ein genehmigtes wiederholbares Skript oder Paket. Dadurch bleiben Schemaänderungen an die Release-Überprüfung gebunden, anstatt mehrere Anwendungsinstanzen beim Start zu überrennen.

Geben Sie der Design-Time-Factory denselben Anbieter mit einer sicheren lokalen Entwicklungsverbindung. Migrationstools können das Modell dann erstellen, ohne Wisej.NET zu starten. Durch die Trennung dieses Pfads wird die Schemagenerierung unabhängig vom Startverhalten der Anwendung zur Laufzeit.

Generieren Sie InitialCreate, überprüfen Sie die geplanten Änderungen und wenden Sie sie dann an, um die Tabellen, Versionsspalten und Indizes zu erstellen. Durchsuchen Sie einen kurzlebigen Context. Die resultierenden Beispielkunden, Agenten, Kategorien und Tickets bieten späteren Bindungsstunden eine konsistente Datenbank zur Verwendung.

Stellen Sie die fünf zugehörigen Entitäten mit expliziten Löschregeln, den geplanten Indizes und RowVersion bereit. Fügen Sie die Design-Time-Factory und die überprüfte anfängliche Migration hinzu und setzen Sie dann die Entwicklungsdatenbank ein. Durch die Abgabe sollte nachgewiesen werden, dass das Modell und das generierte Schema übereinstimmen.

Erstellen Sie einen Ticketbrowser, der asynchron lädt und seine Ergebnisse über BindingSource bindet. Der Bildschirm benötigt zur Anzeige eine stabile Liste, während der Abfragedienst nur eine kurze Datenbankoperation benötigt. Durch die Trennung dieser Verantwortlichkeiten bleibt der Schnittstellenstatus unabhängig vom Context.

Wählen Sie nur die Felder aus, die von den sieben Rasterspalten in TicketListItem benötigt werden. Eine No-Tracking-Projektion gibt weniger Daten zurück und vermeidet die Beibehaltung eines bearbeitbaren Entitätsdiagramms. Die Browserliste kann dann den Abfragekontext überdauern, ohne Teil der Arbeit des Editors zu werden.

Verfassen Sie die Abfrage, bevor Sie sie ausführen: Fügen Sie Filter, Reihenfolge, Seitengrenzen und Projektion hinzu. ToListAsync materialisiert dann einmalig die angeforderten Ergebnisse. Dies überlässt der Datenbank die Filter- und Paging-Arbeit, anstatt alles zu laden und in der Benutzeroberfläche zu beschneiden.

Erstellen Sie in TicketQueryService einen Context und fügen Sie nur die vom Benutzer ausgewählten Filter hinzu. Zählen Sie die Übereinstimmungen und rufen Sie dann die projizierte Seite ab. Die Abfrage bleibt bis zu den asynchronen Ausführungspunkten eine Beschreibung, wodurch ihre Datenbankarbeit in der Methode explizit erfolgt.

Binden Sie die materialisierte Liste an BindingSource und binden Sie das Raster an diese Quelle. Geben Sie dem Grid keinen Live-Datenbanksatz. Laden Sie Suchoptionen vor der ersten Suche und unterscheiden Sie deren angezeigten Text von dem als ausgewählten Wert gespeicherten Schlüssel.

Die Seite koordiniert die Benutzererfahrung rund um einen erwarteten Serviceanruf. Stellen Sie den Ladeschutz ein, deaktivieren Sie Befehle und zeigen Sie den Status vor dem Laden an. Weisen Sie die zurückgegebene Liste zu und stellen Sie dann die Steuerelemente in finally wieder her, sodass sowohl bei Erfolg als auch bei Misserfolg eine verwendbare Seite entsteht.

Suchen Sie nach Text und Status und vergleichen Sie dann die fünfzig sichtbaren Zeilen mit der Gesamtzahl der Übereinstimmungen. „Nächste Seite“ führt eine weitere Abfrage mit einer neuen Seitengrenze durch. Nur projizierte Ergebnisse erreichen den Browser; Der Server überträgt den zugrunde liegenden Entitätsgraphen nicht.

Testen Sie den Pfad zum nicht erreichbaren Server bewusst. Der Bediener sollte eine nützliche Nachricht erhalten und die Suche nach der Bereinigung wieder aufnehmen. Bei einem späteren Versuch wird ein neuer Context erstellt, sodass bei einem fehlgeschlagenen Vorgang der Bildschirm nicht an ein fehlgeschlagenes Datenbankobjekt gebunden bleibt.

Stellen Sie den Browser mit Listenmodell, Suchkriterien, Abfragedienst und gebundenem Raster bereit. Laden Sie zuerst Suchvorgänge und schließen Sie Such-, Vorwärts- und Rückwärts-Paging in die Gesamtzahl ein. Überprüfen Sie Ladeschutz und Wiederherstellung als Teil desselben Arbeitsablaufs.

Verwandeln Sie den Ticketdialog in eine sichere Bearbeitungsgrenze. Der Benutzer erhält die vertrauten Befehle „Speichern“, „Abbrechen“ und „Löschen“, während der Server steuert, wann Eingaben das Modell erreichen und wann Entity Framework sie schreibt. Die modale Form sollte nicht zu einem dauerhaften Datenbankkontext werden.

Setzen Sie vor dem Speichern oder Löschen den Teil des Serververtrags durch: Schließen Sie ausstehende Änderungen ab, erstellen Sie einen neuen Context für den Vorgang und verhindern Sie doppelte Übermittlungen. Ein vertrauter Dialog ist nur dann zuverlässig, wenn diese versteckten Schritte mit dem übereinstimmen, was die Schaltflächen versprechen.

Verbinden Sie die Steuerelemente über BindingSource mit TicketEditModel und wählen Sie aus, wann jeder Wert aktualisiert wird. Text und Datumsaktualisierung bei Validierung; Suchvorgänge werden aktualisiert, wenn sich ihre Eigenschaften ändern. BindingSource-Bearbeitungsmethoden verwalten das aktuelle Element, aber keine davon ersetzt eine Datenbankspeicherung.

Wählen Sie die Bindungsgrenze entsprechend den Verantwortlichkeiten des Herausgebers. Die direkte Entitätsbindung kann für ein kurzlebiges Aggregat mit einem privaten Context geeignet sein. Ein Bearbeitungsmodell macht die Validierung und erlaubte Teilaktualisierungen explizit und vermeidet die Behandlung einer schreibgeschützten Rasterprojektion als bearbeitbare Einheit.

Befolgen Sie eine Speichersequenz: überwachen, Bearbeitungen abschließen, validieren, laden oder mit einem neuen Context erstellen, zulässige Werte zuordnen und speichern. Erfolgreiches Schließen erst nach erfolgreicher Persistenz. Behandeln Sie Parallelität getrennt von anderen Datenbankfehlern, damit der Benutzer die richtige Erklärung erhält.

Überprüfen Sie in SaveAsync die Reihenfolge und nicht nur die Methodennamen. EndEdit muss vor der Validierung erfolgen; Die Kontexterstellung folgt der akzeptierten Eingabe. Das Laden per Schlüssel und die Zuordnung aus dem Bearbeitungsmodell definieren, was geschrieben wird, während finally den Speicherschutz bei jedem Verlassen freigibt.

Das Löschen beginnt mit der Bestätigung und lädt das Ticket dann per Schlüssel in einem neuen Context neu. Wenn es bereits verschwunden ist, erklären Sie dies, anstatt es als normale Entfernung zu betrachten. Überprüfen Sie die Geschäftsregel, bevor Sie den Datensatz entfernen und speichern.

Ändern Sie den Titel und die Dringlichkeit im modalen Editor und speichern Sie dann. Der Besetztzustand deckt die Persistenz ab und ein erfolgreiches Dialogergebnis schließt den Editor. Der übergeordnete Browser führt eine erneute Suche durch, daher basiert die angezeigte Zeile auf dem gespeicherten Datenbankstatus und nicht auf Annahmen über die Bearbeitung.

Erstellen Sie Formulare zum Hinzufügen und Bearbeiten rund um TicketEditModel, BindingSource und ErrorProvider. Dazu gehören das Laden, das geschützte Speichern, das bestätigte Löschen und die übergeordnete Aktualisierung. Stellen Sie sicher, dass das Abbrechen einer Bearbeitung und der Abschluss eines erfolgreichen Speicherns unterschiedliche, vorhersehbare Auswirkungen auf den Browser haben.

Fügen Sie eine Validierung hinzu, bevor der Ticketeditor die Datenbank erreicht. Benutzer benötigen eine Erklärung, auf die sie reagieren können, während der Server noch abschließende Konsistenzprüfungen benötigt. Dieses Modul verbindet Modellregeln, Feldfeedback und Datenbankfehlerbehandlung in einem verständlichen Speichererlebnis.

Behalten Sie alle drei Validierungsebenen bei, da sie unterschiedliche Grenzen schützen. Schnittstellenprüfungen bieten sofortige Orientierung, Domänenregeln gelten auch außerhalb dieser Form und Datenbankeinschränkungen schützen die endgültige Konsistenz. Das Bestehen der ersten Schicht macht die anderen nicht überflüssig.

Gehen Sie nicht davon aus, dass SaveChangesAsync die Anmerkungen des Bearbeitungsmodells ausführt. Das Required-Attribut hilft bei der Beschreibung der Zuordnung für eine Entität, aber das Eingabemodell benötigt einen expliziten Validierungsaufruf. TryValidateObject ist der Schritt, der diese deklarierten Regeln in tatsächliche Prüfungen umwandelt.

TicketValidator gibt Feldnamen und Meldungen zurück, nachdem Anmerkungen und die Closed-Ticket-Regel ausgeführt wurden. Es besteht keine Abhängigkeit von den Wisej.NET-Steuerelementen, sodass negative Fälle getestet werden können, ohne ein Formular zu öffnen. Die Schnittstelle entscheidet später, wo jedes Ergebnis angezeigt wird.

Löschen Sie altes Feedback, beenden Sie die Bearbeitung und validieren Sie das aktuelle Modell, bevor Sie einen Context erstellen. Leiten Sie jedes Ergebnis an seine Eingabe und auch an die Zusammenfassung weiter. Durch die Rückkehr an diesem Punkt wird verhindert, dass ungültige Daten einen unnötigen Datenbankvorgang starten.

Halten Sie Validierung und Ausnahmebehandlung in der richtigen Reihenfolge. Vor dem Speichern wird eine ungültige Eingabe zurückgegeben. Eine Parallelitätsausnahme wird vor umfassenderen Datenbankausnahmen abgefangen. Protokollieren Sie technische Details auf dem Server, aktualisieren Sie die Suchvorgänge bei Bedarf und stellen Sie die Speicherung stets in finally wieder her.

Kombinieren Sie einen leeren Titel mit einem zukünftigen Fälligkeitsdatum auf einem geschlossenen Ticket. Beide Eingaben sollten nützliches Feedback erhalten und in der Zusammenfassung erscheinen, während „Speichern“ weiterhin nicht verfügbar ist. Korrigieren Sie beide Werte, um zu bestätigen, dass das Löschen von Fehlern der aktuellen Gültigkeit des Modells entspricht.

Ein gültiges Eingabemodell kann immer noch fehlschlagen, wenn ein anderer Agent dieselbe Ticketnummer erstellt. Der eindeutige Index lehnt das Duplikat beim Speichern ab. Übersetzen Sie diesen Fehler in eine klare Erklärung für den Benutzer und behalten Sie die Datenbankdetails nur im Diagnoseprotokoll bei.

Stellen Sie das kommentierte Bearbeitungsmodell, den unabhängigen Validator, das Feld-Feedback und die Zusammenfassung zusammen bereit. Fügen Sie die Übersetzung doppelter Nummern hinzu und lassen Sie „Speichern“ für ungültige Eingaben deaktiviert. Die fünf negativen Tests sollten die Regeln direkt umsetzen und beweisen, dass sie nicht von einer sichtbaren Form abhängen.

Verwenden Sie den langsamen Ticketbrowser, um zu messen, was die Datenbank tatsächlich tut. Das Ziel ist eine projizierte, ausgelagerte Abfrage mit Beweisen aus dem Protokoll. Der Vergleich derselben Suche vorher und nachher zeigt, ob die Verbesserung eher auf weniger Arbeit als auf einen visuellen Eindruck zurückzuführen ist.

Die Zellformatierung sieht harmlos aus, bis das Lesen einer Navigationseigenschaft ein verzögertes Laden auslöst. Auf die erste Ticketabfrage folgen Abfragen zugehöriger Daten für jede Zeile. Zählen Sie diese Anweisungen, um herauszufinden, warum die Anzeige von fünfzig Zeilen einhunderteinundfünfzig Datenbankbefehle erzeugen kann.

Wählen Sie das Laden verwandter Daten entsprechend dem von Ihnen benötigten Ergebnis. Die Projektion passt auf ein Flachdisplaymodell. Include passt zu einem kontrollierten Aggregat, gegebenenfalls mit Filterung oder explizitem Laden. Vermeiden Sie einen verzögerten Navigationszugriff im Raster, da die Datenbankkosten im Präsentationscode verborgen sind.

Verwenden Sie Tracking, wenn der Editor dieselben Entitätsinstanzen speichert. Für schreibgeschützte Listen, Suchvorgänge, Exporte und Dashboards ist dies im Allgemeinen nicht erforderlich. Die Identitätsauflösung ist eine separate Wahl für ein schreibgeschütztes Diagramm, das dennoch eine Instanz für jede wiederholte Entität benötigt.

Filtern Sie nach indizierten Spalten, zählen Sie die Übereinstimmungen und rufen Sie eine Seite mit fünfzig projizierten Listenelementen ab. Durch die Auswahl verwandter Namen in der Abfrage werden diese von der Datenbank einmalig verknüpft. Beim Formatieren der zurückgegebenen Zeilen werden dann verfügbare Werte verwendet, anstatt zusätzliche Datenbanklesevorgänge zu verursachen.

Aktivieren Sie die Befehlsprotokollierung in der Entwicklung, bevor Sie eine Optimierung auswählen. Untersuchen Sie die Anzahl und Dauer der Befehle, um den Engpass zu lokalisieren. Kompilierte Abfragen, Pooling, geteilte Abfragen oder unformatierte Datenbankanweisungen sollten einen gemessenen Bedarf ansprechen und nicht die Komplexität erhöhen, bevor die gewöhnliche Abfrage verstanden wird.

Vergleichen Sie die aufgezeichneten Suchanfragen: Aus einhunderteinundfünfzig Suchanfragen werden zwei, wobei die Gesamtzahl immer noch vorhanden ist. Die gemessene Dauer sinkt auf achtunddreißig Millisekunden. Suche und Paging bleiben während des Ladens deaktiviert, sodass der schnellere Datenbankpfad auch ein koordiniertes Schnittstellenverhalten beibehält.

Warten Sie eine Operation ab, bevor Sie eine andere im selben Context starten. Für längere Hintergrundaufgaben erstellen Sie den Context in Application.StartTask und melden Sie den Fortschritt über Application.Update. Durch die lokale Beherrschung der Aufgabe wird vermieden, dass ein Context über gleichzeitige Schnittstellen- und Hintergrundvorgänge hinweg geteilt wird.

Notieren Sie die ursprünglichen Befehle und die Dauer und ersetzen Sie dann die Rasterabfrage durch eine No-Tracking-Projektion und fünfzig Zeilen Seiten. Entfernen Sie verzögerte Navigationslesevorgänge aus dem Präsentationscode. Ihre Vorher-Nachher-Notiz sollte die gemessene Verbesserung mit der entfallenden Datenbankarbeit in Verbindung bringen.

Beenden Sie die Support Desk-Konsole, indem Sie in verschiedenen Sitzungen vorgenommene Änderungen schützen. Da zwei Bediener dasselbe Ticket öffnen können, darf ein erfolgreiches Speichern nicht stillschweigend eine Änderung löschen, die seit dem Laden des Editors vorgenommen wurde. Das Abschlussprojekt verbindet diesen Schutz mit Bereitstellung und Diagnose.

Dana schließt das Ticket, während Priya noch eine ältere Bearbeitung offen hat. Durch das Speichern der Prioritätsänderung von Priya ohne Überprüfung der Originalversion könnte der alte Status wiederhergestellt werden. RowVersion erkennt, dass sich der Datensatz geändert hat, und verwandelt ein stilles Überschreiben in einen expliziten Konflikt.

Bewahren Sie in TicketEditModel die Version auf, die der Benutzer tatsächlich gesehen hat. Weisen Sie diese mitgeführte Version beim Speichern mit einer frisch geladenen Entität als ursprünglichen Wert zu. Andernfalls würde der Context mit seiner gerade neu gelesenen Version vergleichen und Änderungen übersehen, die während der Bearbeitung entstanden sind.

Fangen Sie nach der Wiederherstellung der Originalversion die Parallelitätsausnahme ab und überprüfen Sie jeden betroffenen Eintrag. Lesen Sie die aktuellen Datenbankwerte, um die Konfliktliste zu erstellen. Eine fehlende Datenbankzeile bedeutet Löschung. Vergleichen Sie unterschiedliche Eigenschaften, damit der Dialog die tatsächliche Kollision erklären kann.

Stellen Sie den Konflikt anhand der Feldnamen sowie der Benutzer-, Datenbank- und Originalwerte dar. Reload übernimmt aktuelle Datenbankdaten; Für das Überschreiben ist eine Richtlinienerlaubnis erforderlich, während für das Zusammenführen je Feld entschieden wird. Aktualisieren Sie nach der Auflösung das Raster, sodass der umgebende Bildschirm mit dem gewählten Ergebnis übereinstimmt.

Ein SaveChangesAsync stellt bereits eine Transaktion für seine Änderungen bereit. Verwenden Sie eine explizite Transaktion, wenn mehrere Vorgänge gemeinsam erfolgreich sein müssen. Wenn die Wiederholung aktiviert ist, platzieren Sie die gesamte Einheit in der Ausführungsstrategie, sodass bei einer Wiederholung die gesamte Transaktion wiederholt wird und nicht nur ein isoliertes Fragment.

Halten Sie Verbindungsgeheimnisse des Produktivbetriebs außerhalb des Quellcodes und stellen Sie überprüfte, wiederholbare Migrationen während der Veröffentlichung bereit. Deaktivieren Sie die Protokollierung vertraulicher Daten außerhalb der Entwicklung. Testen Sie Dienste unabhängig von der Schnittstelle mithilfe einer relationalen Datenbank, bei der das zu testende Verhalten von relationalen Regeln abhängt.

Führen Sie die Zwei-Sitzungs-Kollision aus: Dana speichert zuerst, dann sieht Priya den widersprüchlichen Status und die Priorität neben den Datenbankwerten. Wenn Sie „Neu laden“ wählen, wird die Version des Editors aktualisiert und das Raster aktualisiert. Das sichtbare Ergebnis zeigt, dass die veraltete Speicherung gestoppt und nicht stillschweigend akzeptiert wurde.

Überprüfen Sie die Konsole als ein verbundenes System: projizierter Browser, Laden von Lookups, Bearbeitungsmodell, Feedback, Schutzprüfungen und Versionsprüfung. Der Migrationsplan und der Architekturhinweis erläutern, wie es wartbar bleibt. Die Bewertung belohnt Architektur, Bindung und Entity Framework-Korrektheit zusammen.

Reichen Sie einen reproduzierbaren Konflikt zwischen zwei Sitzungen ein. Die ursprünglich gelesene Version muss bis zum Speichern mitgeführt werden, und ein verständlicher Dialog muss die Auflösung ermöglichen. Ergänzen Sie Bereitstellungshinweise, das geprüfte Migrationsskript und sichere Protokollierungseinstellungen. Bei der Abschlussprüfung müssen sich der Konflikt und seine Auflösung wiederholen lassen.