Cette question se concentre sur l' extraction des avantages et des inconvénients de l'utilisation de cadres Web : tels que Cake PHP, Zend, jQuery, ASP.NET). Cette question est complètement indépendante de la langue . Permettez-moi de commencer par la notion de "Debout sur les épaules des géants ".

Avantages:

• Autorise les développeurs - en prenant des fonctionnalités qui auraient auparavant pris des centaines de lignes de code et en les compressant en une seule fonction, les développeurs peuvent intégrer des fonctionnalités plus complexes dans leurs sites Web.
• Permettre un développement plus rapide des applications - ceci est très pertinent pour les personnes qui ont besoin de sites Web créés dans une très petite fenêtre (quelqu'un a-t-il des exemples de cela?)
• Coûts inférieurs - permet aux programmeurs de répercuter les économies sur le client, une toute nouvelle gamme de clients générés qui souhaitaient un site Web mais qui auparavant ne pouvaient pas se permettre les coûts de développement plus élevés.

Désavantages:

• Perte de compréhension - en s'appuyant sur les fonctionnalités d'un framework, un développeur risque de perdre la compréhension du fonctionnement des choses (sous le capot).
• La falaise de configuration - une fois que vous allez plus loin que la configuration de votre framework, votre productivité baisse immédiatement, il peut être difficile d'implémenter des fonctionnalités en dehors d'une configuration de frameworks.
• Développeur tramlines - vous (le développeur) devez faire les choses comme le développeur veut que vous fassiez les choses.

Je me demande ce que les gens font de mes arguments et si quelqu'un est en désaccord avec eux? Aussi, si les gens ont des points supplémentaires, je serais reconnaissant.

Voici l'essentiel: il peut être difficile d'implémenter des fonctionnalités en dehors d'une configuration de frameworks.

Passons en revue cette hypothèse par hypothèse.

Perte de compréhension - en s'appuyant sur les fonctionnalités d'un framework, un développeur risque de perdre la compréhension de la façon dont les choses fonctionnent (sous le capot).

Faux. Vous ne perdrez jamais la compréhension du fonctionnement des choses. Les cadres ne sont pas magiques. Ce sont juste des codes pratiques que vous n'avez pas à écrire vous-même.

Croyez-le ou non, vous ferez des erreurs en utilisant le framework. Vous devrez déboguer jusqu'aux niveaux les plus bas de HTTP pour comprendre ce que vous avez fait de mal.

Vous ne perdrez jamais de vue ce qui se passe sous le capot. À moins, bien sûr, que votre framework soit si épique et parfait que vous n'aurez jamais de problème.

La falaise de configuration - une fois que vous allez plus loin que la configuration de votre framework, votre productivité baisse immédiatement, il peut être difficile d'implémenter des fonctionnalités en dehors d'une configuration de frameworks.

Cela n'a guère de sens.

Premier. Construire sans cadre peut transformer un travail trivial en une grande tâche de programmation qui comprend le test unitaire, le débogage, les diagnostics, le contrôle de la configuration et tout ce travail sans valeur réinventant les choses qui sont dans le cadre. Comment est cette "productivité"?

Seconde. Mettre en œuvre des choses en dehors du cadre est toujours beaucoup de travail parce que - ahem - implémenter quoi que ce soit en dehors d'un cadre est toujours beaucoup de travail. Cela n'a rien à voir avec le temps passé à apprendre et à configurer le framework. Implémenter quoi que ce soit en dehors du cadre est intrinsèquement difficile.

Développeur tramlines - vous (le développeur) devez faire les choses comme le développeur [framework] veut que vous fassiez les choses.

Correct. Et c'est souvent une bonne chose. Faire les choses de manière cohérente est plus précieux que de les faire à votre guise. Cela peut nécessiter «l'apprentissage» et la «compréhension», mais ceux-ci ont de la valeur.

Problèmes de sécurité - donner aux gens ces outils pour développer rapidement des sites Web professionnels est un risque potentiel, les gens peuvent rapidement créer des sites Web professionnels pour les entreprises frauduleuses.

Quelle? Cela n'a rien à voir avec le cadre. La fraude est une fraude, quels que soient les outils utilisés.

Inconvénient: perte éventuelle de soutien / perte de popularité

• S'il y a deux frameworks web qui font essentiellement la même chose et que le vôtre ne gagne pas, il y a une chance que le projet meure. Dans cette situation, vous devez conserver le framework vous-même (open source), réécrire l'application ou continuer sans mises à jour (source fermée).
• Selon le framework, vous pouvez être contraint de mettre à niveau votre application avec le calendrier de publication du framework. Prendre trop de retard pourrait vous rendre inéligible au soutien. Sans cadre, vous pouvez travailler à votre rythme. (Cela dépend si vous avez besoin / souhaitez une assistance ou non).

Pro: Code pour l'entreprise

• Les cadres vous permettent de ne pas vous soucier du travail de grognement et de vous concentrer sur le code qui apporte directement de la valeur à l'entreprise.
• Parfois, les mises à niveau du framework qui (fonctionnent) vous permettent de proposer de nouvelles fonctionnalités à vos utilisateurs pratiquement "gratuitement". Surtout avec les frameworks qui viennent avec des contrôles personnalisés (comme une grille que la nouvelle version peut offrir une sorte de recherche / filtre).

Les avantages

• Temps de développement plus rapide
• Moins de bugs
• Développement partagé plus rapide
• Prise en charge de la bibliothèque
• Interaction DB simple

Désavantages

• "Encadré" dans le cadre
• Souvent inflexible lorsque vous souhaitez étendre ou modifier le comportement du noyau
• "Erreurs de malheur" - erreurs qui proviennent du noyau ou de l'architecture sous-jacente sans bonne trace de leur origine. Un exemple parfait est les erreurs de printemps lors de l'utilisation de Grails.

Je préconise d'utiliser des cadres pour tous les projets, sauf les plus simples. Si vous devez ajouter un formulaire de contact à un site HTML existant, vous pouvez utiliser un fichier PHP au lieu de passer à un framework.

Quelques choses qui me viennent à l'esprit sont ...

Les avantages

• Réutilisation de code - en utilisant un framework, vous réutilisez du code testé et vrai.
• Développement / prototypage rapide.
• (souvent) validation d'entrée intégrée qui peut être présumée sécurisée (étant donné que le développeur l'utilise correctement)

