È possibile accoppiare liberamente un'applicazione al proprio framework?

Accoppiare liberamente la tua applicazione al suo framework significa essenzialmente che stai per scrivere un framework proxy. Scrivere quel framework proxy è molto lavoro, e se mai passerai a un nuovo framework dovrai fare un sacco di lavoro per far sì che il framework proxy supporti il nuovo framework. Ovviamente, diversi framework usano idiomi e pattern differenti, il che renderà il framework proxy molto complesso (se si cerca di renderlo adatto a tutto) o molto limitato (se si va al minimo comune denominatore). In entrambi i casi dovrai lottare con quel framework proxy.

Avere la capacità di cambiare framework per un capriccio vale tutti questi problemi? Come ho detto, non sarai in grado di cambiarlo per un capriccio, perché dovrai adeguare il framework del proxy, che potrebbe rivelarsi più efficace della modifica diretta del codice dell'applicazione.

No can do.

Puoi progettare in un modo che è portatile attraverso i framework. MVC è MVC e i principi sono approssimativamente gli stessi indipendentemente dalla lingua o dalla piattaforma utilizzata.

Il codice attuale, tuttavia, dipenderà molto dalla struttura o dalla lingua. L'unico modo per astrarsi da quello sarebbe il codice basato su un quadro intermedio. Quindi è possibile modificare l'implementazione intermedia (da F3 a .NET?) Senza modificare l'applicazione. Il che è molto lavoro, presuppone astrazioni che non perdono e sposta semplicemente il problema senza risolverlo: ora sei legato al tuo framework intermedio.

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

Una volta ho visto Robert C. Martin parlare in cui diceva 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 sei esattamente sicuro di ciò che vuoi usare ancora. Identifica i pezzi che puoi definire ora e che rimarrebbero facilmente indipendenti da qualsiasi framework tu usi.

Il lock-in 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 tuo punto di partenza e a 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 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 tuo framework e potrebbero essere i più difficili da vedere.

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