Questa domanda è focalizzata sull'estrazione dei vantaggi e degli svantaggi dell'utilizzo di Frameworks basati sul Web : come Cake PHP, Zend, jQuery, ASP.NET). Questa domanda è completamente indipendente dal linguaggio . Vorrei iniziare con l'idea di "In piedi sulle spalle dei giganti ".

vantaggi:

• Autorizza gli sviluppatori : prendendo funzionalità che in precedenza avrebbero preso centinaia di righe di codice e comprimendole in una semplice chiamata di funzione, consente agli sviluppatori di integrare funzionalità più complesse nei loro siti Web.
• Consentire uno sviluppo più rapido delle applicazioni - questo è molto rilevante per le persone che hanno bisogno di siti Web creati in una finestra molto piccola (qualcuno ne ha qualche esempio?)
• Costi inferiori : consente ai programmatori di trasferire i risparmi sui costi al cliente, generando una gamma completamente nuova di clienti che desideravano un sito Web ma che in precedenza non potevano permettersi i costi di sviluppo più elevati.

svantaggi:

• Comprensione perduta : basandosi sulle caratteristiche di un framework uno sviluppatore corre il rischio di perdere la comprensione di come funzionano le cose (sotto il cofano).
• La scogliera di configurazione: una volta che vai oltre la configurazione del tuo framework, la tua produttività diminuisce immediatamente, può essere difficile implementare funzionalità al di fuori di una configurazione di framework.
• Linee tranvia per sviluppatori : tu (lo sviluppatore) devi fare le cose nel modo in cui lo sviluppatore vuole che tu faccia le cose.

Mi chiedo che cosa la gente dica dei miei punti e se qualcuno non è d'accordo con loro? Anche se le persone hanno punti aggiuntivi, sarei grato.

Ecco la linea di fondo: può essere difficile implementare funzionalità al di fuori della configurazione di un framework.

Esaminiamo questo assunto per presupposto.

Comprensione perduta: basandosi sulle caratteristiche di un framework uno sviluppatore corre il rischio di perdere la comprensione di come funzionano le cose (sotto il cofano).

Falso. Non perderai mai la comprensione di come funzionano le cose. I frame non sono magici. Sono solo codici utili che non devi scrivere tu stesso.

Che ci crediate o no, commetterete errori usando il framework. Dovrai eseguire il debug fino ai livelli più bassi di HTTP per capire cosa hai fatto di sbagliato.

Non perderai mai di vista quello che succede sotto il cofano. A meno che, ovviamente, il tuo framework sia così epico e perfetto da non avere mai problemi.

La scogliera di configurazione: una volta che vai oltre la configurazione del tuo framework, la tua produttività diminuisce immediatamente, può essere difficile implementare funzionalità al di fuori di una configurazione di framework.

Questo ha poco senso prezioso.

Primo. Costruire senza un framework può trasformare un lavoro banale in una grande attività di programmazione che include unit test, debugging, diagnostica, controllo della configurazione e tutto quel lavoro senza valore che reinventa le cose presenti nel framework. Com'è questa "produttività"?

Secondo. L'implementazione di cose al di fuori del framework richiede sempre molto lavoro perché - ehm - implementare qualsiasi cosa al di fuori di un framework richiede sempre molto lavoro. Non ha nulla a che fare con il tempo dedicato all'apprendimento e alla configurazione del framework. L'implementazione di qualsiasi cosa al di fuori del framework è intrinsecamente difficile.

Linee tranvia per sviluppatori: tu (lo sviluppatore) devi fare le cose nel modo in cui lo sviluppatore [framework] vuole che tu faccia le cose.

Corretta. E questa è spesso una buona cosa. Fare le cose in modo coerente è più prezioso che farlo secondo le tue preferenze personali. Potrebbe richiedere "apprendimento" e "comprensione", ma questi hanno un valore.

Problemi di sicurezza: offrire alle persone questi strumenti per sviluppare velocemente siti Web dall'aspetto professionale è un rischio potenziale, le persone possono rapidamente creare siti Web dall'aspetto professionale per aziende fraudolente.

Che cosa? Questo non ha nulla a che fare con il framework. La frode è una frode, indipendentemente dagli strumenti utilizzati.

Contro: eventuale calo del supporto / perdita di popolarità

• Se ci sono due framework web che fanno praticamente la stessa cosa, e il tuo non vince, c'è una possibilità che il progetto muoia. In questa situazione, è necessario conservare da soli il framework (open source), riscrivere l'applicazione o continuare senza aggiornamenti (closed source).
• A seconda del framework, potrebbe essere necessario aggiornare l'applicazione con il programma di rilascio del framework. Restare troppo indietro potrebbe renderti inammissibile al supporto. Senza framework, puoi lavorare secondo i tuoi programmi. (Dipende se hai bisogno / desideri supporto o meno).

Pro: codice per l'azienda

