Ein paar Worte zur "neuen" Architektur

[Forte]

Hallo

Wie ihr alle unweigerlich gemerkt habt, haben Smiley und ich noch in der Nacht von SA auf den SO an der Architektur gearbeitet. Die Umsetzung lies sich in dieser Nacht leider nicht komplett abschliessen. Die Arbeiten sind aber im Gange... und kommen gut voran.

Ich möchte an dieser Stelle kurz erläutern, was die Grundidee der Architektur sein wird. Dies in der Hoffnung, dass wenn ihr auf die neue Architektur / Ordnerstruktur stossen werde, ihr diese erkennt und besser damit zurecht kommt.

Die Ordnerstruktur:

• eCamp3
  
• application
• confics
• Core
  
• CoreServices
  
• Module
  
• WebApp
  
• MobileApp
  
• library
• public

Ein paar Worte zu den einzelnen Ordner:

application:

Dieser Ordner enthält alle eCamp3 spezifischen Dateien, welche mit dem Browser nicht zugänglich sein müssen / sollen.

configs:

In configs steckt die application.ini. Diese umfasst einige Konfigurationen (z.b. Datenbank Passwort)

Auch denkbar wäre eine acl.ini, welche die rechte einzelner Rollen fest legt. (ACL = Access Control List)

Core:

Im Ordner Core kommt der harte Kern von eCamp. Das heisst, all der benötigte Code, um die Funktionalität von eCamp sicher zu stellen und die Konsistenz der Datenbank zu sichern. Darunter fallen z.B. Entitäten (also das Model), die Authentifizierung, die Rechte (ACL) und andere...

CoreServices:

Der Ordner CoreServices sollen Services liegen, welche den Zugang zum Core vereinfach, aber auch vereinheitlichen soll. Die Idee ist es, dass Module nur auf Methoden / Funktionen von diesen Services verwenden dürfen. Es handelt sich somit um eine art systeminterne API. (weitere Erläuterungen folgen in der Diskussion)

Module:

Module bilden die Schnittstelle zur Aussenwelt. Sie definieren, wie eCamp verwendet / aufgerufen wird und wie die Antwort aussieht.

Die benötigten Informationen/Daten zu laden, müsse die Module Services aus CoreServices verwenden. Aufrufe direkt auf den Core sind nicht erlaubt.

WebApp:

Das HTML Interface von eCamp.

MobileApp:

Ein Mobiles Interface von eCamp... vielleicht eines Tages....

library:

Hier landen in erster Linie Goldstücke von Drittanbieter. Beispiele sind das ZendFramework, der Doctrine als ORM und PHPTal als Template Engine. Es ist auch denkbar, hier Code auszulagern, welcher in keiner Weise eCamp spezifisch ist. 

(Beispiele dafür könnten sein, weitere Validatoren, Routen oder ähnliches...)

public:

Dieser Ordner wird dem Apache-Server als root angegeben. Die index.php und .htaccess Dateien liegen da. 

Weiter liegen Dateien wie JS-, CSS- und Bild-Files, welche für den Browser erreichbar sein müssen, in diesem Ordner.

Die Diskussion:

In der Diskussion möchte ich allen voran folgenden Punkt diskutieren:

Weshalb "zum Geier" braucht diesen CoreService Layer??

Es gibt ein paar Gründe, welche Smiley und mich dazu motiviert haben.

• Der CoreService Layer stellt eine Hand voll Services zur Verfügung. Jeder Service gruppiert eine hand voll Methoden, welche thematisch eine Gemeinsamkeit haben (die konkrete Gruppierung ist noch nicht fixiert). 
  Mit Hilfe dieser Methoden kann das Model manipuliert werden. Alle gewünschten und notwendigen manipulationen müssen von diesem Layer angeboten werden. Zugleich stellt der Layer sicher, dass das Model nie einen ungültigen Zustand einnimmt.
• Direkte zugriffe auf das Model sind nicht erlaubt, damit die Gültigkeit des Models garantiert ist.
• Die Funktionsweise und der mögliche Funktionsumfang aller Module ist identisch.
• Es erleichtert das Gegenlesen von allen Code-Versuchen in den Modulen.
  (Es darf nie auf den Namespace Core zu gegriffen werden!)

Zugleich ist es unumstritten, dass die Gefahr besteht, ein paar Zeilen mehr programmieren zu müssen. Dies möchten wir jedoch in kauf nehmen, und versuchen uns so Qualität zu erkaufen ;)

Wie weiter?

Weiter arbeiten wir gedanklich noch folgenden Fragen:

• Wo findet die Validation von eingegebenen Daten statt:
• im Core muss eine Validation statt finden. Dies, damit das Model nicht inkonsistent werden kann.
• die WebApp will validieren, damit dem User ein qualitatives Feedback gegeben werden kann, welche Angaben falsch sind... und wieso!
• Es soll versucht werden, die Validation nur einmal zu programmieren, da ansonsten inkonsistenten zwischen Core und WebApp entstehen können.

Ein möglicher Ansatz könnte sein, dass die Validatoren (see Zend_Validator) im CoreService Layer liegen und somit vom Core und von WebApp gebraucht werden kann. Es schweben noch weitere Ideen in der Luft... diese mag ich nun aber nicht alle auflisten....

• In welcher Form gelangen die Daten vom Model zur WebApp:
• Eine Möglichkeit ist es, die Entitäten vom Core via CoreService herauszugeben und nach der manipulation vom CoreService wieder zurück in den Core nehmen. Der CoreService müsste dann ala Zöllner agieren und (im mindesten) die Entitäten beim wiedereintritt in den Core auf ihre Gültigkeit prüfen.
• Die Daten könnten als Key-Value Array herausgegeben werden.

Auch hier sind noch weitere Ideen im Raum, doch fixiert ist noch nichts.

So, ich hoffe, dass ich euch somit die Überraschung auf die neue Struktur vorwegnehmen konnte.

Zudem bin ich gespannt, was ihr von diesem Design haltet.

Nun wünsche ich gut Nacht ;)

Gruss Forte