Dieser Artikel wurde maschinell übersetzt.

Innovation

Objekte Und Die Kunst der Datenmodellierung

Dino Esposito

 

Viele der heutigen Anwendungen basieren auf ein einzelnes Datenmodell in der Regel in einem Datenspeicher über ein Tool objektrelationale Mapper (ORM) beibehalten. Aber manchmal – für mehrere unterschiedliche Gründe haben – möglicherweise mehr Flexibilität, die mehrere Modelle erfordert. In diesem Artikel werde ich einige Strategien erläutern, Sie behandeln dieser Situationen und weitere Ebenen und robusten Anwendungen entwickeln können.

Mit Verschiedene Modellen Deutlich Macht Die Gesamte Anwendung Komplizierter, Aber es ist Eine Art der the, positive Komplexität, Die Das Gesamte Projekt Leichter Macht. Verstehen, Wenn Ein Modell der Daten Nur Alle Anwendungsfälle Passt, ist Die Herausforderung Für Architekten.

Verschiedene Teile Einer Softwareanwendung zeigt Ihr Eigenes Modell der Daten. Die Weise, in der Sie Daten Auf der Ebene der Benutzeroberfläche Darstellen, Unterscheidet Sich von der Weise Organisieren von Daten in der Mittleren Ebene, Und zeigt Sogar Unterscheidet, Wie die Daten Physisch in Some Datenspeicher Beibehalten Werden.

Aber Seit Vielen Jahren das Entwickler Nur Ein Modell von Daten, Unabhängig von der Teil der Beteiligten Anwendung Verwendet. Viele von Uns Sind Mit relationalen Datenbanken Und Deren Zugehörige Modellierungstechniken Gewachsen. Es War Natürlich Viel Aufwand Bei der Ausarbeitung Eines Modelle Auf der Grundlage von Beziehungen Und Regeln Für die Normalisierung Zu Verbringen. Alle Daten in Einer relationalen Datenbank Gespeichert Wurde, Then Stored Und Mit Speicherstrukturen, Die Ähnlich Wie Eine in-Memory-Datenbank Verschoben. Datensatz ist der Name Dieses Generische Datenzugriffs-Muster (See bit.ly/nQnyaf); die ADO.NET-DataSet Wurde Eine Ausgezeichnete Implementierung.

Der Table-Ansatz Wurde Schrittweise Durch Die Zunehmende Komplexität von Anwendungen Zur Ecke Abgelegt. ORM-Tools Entstand aus Zwei Hauptgründen Pragmatisch. Arbeiten Mit Objekten ist Zunächst Einfacher Umgang Mit Generischen Super-arrays Wie Z. B. Einem Recordset. Der Zweite Grund ist Die Produktivität. Das Ziel von Einem ORM Nimmt Ein Objektmodell Und Ein Relationales Schema Zuordnen. Mit Einem ORM, Stellen Sie Im Wesentlichen Das Objektmodell der Echten Datenbank Für die Anwendung Augen Aussehen.

Wie Gestalten Sie Dieses Modell? Und Sie Wirklich Nur Ein Modell Für Jede Anwendung-Sollte? Genau Darum Geht es Hier.

Ein Modell Passt Immer Alle nicht

Die Aktuelle Version von Entity Framework (EF) 4.1 Enthalten Support Für "Code Zuerst" Programmieren, Die Wie der Name Schon Sagt, Können Microsoft.NET Framework-Entwickler Nehmen Eine Code-First-Ansatz Für Die Datenmodellierung. Dies Bedeutet Im Grunde, Dass Sie Beginnen, Indem Sie Beim Schreiben der Plain Old CLR Object (POCO)-Klassen, Die Die Domäne der Anwendung Zu Modellieren. Der Zweite Schritt Besteht Darin, das Zuordnen Dieser Klassen Zu Einem permanenten Speicher Und Müssen Das ORM-Tool (EF) Kümmern Persistenz-Details. Das ORM Stellt Eine Abfragesprache (LINQ to Entities), Transaktionale Semantik (Die XxxContext-Objekte in der EF) Und Eine Grundlegende Erstellen, Lesen, Aktualisieren Und Löschen (CRUD) API, die Parallelität, lazy Loading and Fetch Unterstützt Pläne.

