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

Analizziamo questa ipotesi per ipotesi.

Lost Understanding - by relying on the features of a framework a developer is in danger of loosing understanding on how things work (underneath the hood).

False. Non perderai mai la comprensione di come funzionano le cose. I quadri non sono magici. Sono solo un codice utile che non devi scrivere da solo.

Che ci crediate o no, farai degli errori usando la struttura. Dovrai eseguire il debug fino ai livelli più bassi di HTTP per capire cosa hai sbagliato.

Non perderai mai di vista cosa sta succedendo sotto il cofano. A meno che, naturalmente, il tuo quadro sia così epico e perfetto che non hai mai un problema.

The configuration cliff - once you go further than the configuration of your framework your productivity drops right off, it can be difficult to implement features outside of a frameworks configuration.

Questo ha poco senso.

Per prima. Costruire senza un framework può trasformare un lavoro banale in una grande attività di programmazione che include test unitari, debugging, diagnostica, controllo della configurazione e tutto il resto del lavoro senza valore che reinventa le cose contenute nel framework. Com'è quella "produttività"?

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

Developer tramlines - you (the developer) has to do things the way that the [framework] developer want you to do things.

Una corretta. E questa è spesso una buona cosa. Fare le cose in modo coerente è più prezioso che farle come preferisci. Potrebbe richiedere "apprendimento" e "comprensione", ma questi hanno un valore.

Security issues - giving people these tools to develop professional looking websites fast is a potential risk, people can quickly create professional looking websites for fraudulent companies.

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

vantaggi

• Tempo di sviluppo più rapido
• Meno errori
• Sviluppo condiviso più rapido
• Supporto della libreria
• Interazione Easy DB

Svantaggi

• "Inserito" nel framework
• Spesso inflessibile quando si desidera estendere o modificare il comportamento di base
• "Errori di doom" - errori che derivano dall'architettura core o sottostante senza una buona traccia di ritorno al punto da cui sono originati. Un esempio perfetto sono gli errori Spring quando si usa Grails.

Io sostengo l'utilizzo di framework per tutti, eccetto i progetti più semplici. 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 ti vengono in mente sono ...

vantaggi

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

Svantaggi

• Perdita di supporto. Mi viene in mente Symfony 1.4. Immagino che Symfony supporterà 1.4 per un po 'di tempo, ma sapendo che il 2.0 non è retrocompatibile, 1.4 sembra un supporto senza uscita nei prossimi anni.
• Overhead; Utilizzando un framework, si eseguono migliaia di righe che potrebbero non essere applicabili alla propria applicazione specifica, ma si applicano ad altri. Alcuni ritengono questo un compromesso ragionevole, e alcuni scelgono di scrivere il loro codice da zero per le prestazioni.
• Utilizzare la struttura sbagliata per le tue esigenze specifiche. Non tutti i framework sono creati allo stesso modo.

Dipende tutto dal framework che usi.

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

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

Esistono quadri in modo da poter dedicare più tempo alla realizzazione del lavoro e meno tempo a costruire scaffalature. A tale riguardo, non vedo alcun svantaggio, a meno che non vogliate davvero passare il tempo a costruire impalcature.

Vorrei aggiungere alcuni punti.

• Uno dei maggiori problemi con i framework che trovo è che le persone smettono di pensare. Vogliono solo usare il framework perché è bello o perché usano sempre il framework. Non si fermano a pensare se l'uso è giustificato.
• Licenziando, le persone sembrano utilizzare i framework senza realmente guardare alle licenze. Ciò potrebbe avere implicazioni che non sono consapevoli. Oppure pensa a cosa succede quando la licenza cambia.
• Uso di gran parte dello stesso tipo di framework. A volte il loro può essere un sacco di quadri che in realtà 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

Tuttavia ritengo che mettere un po 'più impegno 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 quando si considerano i Vantaggi.

I vantaggi:

• quando usi coerentemente 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 sviluppatori autorizzati

Parlo per esperienza personale negli ultimi 13 anni. Nella mia compagnia abbiamo usato puntoni, dopo una breve curva è stato fantastico. Nella mia successiva abbiamo usato un'architettura che era per lo più opaca, un po 'come un montone ma cresciuta, potremmo estenderla ma il codice base era solo giare. E così via. negli ultimi 3 anni ho lavorato in una piccola azienda (numero di sviluppatori & nd; 30) ed erano tutti i nostri jsps, servlet ed ejbs. Guardando i nostri numerosi clienti e la ripetizione di jsps, nel 2012 è stato creato un filtro j2ee che mimasse il 20% delle puntine2. Perché non usare stuts 2? Vorrei averlo ma: non riuscivo a far passare il nostro capo architetto; non abbastanza esperienza o tempo.

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

Usiamo alcuni algoritmi e cache e interfaccia utente grandiosi ma abbiamo perso molte ore e sovraccaricato di un sacco di codice che abbiamo un piano di 3 anni per andare in pensione.