Vom schulischen zum professionellen

Vom schulischen MVC zur professionellen Webarchitektur (Teil 1 von 2)
💡 Professionell heißt: verständlich, testbar, erweiterbar, sicher strukturiert

Entwicklung eines modularen Mini-Frameworks als langfristige Projektbasis

Ziel:

Dieses Projekt dient als architektonische Referenz für die Entwicklung skalierbarer Webanwendungen. Es zeigt den schrittweisen Übergang von einer schulischen MVC-Struktur zu einer professionellen, modularen Webarchitektur.
Das Endergebnis ist kein einzelnes Projekt, sondern ein leichtgewichtiges Mini-Framework, das:

dient als stabile Basis für beliebige Webprojekte
es langfristige Erweiterbarkeit ermöglicht
es vermeidet spätere Komplett-Refactors

„Einmal das richtige Fahrgestell bauen – danach nur noch Module austauschen.“

Ausgangspunkt:

Um dieses Konzept praxisnah zu demonstrieren, arbeite ich in zwei Phasen mit bereits vorhandenen Demo Projekte:

Phase 1: Als Ausgangspunkt diene ich mein DemoMVC-Projekt – eine typische schulische MVC-Implementierung, die alle wesentlichen Konzepte enthält, aber noch keine professionelle Struktur aufweist.

Phase 2: In der zweiten Phase verwende ich das Demologin-Projekt, das auf derselben DemoMVC-Basis aufgebaut ist, jedoch hat es bereits eine vollständige Login-Funktionalität implementiert.

Etappen:

ETAPPE	FOKUS	ZIEL	PHASE
1	Schulisches MVC	Verständnis	1
2	Ordnerstruktur	Sicherheit & Übersicht	1
3	Bootstrap & Rooter	Index Entlastung & Request-Flow	1
4	.htaccess-Konfiguration	Zugangssicherheit (Grundlage)	1
(5)	Services & Klassen	Struktur & Testbarkeit (später)	2
(6)	Mini-Framework	Langfristige Skalierbarkeit (später)	2

👉 Jede Etappe funktioniert eigenständig
👉 Keine „Alles neu“-Momente

Struktur:

Ziel: Sicherheit & Übersicht, ohne Refactor

Prinzip: Nur public/ ist öffentlich erreichbar – alles andere geschützt.

Projekt/
    ├─ app/
    │  ├─ config/
    │  ├─ control/
    │  ├─ helper/
    │  ├─ model/
    │  ├─ service/
    │  ├─ view/
    │  └─ bootstrap.php
    │  └─ rooter.php
    │  └─ session.php
    ├─ doc/...
    ├─ public/    ← einzig öffentlich
    │  ├─ css/
    │  └─ img/
    │  ├─ js/
    │  ├─ index.php    ← Single Entry Point
    ├─ sql/
    ├─ storage/
    │  ├─ logs/
    │  └─ upload/
    └─ README.md

Entlastung des Index:

Problem:

Im schulischen MVC übernimmt index.php zu viel:

Rooter
Controller
Security-Gate
Workflow-Orchestrator

👉 Single Point of Chaos

Ziel:

index.php wird:

Klein
Startpunkt
keine Logik

Lösung:

Rooter auslagern
Zentrale Bootstrap-Logik
Vorbereitung für Autoloading
klare Request-Pipeline

Request-Pipeline

Request
↓
public/index.php
↓
Bootstrap
↓
Rooter
↓
Controller
↓
Service
↓
View / Response

Bootstrap:

Initialisiert:

config
Session
Helper
Controller & Service
Model & View

Rooter:

Aufgabe:

URL → Controller / Aktion
Parameter extrahieren
Fehler sauber behandeln

Umsetzen:

Erstelle: app/bootstrap.php
Verschiebe die Importpfade vom index in den neuen bootstrap
Verschiebe den switch($page) in Controller in einer Funktion eingebettet
Verschiebe Controller Inhalte in Service Ordner und teile es auf die neuen Dateien auf:

      App/services/
      │  ├─ AuthService.php
      │  ├─ UserService.php
      │  ├─ ProfileService.php
      │  ├─ SessionService.php
      │  └─ UploadService.php

Erstelle: app/rooter.php
Verschiebe Sprach- und Seiten-Prüfung von session.php zu rooter.php

Sicherer Zugang mit .htaccess (Zwei-Datei-Architektur)

Ziel: Mehrschichtiger Schutz mit klarer Aufgabentrennung

Prinzip: Zwei .htaccess-Dateien arbeiten zusammen für maximale Sicherheit

Basis .htaccess (Root):

    # BASIS/.HTACCESS (Root-Verzeichnis)
    # Aufgabentrennung: URL-Umleitung & Grundschutz

    # SCHUTZ VON .HTACCESS DATEI
    RewriteRule ^\.htaccess$ - [F]

    <IfModule mod_rewrite.c>
        RewriteEngine On

        # ALLE ANFRAGEN AN PUBLIC/ UMSCHREIBEN
        RewriteCond %{REQUEST_URI} !/public/
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.*)$ public/$1 [QSA,L]

        # STATISCHE DATEIEN DIREKT AUSLIEFERN
        RewriteCond %{REQUEST_URI} !/public/
        RewriteCond %{REQUEST_FILENAME} !-f
        # ALLES ANDERE AN PUBLIC/INDEX.PHP
        RewriteRule ^(.*)$ public/index.php [QSA,L]
    </IfModule>

Public .htaccess (Anwendung):

    # BASIS/PUBLIC/.HTACCESS 
    # Aufgabentrennung: Application Routing

    RewriteRule ^\.htaccess$ - [F]

    <IfModule mod_rewrite.c>
        RewriteEngine On

        # EXISTIERENDE DATEIEN/ORDNER DIREKT AUSLIEFERN
        RewriteCond %{REQUEST_FILENAME} -f [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^ - [L]

        # ALLES ANDERE → INDEX.PHP (FRONT CONTROLLER)
        RewriteRule ^ index.php [L]
    </IfModule>

Warum zwei Dateien:

Schichtensicherheit: Doppelter Schutz vor Verzeichnis-Durchsuchung
Aufgabentrennung: Root regelt Zugang, Public regelt Routing
Debugging: Einfacher zu testen und zu warten
Flexibilität: Kann pro Umgebung angepasst werden

Wie sie zusammenarbeiten:

Schritt 1: Root .htaccess leitet alle Anfragen zu public/ um
Schritt 2: Public .htaccess prüft ob Datei/Ordner existiert
Schritt 3: Statische Dateien werden direkt geliefert
Schritt 4: Alles andere geht an index.php (Front Controller)

👉 Zusammen mit der Ordnerstruktur bildet dies die Sicherheitsgrundlage des gesamten Projekts. Keine sensiblen Dateien sind je öffentlich erreichbar.