Rendre la vie meilleure en n'utilisant pas les frameworks Web Java? [fermé]


Je suis tellement fatigué d'avoir à apprendre encore un autre framework Web Java tous les deux jours.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC pour n'en nommer que quelques - uns-tous ces innombrables frameworks tentent de résoudre les mêmes problèmes. Cependant, aucun d'entre eux ne résout vraiment les problèmes fondamentaux - c'est pourquoi il y en a toujours de plus en plus de nouveaux tout le temps.

La plupart ont l'air très brillant et brillant à la première impression parce qu'ils simplifient faire des choses simples.
Mais comme dès qu'il s'agit de la mise en œuvre d'un cas d'utilisation du monde réel, on rencontre des problèmes.
Souvent, les frameworks ne fournissent aucune aide mais en entravent un et limitent les options en forçant les choses à être implémentées selon la logique et l'environnement propres aux frameworks.

En bref, je vois les inconvénients suivants lors de l'utilisation d'un framework:

  1. Il y a surtout une courbe d'apprentissage abrupte et vous devez d'abord comprendre des concepts parfois assez académiques et savoir la signification et l'emplacement d'un tas de fichiers de configuration avant de commencer.
  2. La documentation est généralement plus ou moins horrible, soit il manque une référence en ligne accessible au public, soit elle est désuète, confond différentes versions incompatibles ou tout cela ensemble et ne fournit souvent aucun exemple utile.
  3. Le cadre se compose de zillions de classes, ce qui rend pratiquement impossible de comprendre l'utilisation prévue uniquement en parcourant le source.
  4. Par conséquent, vous devez acheter des livres de type "XYZ en action pour les nuls en 21 jours" qui ont une mauvaise interface utilisateur car ils manquent d'une recherche en texte intégral et sont lourds à transporter.
  5. Pour vraiment utiliser l'un de ces frameworks, vous devez apprendre par cœur comment les choses peuvent être faites comme le framework l'exige en vous souvenant des classes et des noms de méthodes adéquats jusqu'à ce que votre tête soit pleine d'informations stupides et inutiles que vous ne pouvez utiliser pour rien autre.
  6. Il y a une grande surcharge, ce qui ralentit les performances de vos applications et rend votre cerveau engourdi lorsque vous essayez de comprendre ce qui se passe réellement.
  7. Dans le monde réel, il n'y a généralement pas de temps pour se familiariser avec quelque chose de nouveau à cause de la pression d'être productif. En conséquence de cette approche d'apprentissage par la pratique on ne cherche toujours que le moyen le plus rapide de faire la tâche suivante plutôt que de vraiment comprendre le nouvel outil et c'est possibilité.
  8. L'argument selon lequel suivre une norme permettrait aux personnes qui sont nouvelles dans un projet de démarrer rapidement n'est pas valide à mon avis car chaque projet utilise un cadre différent même au sein de la même entreprise (du moins dans mon cas).

Il me semble que la citation suivante d'Albert Einstein convient ici très bien:

"Nous ne pouvons pas résoudre les problèmes en utilisant le même type de pensée que nous avons utilisé lorsque nous les avons créés."

Retour dans mon bon vieux temps de codage PHP quand le codage était encore amusant et productif, j'avais l'habitude d'écrire mes propres frameworks pour la plupart des choses et de les copier-coller et de les adopter d'un projet à l'autre.
Cette approche a très bien fonctionné, ce qui a entraîné un développement rapide, pas de surcharge du tout et un framework qui était en fait plus puissant que la plupart des frameworks Java, mais avec seulement quelques centaines de lignes de code dans un seul fichier plus quelques règles mod_rewrite simples.
Cela ne résolvait certainement pas tous les problèmes de développement web, mais il était simple, rapide et droit au but.
Bien que parfaitement ajusté aux exigences du projet actuel, il était également facile à étendre et avait une très haute performance en raison de zéro frais généraux.

