Quando si progetta un sistema, è buona norma soddisfare il progetto attorno al framework che verrà utilizzato?

Quando si sviluppa un sistema o un'applicazione che si prevede di utilizzare con un determinato framework, è consigliabile progettare il sistema senza il framework in mente, oppure è meglio progettare il sistema con la mentalità "bene il framework avrebbe un tempo più facile con questo".

Il tuo design dovrebbe soddisfare le esigenze dei clienti il ​​più vicino possibile. Ricorda che il design include piccole cose come:

• Esperienza utente
• Funzionalità
• Come comunicano parti dell'applicazione (con se stessa o entità esterne)

Nessuna di queste cose dovrebbe essere dettata dal quadro. Se è chiaro che dovrai combattere il tuo framework per raggiungere questi obiettivi, allora scegli un nuovo framework che ti aiuterà a raggiungere quegli obiettivi prima di iniziare a scrivere codice.

Dopo aver scelto un set di strumenti appropriato (il framework è uno strumento), quindi consiglio di utilizzare gli strumenti nel modo in cui sono progettati per essere utilizzati. Più si discosta dal design del framework, più si aumenta la curva di apprendimento per il proprio team e maggiori sono le probabilità che qualcosa vada storto.

In breve

• Design per i tuoi utenti
• Scegli gli strumenti appropriati per realizzare il tuo design
• Usa i tuoi strumenti nel modo in cui sono progettati per essere utilizzati

Ulteriori pensieri:

Dopo oltre 20 anni di ingegneria del software e utilizzo di numerosi framework, ho imparato un paio di lezioni. Tutti i framework sono un'arma a doppio taglio: entrambi vincolano e consentono. Il problema di decidere il tuo framework prima di guardare ai grandi 3 che ho menzionato sopra è che potresti compromettere una buona esperienza utente per una mediocre (nella migliore delle ipotesi). Oppure potresti essere costretto a deviare dalla progettazione dei framework per ottenere alcune funzionalità specifiche.

I framework influenzano naturalmente la progettazione di moduli e sottosistemi specifici (come un front-end della GUI). Come menzionato nell'altra risposta, avrai un momento difficile se ti ritrovi a combattere contro il / i quadro / i prescelto / i.

Più in generale, tuttavia, si dovrebbe evitare di lasciare che qualsiasi singolo framework o tecnologia dettino o guidino il "quadro generale" dell'architettura generale del sistema. La maggior parte dei framework applicativi per scopi generici non incoraggia questo, quindi se ti ritrovi a scrivere l'intero sistema attorno a un framework, probabilmente stai facendo qualcosa che gli autori di quel framework non intendevano.

Probabilmente userete molti framework diversi per risolvere problemi diversi; man mano che il tuo sistema diventa più complesso, devi stare attento a non costruire The Big Ball Of Mud . Ove possibile, mantieni il tuo sistema modulare e liberamente accoppiato. Alcuni framework potrebbero essere tenuti meglio dietro le astrazioni scrivendo wrapper e adattatori che "nascondono" i flussi di lavoro specifici del Framework lontano da altri componenti. I toolkit GUI tendono a servire solo la funzionalità GUI front-end, quindi quei moduli GUI dovrebbero essere tenuti lontani dal resto del sistema.

Non esistono framework di uso generale (come framework dell'interfaccia utente, framework di layer di dati, ecc.) Per prescrivere l'architettura completa del sistema - al massimo potrebbero prescrivere la progettazione di un componente o modulo; ad esempio, alcune tecnologie GUI sono orientate verso particolari schemi MV *.

L'architettura generale del sistema dovrebbe essere guidata principalmente dai requisiti aziendali . Potresti trovarti appoggiato pesantemente a un particolare strumento (ad esempio, uno strumento di middleware di messaggistica o un framework ORM) al fine di legare tutto insieme, ma se hai incapsulato il framework in un'astrazione come una classe di "servizio", è meno probabile trovarti vincolato da quel quadro quando incontri i suoi limiti.

Cerca di tenere a mente quanto segue per il tuo disegno a grande immagine:

• Punta a costruire software modulare
• Prendi in considerazione la separazione delle preoccupazioni quando scrivi ogni modulo e componente
• Considerare l' architettura multilivello per separare il sistema in livelli
• Non costruire astrazioni che perdono
• Gli acronimi su questa domanda correlata : quali sono classificati DRY, KISS, SOLID, ecc.?

Sì, dovresti attenersi il più vicino possibile a ciò che il framework "ti dice" di fare.

Il motivo è semplicemente che più ti avvicini al modo di "pensare" dei framework, più facile sarai in grado di parlare con altri sviluppatori dei tuoi problemi / idee che usano anche quel framework.

Aumenta l'interoperabilità e la facilità d'uso per le altre persone che lo usano in seguito, capirai e incorporerai meglio tutorial o soluzioni comuni se ti atterrai alla filosofia di base di qualunque cosa tu stia usando.

L'unica buona ragione per cui riesco a pensare al motivo per cui "rompi" il framework è che hai assolutamente bisogno di qualcosa che non può fornire, data la sua configurazione / applicazione "predefinita" dei principi. Ma allora, potrebbe non essere il quadro giusto per cominciare.

Fondamentalmente, questo può essere applicato anche ad altre decisioni. Dovresti usare la lingua che stai usando tanto attentamente quanto è destinata a essere utilizzata, perché semplifica le cose se parli la stessa lingua di tutti gli altri.