Wie strukturiertes landen von Klassen in Index.php?

[dedlfix]

Tach!

Ich will eine index.php bastel in der alles per include( 'seite.php' ); geladen wird.

Aber wie passt dann diese Aussage

[Die Webseite] soll zusätzlich mit dem Webclient direkt über Nachrichten in einem Dialog kommunizieren könnnen

dazu? Wer kommuniziert denn nun auf welche Weise mit wem?

Für die kann man sich eine WebAPI-Schnittstelle erstellen, beispielsweise nach dem REST-Prinzip.

Was sind WebAPI-Schnittstellen und das REST-Prinzip. Kleine erläuterung und Literatur. Fnde ich in Wiki was? Oder kenne ich diesen Begriff nur unter einem anderen Namen?

WebAPIs sind beispielsweise auch SOAP und XMLRPC. Das sind Ansammlungen von URLs, die nicht für den direkten Aufruf durch menschliche Nutzer vorgesehen sind und vollständige HTML-Seiten liefern, sondern die nur Daten liefern und/oder solche entgegennehmen und verarbeiten und dann nur eine maschinenlesbare Erfolgsmeldung oder Antwortdaten zurückgeben. - Aber das scheint ja nun doch nicht dein Anwendungsfall zu sein.

Man arbeitet (besonders als Einzelkämpfer) ja meist themenorientiert und nicht architekturorientiert.

Klingt einleuchtend. Hast du dazu nen Schaubild für die von Dir bennante Struktur und Controller Code Beispiel? Würde mich zu gern interessieren.

Die übliche Struktur ist sowas wie

- Controllers
  - CustomerController
  - ItemController
  - ShopController
  - CheckoutController
- Models
  - Customer
  - Item
  - Cart
- Views
  - Customer
    - Edit
    - List
  - Item
    - Edit
    - List
  - Shop
    - List
    - Buy
  - CheckoutController
    - Address
    - PayMethod
    - OrderConfirmation
- Helpers
  - SomeCommonValidator
  - CreditCardValidator
- Repositories
  - CustomerRepository
  - ...
- Services
  - CustomerService
  - ...

Sieht auf den ersten Blick schön sortiert aus. Und diese Struktur hat auch Vorteile, beispielsweise dann, wenn man Dinge in mehreren Kontexten benötigt. Items - die Dinge, die man im Shop kaufen kann - müssen nicht nur verwaltet werden, sie müssen auch vom Shop gelistet werden und der Warenkorb muss die Daten der ausgewählten Dinge auch anzeigen.

Nachteilig ist aber, dass für die Erstellung der Kundenverwaltung der Controller in dem einen Verzeichnis ist, das Model in einem anderen, die für die Speicherung zuständigen Repositorys und Services in ihren Verzeichnissen und die Views in einem weiteren. Wenn ich mich recht erinnere, gibt es auch IDEs, in denen man sich individuelle Ansichten erstellen kann, so dass man die zum Arbeiten an einer bestimmten Aufgabe benötigten Dateien an einen Fleck verlinken kann. Aber das nützt einem nur etwas, wenn man dieselbe IDE und dieselben Ansichtsdefinitionen verwendet. Versucht man das Projekt über seine Verzeichnisstruktur zu ergründen, hat man diese nicht zur Verfügung. Deshalb ist es besser, um die Sinnzusammenhänge leichter zu erkennen, dass Projekte nicht nach Programmiermustern / Architekturtypen strukturiert sind, sondern nach fachlicher Zusammengehörigkeit. Nur, wie schon gesagt, ist es nicht immer möglich, klare Grenzen zu ziehen. Eine ordentliche Struktur zu schaffen ist also ähnlich schwierig wie das Finden von aussagekräftigen Namen für Bezeichner. Mitunter ist es auch vom verwendeten Framework vorgegeben, in welchen Verzeichnissen nach bestimmten Dingen gesucht wird, beispielsweise Controller nur im Controllers-Verzeichnis.

- Customers
  - Customer
  - CustomerController
  - Views
    - Edit
    - List
  - CustomerRepository
  - CustomerService
- Items
  - ...
- Shop
  - ...
  - Cart
    - CheckoutController
    - CheckoutViews
        - ...
    - ...
  - CreditCardValidator
- Helpers
  - SomeCommonValidator

Das ist ein Vorschlag, wie man es fachlich sortieren könnte. Natürlich kann man darüber streiten, ob das eine oder andere nicht woanders besser einsortiert wäre. Aber da das nur ein Beispiel ist, zu dem keine konkreten Anforderungen (z.B. eines Auftraggebers) definiert wurden, wird es hier wohl auch kein eindeutiges Richtig oder Falsch geben können. Und, was in dem einen Projekt richtig und sinnvoll war, muss nicht zwangsläufig in einem anderen Projekt ebenso bewertet sein.

dedlfix.