In diesem Fall Haben Sie Das Modell, Und Sie Wissen, Wie es Beibehalten Werden Und Abfragen von Informationen aus. Dies ist Ein Modell, Das Sie Überall in Ihrer Anwendung Verwenden Können? Stirbt ist Genauer Gesagt, Ein Modell, Das Sie der Präsentationsschicht Effektiv Bringen Kann? Dies ist Ein Wirklich Wunder Punkt, wo Theorie Und Praxis Unterscheiden Sich Grundlegend Context is König Und Die Unsicherheit (Bei Nicht Wirklich Verwirrung) Herrscht. Lassen Sie mich Ein Konkretes Beispiel einer Die Beliebten ASP Gebunden finden.NET MVC-Technologie. Der Einzige Grund, Ich Bin Mit, Dass ASP.NET MVC Anstelle von Silverlight Sagen, ist, Dass ASP.NET MVC Hat Das Wort "Modell" Im Namen (Die m in MVC) – Und Ich Wurden Gebeten Zu Viele Male in Klassen Und Konferenzen Über Die Genaue Lage der "Model" in Einer ASP.NET MVC-Anwendung.

Heute, Auch Nach Drei Versionen, Zu Viele Tutorials Auf ASP.NET MVC Bestehen Auf Nur Ein Modell Für Abfragen, Aktualisierungen Und Präsentation Verwenden. Viele Tutorials Halten Auch Die Definition des Modelle Innerhalb des Hauptprojekts. Es Funktioniert, auch 's wo Das Problem? Das Problem ist Nicht Mit der Lösung, die Funktioniert, ist Effektiv Und ist Etwas, Ich Habe mich oft Verwendet Und Weiterhin Verwenden Möchten. Es ist Eigentlich Eine Reihe von realen, Aber Einfach Und Relativ Kurzlebige Anwendungen (Nicht Nur Demos Und Tutorials),, die Mit Einfacher Muster Entwickelt. Das Problem der Verwendung von Nur Einem Modell ist Mit der Nachricht, Die es, um die Primären Consumer von Tutorials Überträgt: Entwickler, die um Eine Technologie Vertraut Zu Machen. Mit Nur Einem Modell ein Einer Stelle Vorschlägt, ist der Bevorzugte (Nicht Recommended) Weg, Dinge Zu Tun. Es ist Dagegen Nur Ein Spezialfall – Ein Szenario Sehr Einfach Und Günstig. Wenn Tatsächlich you in Productive realen Szenarios Entspricht, Können Sie Mehr als Gut. You are Andernfalls stecken Und Bereit, Ihre Erste "big Ball Schlamm" Wachsen größer Und größer.

Eine Weitere Allgemeine Architektur

Beginnen Wir Mit Geringfügig Unterschiedliche Namen. Nennen Wir Das Modell der Daten, die Das Domänenmodell Beibehalten Und Rufen Sie Die Daten you Verwalten in der Ansicht, Das Modell Anzeigen. Ich Möchte Diesem Domänenmodell Genau Einen neutralen Begriff in der Software ist Nicht Auf Eine Entsprechend Einer Reihe von Zusätzlichen Regeln Entworfene Objektmodell Verweist, Erwähnen. In Den Anwendungsbereich Dieses Artikels Verwende Nicht Die Bedeutung Ich die Ergebnis der Methodik-Driven Design (DDD). Für mich Hier Das Domänenmodell ist Einfach Das Objektmodell, die Sie Beibehalten –Entity Model zeigt Eine Andere Entsprechung – Und Weniger Verwirrend – Begriff.

Sie Verwenden Die Klassen Im Entitätsmodell Im Back-End der Anwendung; Sie Verwenden Die Klassen Im Ansichtsmodell in der Darstellungsschicht. Beachten Sie Jedoch, Dass in ASP.NET MVC ist die Darstellungsschicht der Controller. Der Controller erhalten Daten für die Benutzeroberfläche bereit. Die Komponenten der mittleren Ebene erhalten und Modell Ansichtsobjekte zurückzugeben und Entitätsobjekte intern verwenden. Abbildung 1 im Web von Abhängigkeiten in einem typischen mehrschichtige Projekt zeigt.

Abbildung 1-Verbindungen zwischen den Schichten

Die Präsentation (d. h. die Codebehind oder Controller-Klasse) verweist auf die Anwendungslogik, nämlich eine Komponente, die der Anwendung implementiert. Die Anwendungslogik technisch gehört zur Business Layer oder Ebenen und in sehr einfachen Fällen kann mit der Präsentation zusammengeführt werden. Dies geschieht in einigen Lernprogramme, die zu einfach, wirklich das Gefühl, der Notwendigkeit der Anwendungslogik in einer eigenen Ebene isolieren oder schlecht konzipiert sind und zwischen der Präsentation und der Datenzugriffsebene (DAL) aufteilen Anwendungslogik.

Die Anwendungsassembly Logik implementiert das Muster des Service-Ebene und entkoppelt die zwei Ebenen der Schnittstelle: Präsentation und Daten. Die Anwendungslogik verweist auf das Entitätsmodell (Domäne Klassen) und der DAL. Die Anwendungslogik koordiniert DAL, Domain-Klassen und Dienste, das erwartete Verhalten zu verfolgen. Die Anwendungslogik kommuniziert mit der Darstellungsschicht über Modell Ansichtsobjekte und kommuniziert mit der DAL durch Domain-Objekte. Die DAL wiederum verweist auf das Modell und die ORM-Assembly.