Alors pourquoi tous ces tracas avec l'utilisation de ces frameworks, pourquoi ne pas les jeter tous et revenir aux racines?
Que dois-je dire à mon patron quand nous commençons demain le prochain projet avec un nouveau framework?
Ou y a-t-il peut-être des cadres qui vraiment faire une différence?
Ou certains avantages cachés que j'ai ignorés?

Author: skaffman, 2009-04-23

13 answers

De retour dans mes bons vieux jours de codage PHP quand le codage était encore amusant et productif, j'ai utilisé pour écrire mon propre cadres pour la plupart des choses et juste copie-collé et adopté un projet à l'autre. Cette approche payé très bien, résultant en rapide développement, pas de frais généraux du tout et un cadre qui était en fait plus puissant que la plupart des frameworks Java là-bas

Pardonne-moi de croire que pas une seconde.

, Mais avec seulement quelques centaine de lignes de code dans un seul fichier plus quelques simples les règles de mod_rewrite. C'est certainement ne résolvait pas tous les problèmes du web du développement, mais c'était simple, rapide et droit au but.

Donc, fondamentalement, vous avez développé votre propre cadre au cours des mois ou des années, adapté à vos propres besoins, et pourrait travailler très rapidement avec elle parce que vous le saviez intimement.

Et pourtant, vous ne pouvez pas comprendre pourquoi les autres font de même et essaient ensuite de transformer le résultat en quelque chose utilisable par tout le monde?

Où est ce grand cadre que vous avez développé? S'il est si puissant et facile à utiliser, où sont les communautés dédiées, les milliers d'utilisateurs et les centaines de sites développés avec lui?

Chaque projet utilise un même au sein de la même entreprise (au moins dans mon cas)

Eh Bien, c'est votre problème. Pourquoi jeter l'expertise acquise avec chaque cadre après chaque projet?

L'idée est de choisir un cadre et de s'y tenir sur plusieurs projets afin que vous y soyez compétent. Vous devez investir du temps pour apprendre le cadre, puis cela vous fait gagner du temps en vous permettant de travailler à un niveau supérieur.

 35
Author: Michael Borgwardt, 2009-04-23 12:28:01

Le problème avec la création de votre propre framework est que vous ferez toutes les mêmes erreurs que tous les frameworks établis ont déjà trébuché et résolus. Cela est particulièrement vrai quand il s'agit de la sécurité.

Il suffit de demander à Jeff et aux gars ce qu'ils devaient considérer lors de la mise en œuvre de l'ADM dans stack overflow. Je préfère utiliser ce qu'ils ont produit dans un projet plutôt que de l'implémenter à partir de zéro. C'est juste un exemple.

 20
Author: Martin OConnor, 2009-04-23 11:23:32

Le problème n'est bien sûr pas seulement avec les frameworks Java. J'ai perdu le compte du nombre de projets C++ MFC que j'ai vus patauger en essayant d'intégrer leurs exigences dans le modèle de document/Vue (qui ne fonctionne vraiment que pour les éditeurs de texte et graphiques-les applications de base de données sont particulièrement difficiles à chausse).

Le secret d'une utilisation réussie du framework est de changer votre application pour qu'elle corresponde au framework, et non l'inverse. Si tu ne peux pas faire ça, ne pense même pas d'utiliser le cadre - il finira par être plus de travail que si vous aviez écrit l'application à partir de zéro avec l'aide de quelques bonnes bibliothèques utilitaires fiables et bien documentées.

 11
Author: , 2009-04-23 11:24:28

Voici une citation de Kevdu fil Quelle est votre opinion de programmation la plus controversée? qui correspond vraiment bien ici:

Je pense que toute la chose des cadres "d'entreprise" est de la fumée et des miroirs. J2EE,. NET, la majorité des frameworks Apache et la plupart des abstractions pour gérer de telles choses créent beaucoup plus de complexité qu'elles n'en résolvent.

