Quando si sviluppa un sistema o un'applicazione che si intende utilizzare con un determinato framework, è consigliabile progettare il sistema senza il framework in mente, o è meglio progettare il sistema con la mentalità "beh, il framework avrebbe un momento più semplice con questo ".
Il tuo design dovrebbe soddisfare le esigenze dei clienti il più strettamente possibile. Ricorda che il design include piccole cose come:
Nessuna di queste cose dovrebbe essere dettata dal framework. Se è chiaro che dovrai combattere il tuo framework per raggiungere questi obiettivi, allora scegli un nuovo framework che ti aiuterà a raggiungere questi obiettivi prima di iniziare a scrivere il codice.
Una volta scelto un set di strumenti appropriato (il framework è uno strumento), allora consiglio di utilizzare gli strumenti nel modo in cui sono progettati per essere utilizzati. Più ti allontani dalla struttura, più aumenti la curva di apprendimento per la tua squadra e maggiori possibilità che qualcosa vada storto.
In breve
Ulteriori riflessioni:
Dopo oltre 20 anni di ingegneria del software e utilizzo di diversi framework, ho imparato un paio di lezioni. Tutti i quadri sono un'arma a doppio taglio: entrambi vincolano e abilitano. Il problema con la decisione del framework prima di guardare il grande 3 che ho citato sopra è che potresti compromettere una buona esperienza utente per uno mediocre (nel migliore dei casi). Oppure potresti essere costretto a deviare dal design del framework per realizzare alcune funzionalità specifiche.
I framework influenzano naturalmente la progettazione di moduli specifici e di sottosistemi (come un front-end della GUI). Come l'altra risposta menzionata, avrai un momento difficile se ti troverai a combattere contro i tuoi quadri scelti.
Più in generale, tuttavia, dovresti evitare di lasciare che un singolo framework o tecnologia imposti o guidare il "quadro generale" della tua architettura generale del sistema. La maggior parte dei framework per applicazioni generiche non lo incoraggia, quindi se ti ritrovi a scrivere l'intero sistema su un framework, probabilmente stai facendo qualcosa che gli autori di quel framework non intendevano.
Probabilmente userai molti quadri diversi per risolvere diversi problemi; man mano che il tuo sistema diventa più complesso, devi stare attento a non creare The Big Ball Of Mud . Ove possibile, mantenere il sistema modulare e liberamente accoppiato. Alcuni framework potrebbero essere meglio mantenuti dietro le astrazioni scrivendo wrapper e adattatori che "nascondono" i flussi di lavoro specifici del Framework lontano da altri componenti. I toolkit della GUI tendono a offrire solo funzionalità GUI front-end, quindi i moduli della GUI devono essere tenuti lontani dal resto del sistema.
I quadri per scopi generali (come i framework UI, i framework del livello dati, ecc.) non esistono per prescrivere l'architettura completa del tuo sistema - al massimo potrebbero prescrivere la progettazione di un componente o di un modulo; per esempio, alcune tecnologie GUI sono orientate verso particolari modelli MV *.
L'architettura generale del tuo sistema dovrebbe essere guidata principalmente dai tuoi requisiti aziendali . Potresti trovarti ad appoggiare pesantemente su uno strumento particolare (ad esempio, uno strumento middleware di messaggistica o un framework ORM) per legare tutto insieme, ma se hai incapsulato il framework in un'astrazione come una classe di 'servizio' tu È meno probabile che tu ti ritrovi costretto da quel quadro quando incontri i suoi limiti.
Cerca di tenere presente quanto segue per il tuo design di immagini grandi:
Sì, dovresti applicare il più vicino possibile a ciò che il framework "dice" di fare.
La ragione è semplicemente che quanto più ti avvicini al modo di pensare del framework, tanto più facilmente sarai in grado di parlare con altri sviluppatori dei tuoi problemi / idee che usano anche quel framework.
Aumenterai l'interoperabilità e la facilità d'uso per le altre persone che lo useranno più tardi, capirai e incorpori tutorial o soluzioni comuni meglio se ti attieni alla filosofia sottostante di qualunque cosa tu stia utilizzando.
L'unica buona ragione per cui riesco a pensare al perché "infrangere" il framework è che hai assolutamente bisogno di qualcosa che non può fornire data la sua configurazione "predefinita" / l'applicazione dei principi. Ma poi, potrebbe non essere la struttura giusta per cominciare.
Fondamentalmente, questo può essere applicato anche ad altre decisioni. Dovresti usare la lingua che stai utilizzando così attentamente come dovrebbe essere usata, perché rende le cose più semplici se parli la stessa lingua di chiunque altro.
Leggi altre domande sui tag development-process systems