Ein paar Worte zu Entitätsframework

Betrachten Sie diese Architektur, EF als die ORM vorausgesetzt. EF ist nicht einfach ein ORM, aber wie der Name andeutet, es funktioniert die typische von einem ORM plus bietet ein Framework zum Erstellen eines Modells. Nette Idee, aber es sollte nicht vergessen werden, dass wir zwei unterschiedliche Ebenen hineinragen sind – Business und der DAL. Die Klassen sind Business; die Persistenz-Engine ist der DAL. Für die EF ist die Persistenz-Engine (die ORM-Assembly) system.data.entity und seine Abhängigkeiten, einschließlich der ObjectContext-Klasse. Anders ausgedrückt, außer bei Verwendung von POCO Klassen und Code erste, werden Sie wahrscheinlich am Ende mit einem Domänenmodell mit die Abhängigkeit auf der ORM. Ein Domänenmodell sollten POCO verwenden – das heißt, unter anderem, sollte es eine eigenständige Assembly. Eine interessante Threads zu diesem Thema existiert auf Stapelüberlauf bei bit.ly/mUs6cv. Weitere Informationen zum Teilen Entitäten aus Kontext in der EF finden Sie unter ADO.NET-Team-Blog-Einträge, "Exemplarische Vorgehensweise: POCO Vorlage für die Entity Framework" (bit.ly/bDcUoN) und "EF 4.1 Modell & Datenbank der ersten exemplarischen Vorgehensweise"(bit.ly/hufcWN).

Aus dieser Analyse scheint es POCO-Attribut ist für die Domäne Klassen. POCO, gibt natürlich eine Klasse außerhalb der eigenen Assembly ohne Abhängigkeiten. POCO über Einfachheit ist, und es ist nie falsch. Das bedeutet, dass Formulare für enge Kopplung zwischen Ebenen Sie POCO Weg geht nicht. Enge Kopplung ist nicht giftig und doesn't kill sofort, aber es dauert das Projekt einen langsamen Tod. Check out meiner Kolumne über Software Katastrophen im letzten Monat (msdn.microsoft.com/magazine/hh394145).

Was ist das Modell?

Wenn Sie ein Objektmodell erstellen, erstellen Sie eine Bibliothek von Klassen. Sie können Ihr Objektmodell einer Reihe von Mustern zufolge organisieren, aber im Prinzip kristallisieren sich die Wahl zwischen einer Tabelle-orientierten Ansatz und einen objektorientierten Ansatz.

Wie entwickeln Sie Ihre Klassen? Welche Funktionen sollten sie Funktion? Insbesondere sollten die Klassen der Datenbank beachten? Diese Logik (d. h. Methoden) oder werden zum Verfügbarmachen von Eigenschaften nur begrenzt? Es gibt zwei wichtigsten Muster finden Sie in: aktiven Datensatz und Domain-Modell.

In das Muster Active Datensatz werden Klassen genau nach Datenbanktabellen modelliert. Sie haben meist eine Klasse pro Tabelle und eine Eigenschaft pro Spalte. Noch wichtiger ist, sind die Klassen für ihre eigenen Persistenz- und ihre eigenen einfachen, minimale Domänenlogik verantwortlich.

Gemäß dem Muster Domänenmodell sind Klassen sollen eine konzeptuelle Übersicht über das Problem Domain. Diese Klassen haben keine Beziehungen mit der Datenbank und Eigenschaften und Methoden. Schließlich sind diese Klassen nicht verantwortlich für ihre eigenen Persistenz. Wenn Sie für ein Domänenmodell Ansatz entscheiden, muss Persistenz delegiert werden, um eine eigene Schicht – die DAL. Diese Schicht selbst schreiben, aber wäre es nicht viel Spaß. Eine gelungenes DAL für eine Bibliothek, die gemäß dem Domänenmodell Muster entworfen ist fast identisch mit ORM-Tool. So verwenden Warum nicht eines der vorhandenen ORM-Tools?

Vor allem, wenn Sie den automatische Code-Generator verwenden, wird die EF vorgenommenen ein Objektmodell von Klassen, die nur Eigenschaften verfügen. Das Muster ist sicherlich nicht aktiven Datensatz, aber Klassen verfügen standardmäßig über keine Methoden. Glücklicherweise werden Klassen als teilweise markiert die ermöglicht es Ihnen, bis ein viel umfangreicheres Domänenmodell Form durch Hinzufügen von Logik durch partielle Klassen. Wenn Sie den Code ersten Ansatz wählen, sind Sie vollständig verantwortlich für den Quellcode der Klassen von Anfang bis Ende zu schreiben.