• I frame non ti preoccupano del lavoro brusco e ti concentri sul codice che porta direttamente valore all'azienda.
• A volte gli aggiornamenti del framework che (funzionano) ti consentono di offrire nuove funzionalità ai tuoi utenti praticamente "gratuitamente". Soprattutto con i framework forniti con controlli personalizzati (come una griglia che la nuova versione può offrire un qualche tipo di ricerca / filtro).

vantaggi

• Tempi di sviluppo più rapidi
• Meno bug
• Sviluppo condiviso più rapido
• Supporto per la biblioteca
• Interazione DB semplice

svantaggi

• "Boxed in" al framework
• Spesso non flessibile quando si desidera estendere o modificare il comportamento di base
• "Errori di sventura" - errori che derivano dal nucleo o dall'architettura sottostante senza una buona traccia di origine. Un esempio perfetto sono gli errori di primavera quando si utilizza Grails.

Sostengo l'utilizzo di framework per tutti tranne il più semplice dei progetti. Se è necessario aggiungere un modulo di contatto a un sito HTML esistente, è possibile utilizzare un file PHP invece di passare a un framework.

Un paio di cose che vengono in mente sono ...

vantaggi

• Riutilizzo del codice: utilizzando un framework, si sta riutilizzando il codice testato e vero.
• Sviluppo / prototipazione rapidi.
• (spesso) convalida dell'input integrato che può essere considerato sicuro (dato che lo sviluppatore lo sta usando correttamente)

svantaggi

• Perdita di supporto. Mi viene in mente qui Symfony 1.4. Immagino che Symfony supporterà la 1.4 per un bel po 'di tempo, ma sapendo che la 2.0 non è compatibile con le versioni precedenti, la 1.4 sembra un vicolo cieco di supporto nei prossimi anni.
• Overhead; Utilizzando un framework, si eseguono migliaia di righe che potrebbero non essere applicabili alla propria applicazione specifica, ma che si applicano ad altri. Alcuni lo ritengono un ragionevole compromesso, e altri scelgono di scrivere il proprio codice da zero per le prestazioni.
• Utilizzando il framework sbagliato per le tue esigenze specifiche. Non tutti i framework sono creati allo stesso modo.

Tutto dipende dal framework che usi.

Se stai usando ASP.NET, sei in svantaggio: è un'astrazione che perde nel migliore dei casi , e nella peggiore delle ipotesi è doloroso fare cose che sono banali in altri framework che non nascondono il fatto che sei lavorando sul web.

ASP.NET MVC cerca di risolvere quel problema e lo fa molto bene.

I frame esistono per consentirci di dedicare più tempo al lavoro e meno tempo alla costruzione di impalcature. A questo proposito, non vedo alcun svantaggio, a meno che tu non voglia davvero passare il tempo a costruire impalcature.

Vorrei aggiungere alcuni punti.

• Uno dei maggiori problemi con i framework che trovo è che la gente smette di pensare. Vogliono solo usare il framework perché è bello o perché usano sempre il framework. Non smettono di pensare se l'uso è giustificato.
• Licenze, le persone sembrano semplicemente usare i framework senza davvero guardare le licenze. Ciò potrebbe avere implicazioni che non sono consapevoli. Oppure pensa a cosa succede quando la licenza cambia.
• Usando gran parte dello stesso tipo di framework. A volte possono essere molti framework che fanno praticamente la stessa cosa. Come azienda fai scelte colte e non hai un quadro diverso per ogni progetto.
• Tenere il passo con le nuove versioni potrebbe essere una sfida

Penso comunque che fare un po 'più di sforzo per valutare i framework, valutare le licenze, mantenere un elenco pulito di framework per uso e avere una strategia di versioning intelligente valga la pena se si considerano i vantaggi.

vantaggi:

• quando usi costantemente i framework il tempo di apprendimento per i progetti diminuisce per le persone che hanno già lavorato ai tuoi progetti.
• il tuo sviluppo più rapido
• i tuoi stessi sviluppatori

Parlo per esperienza personale negli ultimi 13 anni. Nella mia compagnia abbiamo usato i montanti, dopo una breve curva è stato grandioso. Nel mio prossimo abbiamo usato un'architettura che era per lo più opaca, in qualche modo simile a ma cresciuta, potevamo estenderla ma il codice principale era solo barattoli. E così via. negli ultimi 3 anni ho lavorato in una piccola azienda (numero di sviluppatori <30) ed era tutto nostro jsps, servlet ed ejbs. Guardando ai nostri molteplici clienti e alla ripetizione di jsps, nel 2012 è stato realizzato un filtro j2ee che imitava il 20% di struts2. Perché non usare stuts 2? Vorrei che lo avessimo fatto ma: non siamo riusciti a far passare il nostro capo architetto; non abbastanza esperienza o tempo.

Quindi abbiamo intercettato alcuni jps comuni usati dal nostro mini framework. Ora, quando ho avuto il tempo di passare attraverso un libro di 2 struts, vedo che ci siamo persi così tanto!

Utilizziamo alcuni grandi algoritmi, cache e UI, ma abbiamo perso molte ore e caricato con un sacco di codice che abbiamo un piano di 3 anni per andare in pensione.