È possibile accoppiare liberamente un'applicazione al suo framework?

Diciamo che sto sviluppando un'applicazione web. La mia prima scelta è usare PHP con Fat-Free Framework (F3) e pattern MVC. L'anno prossimo potrei decidere di voler passare a Zend Framework o forse anche ASP.NET MVC. Ha senso provare a progettare la mia applicazione in modo tale che sia vagamente accoppiata al suo framework o il framework è troppo integrale per renderlo realistico?

L'unico motivo per cui chiedo è perché è venuto di recente in una conversazione con un collega, che ha criticato la mia torta nell'idea del cielo di accoppiare liberamente la mia applicazione a F3.

Associare liberamente l'applicazione al suo framework significa essenzialmente scrivere un framework proxy. Scrivere quel framework proxy è molto impegnativo e, se mai dovessi passare a un nuovo framework, dovrai fare molto lavoro affinché il framework proxy supporti il ​​nuovo framework. Naturalmente, quadri diversi usano idiomi e schemi diversi, il che renderà il framework proxy molto complesso (se si tenta di adattarlo a tutto) o molto limitato (se si sceglie il minimo comune denominatore). In entrambi i casi dovrai lottare con quel framework proxy.

Avere la capacità di cambiare i quadri su un capriccio vale tutti questi problemi? Come ho detto, non sarai in grado di cambiarlo per un capriccio perché dovrai regolare il framework proxy, che potrebbe rivelarsi più lavoro che regolare direttamente il codice dell'applicazione.

Non si puo 'fare.

Puoi progettare in un modo che sia portatile attraverso i framework. MVC è MVC e i principi sono all'incirca gli stessi indipendentemente dal linguaggio o dalla piattaforma utilizzati.

Il codice reale, tuttavia, sarà molto dipendente dal framework o dalla lingua. L'unico modo per sottrarvisi sarebbe codificare in base a un framework intermedio. Quindi è possibile avere la modifica dell'implementazione intermedia (da F3 a .NET?) Senza modificare l'applicazione. Il che richiede molto lavoro, presuppone astrazioni non che perdono e sposta semplicemente il problema senza risolverlo: ora sei legato al tuo quadro intermedio.

Una nota più positiva: considera di esprimere alcuni dei tuoi test (stile BDD) in una piattaforma indipendente dalla tua implementazione. Quelli potrebbero sopravvivere a importanti riscritture.

Una volta ho visto Robert C. Martin tenere un discorso in cui ha detto qualcosa sulla falsariga di "la prima decisione che prendi è la più difficile da cambiare in seguito".

Quindi il mio consiglio è di provare a ritardare questa decisione se non si è ancora sicuri di cosa si desidera utilizzare ancora. Identifica i pezzi che puoi definire ora e che rimarrebbero facilmente indipendenti dal framework che finisci per usare.

Il blocco del framework può essere un problema serio, ma aiuta a considerare il problema come una portabilità. La portabilità non è un attributo assoluto, ma relativo al punto di partenza e dove potresti voler andare. Per analogia, quindi, il software è portatile solo nella misura in cui è già stato portato su altri ambienti.

La maggior parte dello sviluppo di un'applicazione all'interno di un framework tende ad essere il codice della colla, il materiale che lega insieme i componenti del framework. I file di configurazione possono astrarre una certa quantità di colla in alcuni sistemi, ma molti dei dettagli devono essere fatti nel codice.

D'altra parte, le regole e i processi aziendali possono essere astratti dall'applicazione. La parte difficile dell'astrazione è quando le regole sono implementate direttamente dal framework; la sicurezza, l'accessibilità e il sequenziamento dei processi tendono ad essere applicati dal framework e potrebbero essere i più difficili da vedere.

Se riesci a separare la parte di colla della tua applicazione dalla regola aziendale e dalla parte dei processi aziendali e dei dati aziendali, sarai in grado di rendere portatili alcune parti della tua soluzione.