Prenez n'importe quel OMR Java ou. NET régulier, ou n'importe quel framework MVC soi-disant moderne pour lequel "magique" pour résoudre des tâches fastidieuses et simples. Vous finissez par écrire d'énormes quantités de passe-partout XML laid qui est difficile à valider et à écrire rapidement. Vous avez des API massives où la moitié d'entre elles sont juste pour intégrer le travail des autres API, des interfaces impossibles à recycler et des classes abstraites qui ne sont nécessaires que pour surmonter l'inflexibilité de Java et C#. Nous n'avons tout simplement pas besoin de la plupart de cela.

Que diriez-vous de tous les différents serveurs d'applications avec leur propre descripteur sacrément syntaxe, la base de données trop complexe et les produits groupware?

Le point de ceci n'est pas cette complexité==mauvaise, c'est cette complexité inutile==mauvaise. J'ai travaillé dans des installations d'entreprise massives où une partie était nécessaire, mais même dans la plupart des cas, quelques scripts locaux et une interface Web simple sont tout ce qui est nécessaire pour résoudre la plupart des cas d'utilisation.

J'essaierais de remplacer toutes ces applications entreprenantes par des frameworks Web simples, des DBS open source et une programmation triviale construire.

 11
Author: dankoliver, 2017-05-23 12:13:35

Donc vous dites que nous devrions traiter dans les sockets et HTTP chaque fois que nous voulons construire une application Web!

Le conteneur de servlet lui-même peut être considéré comme un framework, car il gère tous ces détails désordonnés, et vous laisse écrire des Servlets/Filtres/écouteurs beaucoup plus simples (ie: 'extensions' du framework spécifique à votre application).

Tout ce que n'importe quel framework essaie de faire est de séparer le code banal, reproductible, sujet aux erreurs, legwork du code spécifique à l'application amusante code.

Cependant, pour une petite application, vous pouvez simplement avoir une approche Model 2 MVC qui utilise uniquement des JSP et des Servlets.

Exemple:

class MyController extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
        MyBean model = // do something
        request.setAttribute("model", model);
        request.getRequestDispatcher("/view.jsp").forward(request, response);
    }
}

Ensuite, à mesure que votre application devient plus sophistiquée, vous pouvez envisager d'utiliser Spring MVC pour fournir un couplage plus lâche (et donc plus flexible) des contrôleurs, des résolveurs de vue, etc..

 9
Author: toolkit, 2009-04-23 12:18:15

Je partage votre douleur face à un autre cadre qui ne fait pas l'affaire.

Ayant survécu à dix ans de jsp, struts, EJB, EJB2, struts2, jsf et maintenant plus récemment tous les nouveaux services web framworks, les horreurs xslt et les premiers cauchemars wsdl, j'en ai vraiment marre.

Il y a un certain nombre de problèmes avec les cadres. Ils fuient vous devez donc en savoir plus-pas moins, les frameworks internes ont des coûts énormes, l'utilisation de frameworks externes coûte aussi (mais beaucoup moins), car ils livrent rarement, et vous finissez par écrire des morceaux enourmus de configuration xml et passez des jours à corriger les erreurs de casse et d'orthographe que vous aviez vues immédiatement dans votre contenu préféré en aidant l'éditeur de code.

Peut - être que la réponse est de trouver des boîtes à outils moins pompeuses qui tentent de résoudre un problème sans redéfinir le monde, mais c'est difficile aussi car le modèle d'application fondamental (html sur http) est maladroit-au mieux.

Ajouter le fait qu'il semble y avoir beaucoup decomplicateurs autour, des gens qui semblent être obsédés par le commerce de problèmes simples ennuyeux à des problèmes complexes (mais difficiles) interesting ( peut-être une variante de l'Axiome d'Eric Sink de développement de logiciels mentionné ci-dessus.)