Désavantages

• Perte de soutien. Je pense à Symfony 1.4. J'imagine que Symfony supportera 1.4 pendant un certain temps, mais sachant que 2.0 n'est pas rétrocompatible, 1.4 semble être une impasse de support dans les années à venir.
• Aérien; En utilisant un framework, vous exécutez des milliers de lignes qui peuvent ne pas s'appliquer à votre application spécifique, mais s'appliquer à d'autres. Certains considèrent cela comme un compromis raisonnable, et certains choisissent d'écrire leur code à partir de zéro pour des performances.
• Utiliser le mauvais cadre pour vos besoins spécifiques. Tous les cadres ne sont pas créés de manière égale.

Tout dépend du framework que vous utilisez.

Si vous utilisez ASP.NET, vous êtes désavantagé: c'est au mieux une abstraction qui fuit , et au pire, il est difficile de faire des choses triviales dans d'autres cadres qui ne cachent pas le fait que vous êtes travailler sur le web.

ASP.NET MVC cherche à résoudre ce problème, et il le fait si bien.

Des cadres existent pour que nous puissions passer plus de temps à faire le travail et moins de temps à construire des échafaudages. À cet égard, je ne vois aucun inconvénient, sauf si vous voulez vraiment passer du temps à construire des échafaudages.

Je voudrais ajouter quelques points.

• L'un des plus gros problèmes avec les cadres que je trouve est que les gens s'arrêtent pour réfléchir. Ils veulent juste utiliser le framework parce que c'est cool ou parce qu'ils utilisent toujours le framework. Ils n'arrêtent pas de penser si l'utilisation est justifiée.
• Licence, les gens semblent simplement utiliser des cadres sans vraiment regarder la licence. Cela pourrait avoir des implications dont ils ne sont pas conscients. Ou pensez à ce qui se passe lorsque la licence change.
• Utilisation de la plupart des mêmes types de frameworks. Parfois, il peut s'agir de nombreux cadres qui font à peu près la même chose. En tant qu'entreprise, vous faites des choix éclairés et n'avez pas de cadre différent pour chaque projet.
• Suivre les nouvelles versions pourrait être un défi

Pourtant, je pense que faire un peu plus d'efforts pour évaluer les frameworks, évaluer les licences, garder une liste claire des frameworks par utilisation et avoir une stratégie de versioning intelligente en vaut la peine lorsque vous considérez les avantages.

Avantages:

• lorsque vous utilisez régulièrement des frameworks, le temps d'apprentissage des projets diminue pour les personnes qui ont déjà travaillé sur vos projets.
• votre propre développement plus rapide
• vos propres développeurs d'autonomisation

Je parle d'expérience personnelle au cours des 13 dernières années. Dans mon entreprise, nous avons utilisé des entretoises, après une courte courbe, c'était génial. Dans mon prochain, nous avons utilisé une architecture qui était principalement opaque, quelque peu comme des struts mais développée, nous pouvions l'étendre mais le code principal n'était que des bocaux. Etc. au cours des 3 dernières années, nous avons travaillé dans une petite entreprise (nombre de développeurs <30) et il s'agissait de nos propres jsps, servlets et ejbs. En regardant nos multiples clients et la répétition de jsps, en 2012 devait faire un filtre j2ee qui imitait 20% des struts2. Pourquoi ne pas utiliser stuts 2? Je souhaite que nous ayons eu mais: n'a pas pu le faire passer notre architecte en chef; pas assez d'expérience ou de temps.

Nous avons donc eu des intercepteurs de jsps communs que notre mini framework utilisait. Maintenant, quand j'ai eu le temps de parcourir un livre Struts 2, je vois que nous avons tellement manqué!

Nous utilisons des algorithmes et des caches et une interface utilisateur géniaux, mais nous avons perdu beaucoup d'heures et surchargés de beaucoup de code que nous avons un plan de retraite de 3 ans.