Fortuna Entwickler Blog

Hier wird Ihnen geholfen

Models in Fortuna 5.0

Fortuna.models.Verwendung

Models werden bei Fortuna 5.0 in zwei zu nennenden Bereichen eingesetzt: 

  • Kommunikation zwischen Fortuna.Services und Fortuna.Clients. Hier beschreiben die Models die Objekte, die mittels REST übermittelt werden
  • Kommunikation zwischen Fortuna.Clients und der WebApplikation. Hier beschreiben die Services die Objekte, welche nach extern (z.B. HTML Frontend) geliefert werden.

Für die Kommunikation zwischen Service und Client bietet es sich an, zwischen Request- und Response-Models (Kommunikationswege aus Sicht des Clients) zu unterscheiden.

Bei der Kommunikation zwischen Client und WebApplikation wird man nur zum Teil gesonderte Models benötigen. Geht es um die reine Anzeige / Ausgabe von Daten, so ist möglicherweise das Response-Model aus der Service-Client Kommunikation direkt verwendbar. Bei der Datenpflege ist je nach Anwendungsfall zu entscheiden, ob die vorhandenen Models verwendet werden können, oder ob gesonderte Models benutzt werden und für die Weitergabe an die Services eine Transformation eingesetzt wird.

Ein Model beschreibt immer nur die Struktur eines Objektes und stellt keine eigene Funktionalitäten bereit. Datenmanipulationen sind nur in geringem Umfang im Model umzusetzen (Beispiel: aus den Eigenschaften Vorname und Nachname ein Feld Name bereitstellen, welches dann aus Nachname, Vorname oder auch Vorname Nachname besteht, oder eine IBAN in maschinenlesbarer und mit Leerstellen aufbereiteter Form zur Verfügung stellen).

Namespaces

Models liegen im Namespace Fortuna.Models. Applikationsspezifische Models entsprechend unter Fortuna.Models.MeineApp. Für Models, welche für Querschnittsfunktionalitäten genutzt werden, ist zu prüfen, ob diese entsprechend der Verwendung gruppiert werden können (also z.B. Fortuna.Models.Kommunikation.MeinModel). Ansonsten erfolgt die Zuordnung unter Fortuna.Models.Common (also z.B. Fortuna.Models.Common.MeinModel).

Bei der Unterscheidung nach Request- und Response-Models ist der Namespace Applikationsspezifisch entsprechend zu unterteilen (also Fortuna.Models.MeineApp.Request und Fortuna.Models.MeineApp.Response).

Da die gleichen Models möglicherweise in verschiedenen Projekten einer Applikation verwendet werden, sind diese in einem eigenen Projekt abzulegen. Das Projekt bekommt den Namen des Namespaces ungeachtet von möglicher Unterscheidung nach Request und Response (also im Beispiel Fortuna.Models.MeineApp.csproj). Models für Querschnittsfunktionalitäten werden in einem Projekt Fortuna.Models.Common abgelegt. Dies gilt auch bei einer vorgenommen Gruppierung.

Architektur Fortuna 5.0


Fortuna Anwendungen lassen sich grob in  drei Schichten teilen:

  • Datenbank
  • Daten- und sonstige Services
  • Webapplikation

Die Kommunikation zwischen den Schichten ist immer identisch, unabhängig davon, um welchen fachlichen Themenbereich es sich handelt.

Die Komponenten in den einzelnen Schichten folgen stets festgelegten Vorgehensweisen, Zugriffsarten und Namensgebungen, sodass man unabhängig der fachlichen Aspekte aus technischer Sicht schnell ein Zuordnung findet.

Alle weiteren Erläuterungen beziehen sich zwar auf die derzeitige Infrastruktur der Produktionsumgebung, sind aber auch in der Test- und Entwicklungsumgebung und bei Austausch einzelner Teile der Infrastruktur adaptiv anzuwenden. Die Beschreibungen beziehen sich - wenn nicht anders beschrieben - immer auf den Kontext Webapplikationen und Kommunikation nach Extern.

Datenbank

Alle Daten der Bestandsverwaltung sind auf DBPROD1 im User GUTINGIA abgelegt. Hinzu kommen noch Dokumente, die als Binärobjekte sind auf DBDOK1 im User DBDOK abgelegt sind. Letztere sind gesondert zu behandeln.

Neu hinzu kommt nun der User FORTUNA auf DBPROD1. Dieser User soll perspektivisch als einziger "Kontaktpunkt" für den Datenzugriff dienen und die Benutzer WEBDATA, WEBFRW und WEBSERVICES ersetzen. Webapplikationen verwenden letztlich nur noch diesen User zum Lesen und Schreiben von Daten. Hierbei gelten einige Regeln:

  • Der lesende Zugriff auf Daten geschieht ausschließlich über Views. Benötigt eine Anwendung also Informationen aus GUTINGIA, so ist auf Fortuna eine View zu erstellen, welche die Daten aus GUTINGIA holt und in FORTUNA bereitstellt. Die Webanwendung greift auf diese View zu.
  • Der schreibende Zugriff auf Daten geschieht ausschließlich im Datenbankuser FORTUNA. Daten, welche nachfolgend von GUTINGIA benötigt werden (Stichwort: Dunkelverarbeitung) werden von GUTINGIA aus diesen Tabellen gelesen.
  • Es findet kein direkter schreibender Zugriff auf Tabellen im Datenbankuser GUTINGIA statt.
  • Der lesende Zugriff auf Tabellen, welche unter FORTUNA liegen kann wahlweise direkt oder über eine View erfolgen. Hier wäre allerdings auch eine View zu bevorzugen, wodurch dann in den darüber liegenden Entitäten schon über die Entität selbst klar wäre, ob es sich um lesende oder schreibende Zugriffe handelt.

Daten- und sonstige Services

Jeglicher Datenbankzugriff (lesend und schreibend), Zugriff auf Dokumente, Mailversand, Versand von SMS und alle weiteren nicht fachlich definierten sind hier zu implementieren.

Der Zugriff (lesend und schreibend) auf die Datenbank erfolgt ausschließlich über das Entity Framework und der einzige zu verwendende Datenbankbenutzer ist FORTUNA.

Für die Kommunikation zu WebApplikationen werden in dieser Schicht REST-Services zur Verfügung gestellt welche über dedizierte Clientbibliotheken konsumiert werden können. Alle Funktionalitäten sich auf diese Weise zu kapseln.

In der Entwicklung von Klassen und Funktionen ist die korrekte Benennung von Namespaces zu beachten (Weiteres hierzu siehe unter http://webentw3.gutingia.local/blog/post/2017/01/26/namespaces-in-fortuna-5-0)

Webapplikationen

Jegliche Anwendung, die für eine Kommunikation nach Extern verwendet wird, ist in dieser Schicht angesiedelt. Dies betrifft natürlich vor allem Anwendungen mit einem HTML-Frontend, aber auch Services, welche für externe Partner zur Verfügung gestellt werden.

Der Zugriff auf die Daten- und sonstigen Services (siehe oben) erfolgt ausschließlich über Client Bibliotheken, welche dann über REST kommunizieren. Es gibt keinen direkten Zugriff auf Funktionalitäten dieser Schicht.