Ajoutez l'orgueil des développeurs qui savent tout et n'hésitez pas à écrire un nouveau framework pour résoudre tous les problèmes difficiles pour vous, Seulement qu'ils ne peuvent pas, laissant 10% à gauche, seulement beaucoup plus difficile à résoudre maintenant.

Je n'ai pas d'expérience. NET, mais le. NET le monde semble être moins encombré de théoriciens et de complicateurs, et peut-être que la puanteur persistante de VB les effraie, mais chaque fois que j'entends quelqu'un me dire qu'ils ont passé 1500 heures sur leur configuration maven (bonjour?), j'envisage sérieusement de supprimer "java" de mon CV.

...quelle était encore la question? Existe-il des cadres qui font une différence?

EDIT - ajout de rayures et de QueryDSL.

J'essaierais Stripes ou GWT avec QueryDSL + Hibernate ou OpenJPA (avec des annotations) juste pour le fait que vous développez réellement en Java, et essayez de limiter autant que possible l'utilisation des services Web wsdl-first, des frameworks xml-centric, EJB et ESBs (pas la bière).

 7
Author: KarlP, 2011-12-27 17:35:00

Eh bien, ne fait pas la même chose tous les jours un peu ennuyeux...?

 3
Author: Arjan, 2009-04-23 11:01:09

J'ai déjà dû travailler sur un projet essayant de l'implémenter dans JSF. C'était un cauchemar.

La majeure partie du temps de travail a été consacrée à la compilation des choses. Le fait que pas moins de la moitié de ce qui a été compilé n'a pas fonctionné était une autre histoire. Presque pas de tutoriels. La documentation est essentiellement une exportation de code source automatisée sans commentaires humains. Comment peut-on s'attendre à travailler comme ça?

De plusieurs frameworks que nous avions vus, seul Sun était capable de créer un nouveau projet qui est compilable du tout! L'autre ne pouvait produire que des tas de choses, il a fallu plusieurs jours pour sonner à un état compilable.

Le web était presque silencieux. Pour toute recherche là-bas, nous pas plus de 20 pages de résultats de recherche, avec utile premier 1-3. Dans ce qui a été trouvé pertinent, une moitié des gens pleurait à l'aide, l'autre moitié a déclaré qu'ils avaient pleuré à l'aide, personne n'est venu, ils ont perdu du temps et de l'intérêt et ont abandonné cette technologie.

Donc nous avons passé du temps et seulement fait quelque chose de simple qui pourrait ont été faites en quelques semaines avec ASP.NET par exemple.

Ensuite, nous avons examiné les frameworks JSF alternatifs. À notre grande surprise, nous les avons tous trouvés tout à fait incompatibles.

Sans surprise du tout, nous avons rejoint les rangs de ceux qui ont également abandonné JSF.

 3
Author: User, 2009-04-23 11:33:30

Considérons le point compteur. Je travaille dans un magasin en ce moment qui n'utilise aucun framework au-delà de la norme JSP. Tout le monde a une façon différente de faire les choses et nous sommes très laxistes sur des concepts comme le désassemblage et les problèmes de sécurité comme la validation.

Bien que je ne pense pas que l'utilisation des frameworks fasse automatiquement de vous un meilleur codeur, je pense qu'en utilisant un modèle de conception standard implémenté par la plupart des frameworks et en ayant un accès facile aux fonctions utilitaires comme la validation, je pense les chances sont que vous allez être obligé de coder jusqu'à une certaine norme.

Dans la conception d'applications Web, vous n'inventez pas la roue à chaque fois, vous finissez donc par déployer votre propre solution vers des tâches courantes ou en utilisant un framework. Je suppose qu'en utilisant un framework couramment utilisé plutôt que de lancer le vôtre, vous obtiendrez un code sous-jacent bien testé et flexible.

