La definizione di un framework è più o meno come se fossi bloccato a usarlo. La struttura detta la tua architettura. Il tuo codice è intrecciato con il framework. È come scegliere il linguaggio di programmazione. Non puoi modificare il framework senza una riscrittura quasi completa.
Se provi a isolare il tuo codice dal framework, stai combattendo il framework ad ogni passo invece di lasciarti aiutare. Le cose diventano due volte più difficili, perché oltre a scrivere il tuo codice reale dovrai spesso scrivere i wrapper necessari. Questi wrapper finiscono per essere il proprio framework interno che nessun altro conosce.
Ci sono modi per limitare l'impatto di una scelta di struttura. Per esempio. la tua logica di business (se ce ne sarà) sarà probabilmente completamente indipendente dal framework. Invece di un'architettura a strati Views -> Model -> Data è possibile scegliere qualcosa come Onion Architecture in cui le dipendenze sono Views -> Model <- Data . Cioè il modello non dipende dalle altre parti. Se le viste e le interfacce dati fanno uso di un framework, ciò non influirà sul modello dell'utente, ad esempio sulla logica aziendale. Ma questo può anche significare che non puoi beneficiare di modelli come ORM incorporati nel tuo modello.
In molti casi, la velocità di sviluppo è più importante della flessibilità strategica per quanto riguarda le future modifiche del framework. Questa flessibilità porterebbe solo a soluzioni troppo ingegnerizzate. Una struttura completa che assiste in tutte le parti dell'applicazione è quindi benvenuta, anche se il tuo codice diventa inseparabile da quella struttura. Questa è la tua scelta.