Architettura a Moduli

Una delle caratteristiche più potenti di SismaFramework è la sua architettura modulare. Invece di costruire un'unica applicazione monolitica, il framework ti incoraggia a suddividere la tua applicazione in moduli indipendenti e riutilizzabili. Questo approccio mantiene il codice organizzato, facile da navigare e da manutenere, specialmente in progetti di grandi dimensioni.

Cos'è un modulo?

Un modulo è un'unità autocontenuta che raggruppa una specifica funzionalità dell'applicazione. Ogni modulo ha la sua struttura di cartelle, con i propri controller, modelli, viste, form, ecc.

Ad esempio, in un'applicazione complessa potresti avere moduli separati per:

• User: Gestione degli utenti, profili, autenticazione.
• Blog: Gestione di articoli, categorie, commenti.
• Shop: Gestione di prodotti, ordini, pagamenti.

Struttura delle Cartelle di un Modulo

La struttura predefinita per un modulo (es. MyBlog) è la seguente. Non tutte le cartelle sono obbligatorie; puoi creare solo quelle che ti servono.

MyBlog/
└── Application/
    ├── Assets/
    ├── Controllers/
    ├── Entities/
    ├── Enumerations/
    ├── Forms/
    ├── Locales/
    ├── Models/
    ├── Permissions/
    ├── Templates/
    ├── Views/
    └── Voters/

Registrazione e Autoloading

Per far sì che il framework riconosca il tuo nuovo modulo, devi registrarlo nel file Config/config.php.

// in Config/config.php
const MODULE_FOLDERS = [
    'MyBlog',         // Il tuo nuovo modulo
    // il modulo di sistema SismaFramework non va indicato
];

L'autoloader del framework userà questo array per trovare e caricare automaticamente le classi da tutti i moduli registrati.

Comandi Console e Moduli (--module)

Quando più moduli registrano un comando console con lo stesso nome (ad esempio un comando install proprio di un modulo), puoi selezionare esplicitamente quale modulo deve gestirlo con l'opzione globale --module=NomeModulo:

php SismaFramework/Console/sisma install --module=MyBlog

Senza --module il dispatcher esegue il primo comando compatibile trovato, seguendo l'ordine di discovery (moduli configurati in MODULE_FOLDERS, poi moduli non configurati, poi framework). Se nessun comando del modulo indicato risulta compatibile, viene lanciata una RuntimeException come per un comando inesistente.

Discovery dei Moduli Non Configurati

Il dispatcher rileva automaticamente anche i moduli presenti fisicamente sul filesystem (cartelle con struttura <Modulo>/Console/Commands/) ma non ancora dichiarati in MODULE_FOLDERS. Questo risolve il problema del "bootstrap circolare": un nuovo modulo può così esporre ed eseguire il proprio comando di installazione (es. tramite --module=NuovoModulo) ancora prima di essere aggiunto a MODULE_FOLDERS, che potrà avvenire come passo finale dell'installazione stessa.

Interazione tra Moduli

I moduli non sono isolati; possono e devono interagire tra loro.

Routing

Il Dispatcher non fa distinzione tra moduli quando risolve un URL. Quando riceve una richiesta per /post/show, cercherà un PostController in tutti i moduli registrati, seguendo l'ordine definito in MODULE_FOLDERS. Il primo che trova, viene utilizzato. Questo permette a un modulo di "sovrascrivere" le rotte di un altro semplicemente posizionandolo prima nell'array di configurazione.

Relazioni tra Entità

L'ORM gestisce senza problemi le relazioni tra entità di moduli diversi. Quando definisci una relazione in un'entità, è sufficiente usare il namespace completo della classe dell'entità correlata.

Esempio: Un'entità Post nel modulo Blog che ha una relazione con un'entità User nel modulo User.

Blog/Application/Entities/Post.php

namespace Blog\Application\Entities;

use SismaFramework\Orm\BaseClasses\BaseEntity;
use User\Application\Entities\User; // Importa l'entità dall'altro modulo tramite il suo namespace

class Post extends BaseEntity
{
    // ... altre proprietà
    protected User $author; // La relazione funziona perfettamente

    // ...
}

Indice | Precedente: Installazione e Configurazione | Successivo: Riepilogo delle Convenzioni