Il n'y a rien de mal à lancer votre propre solution en tant qu'universitaire poursuite mais j'accepte que il y a des gens qui mettent beaucoup plus de temps dans une solution robuste que je pourrais peut-être dépenser. Prenez log4j par exemple, assez facile à rouler votre enregistreur, mais log4j est bien testé et entretenu et ils ont pris le temps d'améliorer la flexibilité et les performances à un degré que la plupart de vos propres enregistreurs ne peuvent pas toucher. Le résultat final est un framework robuste mais aussi assez simple à utiliser même dans les applications les plus élémentaires.

 3
Author: James McMahon, 2010-11-30 21:03:52

Ce qui a fonctionné pour moi, c'est que vous ne devriez pas simplement apprendre n'importe quel framework Web dont vous entendez parler, y jeter un œil, voir s'il vous permet de coder confortablement, demander à stackoverflow ou sur des forums pour voir ses avantages et ses inconvénients, puis l'apprendre et l'apprendre bien et simplement rester avec N'importe lequel des webframeworks que vous avez écrits est bon en soi et amusant à travailler si vous savez "VRAIMENT" ce qu'il fait. si vous ne le faites pas vous errez simplement dans un désert sans boussole! J'ai également trouvé que le livre 21 days est un moyen sûr pour vous de NE PAS maîtriser un framework ou une technologie. Docs est sûrement quelque chose à considérer lors de l'adoption d'un f/w, cela aide également si vous regardez vous-même autour du code (en fait, c'est ce qui m'aide le mieux lorsque je suis confronté à un comportement que je trouve bizarre.

1 - Alors pourquoi tous ces tracas avec l'utilisation de ces frameworks, pourquoi ne pas les jeter tous et revenir aux racines?

Si vous revenez aux racines, vous réécrivez le code qui le fait la même chose encore et encore + la plupart de ces f / w étant open source, ils sont probablement mieux lotis avec la maintenance que vous ne le feriez seul avec votre propre f / w.

2-Que dois-je dire à mon patron quand nous recommencerons demain le prochain projet avec un nouveau framework?

C'est la première fois que je travaille avec ce f/w Je ne vois pas pourquoi devrions-nous utiliser ce f/w Je connais déjà X et je suis vraiment bon dans ce domaine. bare à l'esprit le coût de m'apprendre ce f/w, le coût de la reprise qui doit être fait en raison de mon ignorance d'un tel f/w. Je pense que nous ferions mieux d'utiliser X, si c'est une exigence spécifique, nous devrions nous battre pour cela et ne le faire que si nous devons vraiment énoncer les notes précédentes.

Ou y a-t-il peut-être des frameworks qui font vraiment la différence?

Seuls ceux qui s'adressent à la façon dont vous pensez pas à la façon dont vous écrivez du code (pensez à struts à son âge d'or en appliquant le modèle MVC).

Ou certains avantages cachés que j'ai ignorés?

Ne peut pas penser à tout tbh.

 2
Author: MahdeTo, 2009-04-23 11:15:27

Vous avez le même problème en PHP: plus de frameworks que vous n'avez de doigts pour les compter, chacun étant le meilleur et le plus grand (bien que vous ayez quelques conseils: conception PHP5 pure contre compatibilité PHP4, philosophie Rails (hiérarchie de dossiers inflexible, code généré automatiquement) contre approche bibliothèque...) et vous passez plus de temps à chercher et à explorer les possibilités qu'à écrire votre code!
Mais en PHP, il permet de pré-résoudre des problèmes courants, comme le support I18N, l'intégration de plugins, la gestion de sessions et authentification, abstraction de base de données, modèles, support Ajax, etc. Éviter de réinventer la roue sur chaque projet, et de tomber dans des pièges communs pour les débutants.

Bien sûr, il y a aussi quelques conseils pour les frameworks Java: grand ou petit? bien documenté ou non? largement utilisé ou confidentiel? pour les fans XML ou non? Etc.
Je suppose que la plupart des frameworks visent de grands projets, où le temps d'apprentissage n'est pas un gros problème, l'évolutivité et la facilité de déploiement sont importantes, etc. Elles le sont probablement exagéré pour les petits projets.

