Das logische Modell: Anwendungsdefinition und Planung

Der zweite Schritt in einem COM+-Anwendungsentwurfsprozess besteht darin, das konzeptionelle Modell in die logischen Ebenen der dreistufigen Architektur aufzuteilen: die Präsentationsebene oder Benutzerdienste; die mittlere Ebene oder Geschäftsdienste; und die Datenebene oder Datendienste. Wenn Sie mit der Architektur mit drei Ebenen nicht vertraut sind, finden Sie weitere Informationen unter Verwenden eines Three-Tier-Architekturmodells.

Beginnen Sie diesen Prozess, indem Sie das konzeptionelle Modell nach Nomen und Verben durchsuchen. Die Nomen können häufig in Geschäftsobjekte (Klassen) übersetzt werden, und die ihnen zugeordneten Verben können in Aktionen (Methoden der Klassen) übersetzt werden. Obwohl es schwierig sein kann, alle Nomen als Geschäftsobjekte zu definieren, werden Auslassungen oder Fehler offensichtlich, wenn Sie das logische Modell abgeschlossen haben.

Die meisten Geschäftsobjekte landen auf der Geschäftsdienstebene, wobei die verbleibenden Objekte zwischen Benutzeroberflächenobjekten auf der Benutzerdienstebene und Datenobjekten in der Datendienstebene aufgeteilt sind. Beachten Sie beim Erstellen eines logischen Modells mit der Architektur mit drei Ebenen Folgendes:

  • Einige der Nomen im konzeptionellen Entwurf stellen keine tatsächlichen physischen Datenteile dar, sondern können eine Aktion im System oder die Rolle eines Geschäftsobjekts im System darstellen. Ein Geschäftsobjekt kann auch ein Dienst sein, der eine Art Systemsteuerung ausführt, z. B. eine Anmelde-ID aus Sicherheitsgründen.
  • Vermeiden Sie das Erstellen von vage Geschäftsobjekten durch "Lesen zwischen den Zeilen" im konzeptionellen Modell. Solche Geschäftsobjekte sind möglicherweise nicht korrekt, und Sie sollten sie sorgfältig prüfen, bevor Sie sie in das logische Modell aufnehmen. Wenn sie korrekt erscheinen, fügen Sie sie explizit dem konzeptionellen Modell hinzu.
  • Vermeiden Sie das Erstellen von Geschäftsobjekten, die die gleichen Informationen oder Funktionen ausdrücken. Duplizierung kann in Bezug auf Anwendungsgeschwindigkeit und -leistung kostspielig sein.
  • Bestimmen von Objektabhängigkeiten. Einige Nomen im konzeptionellen Modell können einfach Attribute anderer Geschäftsobjekte sein. Entscheiden Sie, ob das Attribut unabhängig vorhanden sein kann. Wenn ja, sollte es zu einem eigenen Geschäftsobjekt werden; andernfalls sollte es mit dem entsprechenden Geschäftsobjekt kombiniert werden.
  • Vermeiden Sie das Erstellen von Geschäftsobjekten, die versuchen, zu viel zu tun. Das Überladen von Geschäftsobjekten kann dazu führen, dass später mehr Zeit für die Trennung von Code aufgewendet wird, und es kann zu Wartungsschmerzen führen. Verschiedene Objekte im konzeptionellen Modell sollten nicht kombiniert werden. Sie sollten separate Geschäftsobjekte bleiben. Sie können alle Ähnlichkeiten verarbeiten, indem Sie Code verwenden, um ihre allgemeinen Funktionen an ein Geschäftsobjekt zu delegieren.
  • Entfernen Sie alle Geschäftsobjekte, die nicht in Verwendungsszenarien verwendet werden. Wenn die Objekte für zukünftiges Wachstum vorgesehen sind, sollten Sie sie nach Abschluss der ersten Anwendung implementieren.

An diesem Punkt können Sie beginnen, in Bezug auf die Computer und den Code zu denken. Ermitteln Sie anhand dieser Geschäftsdienste die Anzeige- und Eingabefunktionen, die Sie als Benutzerdienste bereitstellen müssen. Definieren Sie, welche Tabellen und gespeicherten Prozeduren als Datendienste bereitgestellt werden müssen. Um das logische Modell abzuschließen, definieren Sie die Schnittstellen für jeden Dienst, und schließen Sie Definitionen der einzelnen Datenfelder und deren Validierungsregeln ein. Schließen Sie auch alle Funktionen, ihre Syntax und ihre Parameter ein.

Die Dienst- oder Objektdefinition sollte keinen Aspekt der physischen Implementierung enthalten. Die Absicht besteht darin, eine klare Richtlinie für die Ersteller logischer Komponenten bereitzustellen, mit denen sie arbeiten können, und anderen Programmierern zu ermöglichen, Teile der Anwendung zu programmieren, die die Komponente verwenden können, bevor sie tatsächlich abgeschlossen ist. Im logischen Modellentwurf sollten Sie alle Bildschirme, Funktionen und Objekte dokumentieren. Fahren Sie erst mit dem physischen Modell oder der Implementierung fort, wenn Sie diese Kriterien erfüllen. Wenn Sie fortfahren, während das konzeptionelle Modell und das logische Modell nicht übereinstimmen, treten später im Entwicklungszyklus schwerwiegende Probleme auf.

Die inkrementelle Entwicklung einer COM+-Anwendung ist üblich. Dies umfasst das Erstellen einer Teilmenge der endgültigen bekannten Komponenten und das Testen dieser Komponenten über jede Ebene der Anwendung: Client-, Geschäfts- und Datenebenen bis hin zur Datenspeicherung. Dieses Arbeitsmodell bietet Einblicke in zusätzliche Anforderungen des Kunden und Überlegungen zur Implementierung. Häufig wird dieses Funktionierende Modell auf einem einzelnen Computer getestet.

Das konzeptionelle Modell: Anwendungsanforderungen

Das physische Modell: Anwendungsarchitektur

Verwenden eines Three-Tier-Architekturmodells