Applikationsspezifische Namespaces
Clients konsumieren die von den Services zur Verfügung gestellten REST-Services. Ein Client konsumiert alle vom entsprechenden Service zur Verfügung gestellten Funktionalitäten. Ein Client konsumiert immer nur die Funktionalitäten genau eines Services. Der Client ist unter dem Namespace Fortuna.Client angeordnet. Ein Client für die Services aus Fortuna.Services.Vertrag wäre also unter Fortuna.Client.Vertrag zu finden. Der Client wird immer als eigenes Projekt implementiert; der Projektname entspricht dem Namespace (also im Beispiel Fortuna.Client.Vertrag.csproj). Die Daten zwischen Client und Service werden über Models ausgetauscht. Weiteres zu Models siehe unter http://webentw3.gutingia.local/blog/post/2017/01/26/models-in-fortuna-5-0.
Der Client selbst wird dann von der eigentlichen WebApplikation verwendet. Die WebApplikation ist im Namespace Fortuna.Web angeordnet (und wäre dann unter Fortuna.Web.MeineApp zu finden). Das Projekt der WebApplikation entspricht auch hier dem Namespace (also im Beispiel Fortuna.Web.MeineApp.csproj). Eine WebApplikation kann mehrere Clients benutzen um Funktionalitäten abzubilden. Genauso können Clients in verschiedenen WebApplikationen Verwendung finden.
Entities, Datalayer, Models und Services
Entities sind unter Fortuna.Entities eingeordnet. Entitäten sind unabhängig von einer Webapplikation und entsprechen letztlich einer Tabelle oder View im Datenbankuser 'Fortuna'. Um bereits in den Entities unterscheiden zu können, sind Tabellen bereits mit T_[Objekt], Views mit V_[Objekt] zu benennen. Entsprechend beginnen dann die Entitäten auf Tabellen mit 't' (t[Objekt]) und Views mit 'v' (v[Objekt]).
Beispiel: Personen liegen in der View V_Person und daraus ergibt sich die Entität (inkl. Namespace) Fortuna.Entities.vPerson
Bei der Anlage von Tabellen und Views ist entsprechend schon sorgfältig auf die Namensvergabe zu achten.
Entities werden in einem eigenen Projekt 'Fortuna.Entities' angelegt. Sollten im Laufe der Entwicklung sehr viele Entitäten anfallen, ist zu überlegen, ob man diese thematisch in mehrere Projekte aufteilt, der Namespace bleibt Projektübergreifend aber immer Fortuna.Entities.
Die Aufteilung sollte in keinem Falle anwendungsspezifisch sein, da der allergrößte Teil der Entitäten immer in verschiedenen Applikationen Verwendung finden wird. Wenn man bereits zu Beginn einer neuen Applikation ansehen kann, daß eine Reihe von Entitäten sehr Anwendungsspezifisch sein werden und aller Voraussicht nach nur für diese eine Anwendung zur Verfügung stehen müssen, so kann für diese ein gesondertes Projekt erstellt werden, welches dann aber auch unter dem Namespace Fortuna.Entities agiert.
Die Entities sind in einem Projekt mit einen Datenlayer abzulegen. Dieser Datenlayer sorgt dafür, daß die Informationen aus den Entities über Models weitergegeben werden. Weiteres zu Models siehe unten. Die Methoden des Datenlayers sind nach außen nicht sichtbar. Die Objekte, welche über den ORM Mapper für die Entities erzeugt werden, werden nicht über Services nach 'außen' verwendet; es ist immer eine Transformation in Models vorzunehmen.
Die Weitergabe der Models an die weiter oben liegende Clients erfolgt über Services, welche über REST ansprechbar sind. Services sind meist recht atomar und applikationsunabhängig. Sie wären also unter Fortuna.Services zu finden. Die Namensvergabe der Objekte sollte Aufschluss über die darin gebündelten/verwendeten Entities geben (Beispiel: Fortuna.Services.Vertrag bündelt Entitäten zu Vertrag, Vertragsteil, Vertragswerte etc.)
Entities, Datenlayer und Services können je nach Umfang in einem gemeinsamen Projekt abgelegt werden oder die Services von den Entities getrennt in unterschiedlichen Projekten. Bei einem Projekt für alles, ist das Projekt thematisch passend zu benennen (etwa Fortuna.Services.Vertrag.csproj). Bei getrennten Projekten werden als Projektnamen die Namen der Namespaces von Entitäten und Services verwendet (also Fortuna.Entities.Vertrag.csproj und Fortuna.Services.Vertrag.csproj)
Sollte es bei den Entitäten Applikationsspezifische Objekte geben, so erhalten diese auch einen eigenen Datenlayer, ggf. eigene Models und eigene Services. Gemeinsam sind diese dann auch in einem eigenen Projekt abzulegen. Der Applikationsname sollte sich im Projektnamen der Entities/des Datalayers/der Services wiederspiegeln.
Weitere Objekte
Eine ganze Reihe von Funktionen und Informationen sind unabhängige von einer bestimmten Applikation sondern mehrfach einsetzbar. In diesem Falle sind gesonderte Namespaces zu verwenden. Als Beispiele sind hier Fortuna.Globals und Fortuna.Configuration zu nennen. Bei der Vergabe von Namespaces ist darauf zu achten, daß diese nicht mit bestehenden Namespaces übereinstimmen. Vor allem die oben verwendeten Begriffe bei Anwendungsspezifischen Namespaces dürfen nicht verwendet werden.
So könnte es z.B. durchaus zu Problemen kommen, wenn eine Anwendung sowohl Fortuna.Services.MeineApp verwendet als auch Fortuna.MeinNamespace.Services.MeineApp. Insbesondere, wenn sich dann in den Namespace Klassen finden, die auch identische Namen haben.