Klassen in einem Objektmodell, die oft nur KE-Eigenschaften werden als ein anämischen Domänenmodell bezeichnet.

Repositories

Eine gute Praxis, die wohlverdienten Popularität wird Datenzugriffscode in Fassade Klassen bekannt als Repositories umbrochen. Ein Repository besteht aus einer Schnittstelle und eine Implementierungsklasse. Sie haben in der Regel ein Repository für jede erhebliche Klasse im Objektmodell. Eine wichtige Klasse in einem Objektmodell ist eine Klasse, die eine eigene Dauerhaftigkeit steuert und steht auf eigenen in der Domäne ohne abhängig von anderen Klassen. Im Allgemeinen ist eine wichtige Klasse, z. B. Kunde OrderDetails ist nicht, weil Sie einen Auftrag immer Bestelldetails verwenden. In DDD wird eine wichtige Klasse als ein Aggregat Root bezeichnet.

Um das Design zu verbessern, können Sie eine Abhängigkeit zwischen Anwendungslogik und die DAL über Schnittstellen Repository herstellen. Aktuelle Repositories können dann in der Anwendungslogik entsprechend injiziert werden. Abbildung 2 zeigt die resultierende Architektur, wo die DAL Repositories basiert.

Abbildung 2 Verwenden von Repositories in der DAL

Repositories aktivieren Dependency Injection in der DAL auf, weil können leicht trennen Sie das aktuelle Modul, das Persistenzlogik bereitstellt und es mit Ihren eigenen ersetzen. Dies ist sicherlich nützlich für Testfähigkeit, aber nicht beschränkt auf, ist. Eine Architektur, die auf der Grundlage von Repositories ermöglicht Objektmocks DAL und testen die Anwendungslogik in Isolation.

Repositories stellen auch einen hervorragenden Erweiterungspunkt für Ihre Anwendungen dar. Ersetzen Sie das Repository, können Sie die Persistenz-Engine in einer Weise ersetzen, die für den Rest der Ebenen transparent ist. Der Punkt hier ist nicht so viel über den Wechsel von, sagen, SQL Server, Oracle, weil dieses Maß an Flexibilität von ORM-Tools bereitgestellt werden. Der Punkt hier wird aus der aktuellen Implementierung der DAL auf etwas anderes, wie eine Wolke API, Dynamics CRM, eine Lösung für NoSQL und dergleichen wechseln können.

Welche Repositories nicht sein sollten

Ein Repository ist Teil der DAL. Es soll als solche nicht die Anwendungslogik kennen. Dies ist möglicherweise zu offensichtlich eine Anweisung, aber eines Diagrammtyps Architektur sehe ich ziemlich oft in diesen Tagen basiert auf Präsentation und Repositories.

Die eigentliche Logik ist dünn und einfache – oder ist im wesentlichen CRUD – dieses Diagramm mehr als OK ist. Aber was passiert, wenn das ist nicht der Fall? Wenn dies der Fall ist, benötigen Sie auf jeden Fall einen Platz in der Mitte, wo Sie die Anwendungslogik bereitstellen. Und glauben Sie mir, ich habe gesehen, dass nur wenige Anwendungen, die gerade CRUD in meiner Karriere sind. Aber ich bin wahrscheinlich einfach nicht … ein glücklicher Mann

Klärung der Verschleierung

Abschließen, neigen Anwendungen heute um ein Modell von Daten entworfen werden, die dann ein ORM-Tool einige Datenspeicher erhalten bleibt. Das ist gut für die Back-End der Anwendung, aber nicht allzu überrascht sein, wenn die Benutzeroberfläche erfordert, Sie dass Umgang mit signifikant unterschiedlichen Aggregate von Daten, die nicht nur im ursprünglichen Modell vorhanden sind. Diese neuen Datentypen, die für den alleinigen Zweck der Benutzeroberfläche vorhanden sind, müssen erstellt werden. Und sie bilden ein Objektmodell vollständig parallel am Ende: das Modell anzeigen. Wenn Sie reduzieren diese beiden Modelle auf nur ein, dann mit allen Mitteln Stick, und glücklich. Wenn dies nicht der Fall ist, wird hoffentlich in diesem Artikel einige obskure Punkte geklärt.

Dino Esposito* ist der Autor von "Programming Microsoft ASP.NET-MVC3 "(Microsoft Press, 2011) und Mitautor von"Microsoft.NET: Architekturanwendungen für das Unternehmen "(Microsoft Press, 2008). Esposito Lebt in Italien Und ist Ein Weltweit Gefragter Referent Bei Branchenveranstaltungen. Sie folgen ihm auf Twitter bei twitter.com/despos.*

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels:Andrea Saltarello undDiego Vega