Il y a aussi une tendance dans de tels cadres à viser à faire un ensemble cohérent de bibliothèques faiblement couplées plutôt qu'un cadre monolithique. C'est le cas, dans le monde PHP, pour le framework Zend (certains nient même l'utilisation du mot 'framework'...).
Il résout donc la question de "résoudre les problèmes communs" sans se gêner.

 1
Author: PhiLho, 2009-04-23 11:18:25

Donc vous pensez que c'est mieux si nous inventons tous la roue dans chaque projet?

Vous pourriez voir un excès de frameworks comme un problème, et cela rend plus difficile le choix de votre propre ensemble. Mais d'un autre côté, vous n'avez pas à essayer de chacun; et même si vous le faites, vous vous retrouverez préférant certains d'entre eux. Vous aurez un framework favori pour ORM, un autre pour le développement Web, IoC, etc.

Il est utile de lire sur certains forums pour savoir quels sont les plus populaires; ils doivent être populaire pour une raison, et même si ce n'est pas la bonne raison (comme être techniquement supérieur, peut-être que c'est populaire juste parmi les gestionnaires à cause de la surcharge de mots à la mode ou autre), la connaissance de ce framework sera utile car vous pourrez participer à plusieurs projets qui l'utilisent.

De plus, utiliser un framework au lieu d'écrire le vôtre vous évitera beaucoup de problèmes. Les bogues ne sont pas toujours trouvés et résolus par les auteurs; cela est souvent fait par les utilisateurs du framework. Vous dit que vous vous êtes retrouvé avec votre propre framework privé en PHP; je parie que ce n'était pas sans bug, mais peut-être que vous ne le saviez pas puisque vous étiez le seul utilisateur et le seul codeur.

 0
Author: Chochos, 2009-04-23 14:53:38

Cependant je suis en désaccord sur certains points que vous avez mentionnés, mais je suis d'accord avec vous concernant le travail fastidieux.

Oui, toutes les applications Web concernent les pages affichant des formulaires, la collecte de données, la validation, l'envoi des données pour le stockage dans la base de données, le filtrage des données stockées par des formulaires de recherche et l'affichage du résultat dans des tables et la sélection d'un ou plusieurs enregistrements pour manipulation (CRUD, ou actions commerciales

Cependant je travaille pour seulement 4 ans plus bien sûr mes 4 années d'études universitaires. Je pense que ce type de développement est ennuyeux car vous n'inventez pas d'algorithmes, bien sûr, vous êtes heureux lorsque vous découvrez un nouveau framework et serez plus heureux si vous intégrez l'un des moteurs d'IA dans votre application, mais à la fin, je pense que ce travail est factice, ou disons le travail de la machine, alors pourquoi

Oui un autre cadre ;) MDA Model Driven Architecture, en bref, c'est transformer du PIM (Modèle Indépendant de la Plate-forme) au PSM (Modèle spécifique à la plate-forme), c'est-à-dire par exemple de l'UML au code.

Et cela peut résoudre votre problème de courbe d'apprentissage et de changements technologiques car vous n'aurez besoin que d'être bon en modélisation, car il existe des frameworks qui implémentent les spécifications MDA telles que AndroMDA car il a des cartouches qui prennent les Diagrammes de classe, les cas d'utilisation, les Diagrammes de séquence et les Diagrammes cartographie, Printemps/EJB, JSF/Struts, .NET code.

Bien sûr, de tels frameworks ne généreront pas 100% du code mais généreront un gros pourcentage, et bien sûr, vous demanderez où ce framework résoudra des scénarios complexes et délicats d'exigences? aujourd'hui, je dirai non, demain oui.

Alors pourquoi vous et moi n'investissons pas dans le développement de ce grand cadre.

 0
Author: Ali Abdel-Aziz, 2009-04-23 20:41:06