Grails en vaut-il la peine?
C'est à moitié diatribe, à moitié question.
Vaut-il la peine d'utiliser Grails? J'essaie de développer une application Web basée sur une base de données relativement simple. Mon expertise est en Java, donc naturellement Grails semblait être un bon choix. Au début, je pensais utiliser Spring, JPA et Hibernate, mais je l'ai déjà utilisé et j'ai rencontré toutes sortes de travaux de configuration et de codage fastidieux. Grails s'annonce comme résolvant cela.
Ma plus grande frustration avec Grails est toutes les petites choses qui ne fonctionnent pas. Ce que je veux dire, c'est que cela ne fonctionne pas comme on pourrait le penser intuitivement. C'est très rugueux sur les bords. Je rencontre constamment des problèmes. Parfois, c'est mon manque de compréhension Grails - d'autres fois, j'ai découvert des bugs Grails légitimes.
Un problème majeur est le manque d'une bonne intégration Eclipse. Il existe un plugin Groovy et Grails, mais il ne fait pas grand-chose d'autre que la mise en évidence de la syntaxe. Appeler Groovy à partir de Java et vice versa est très pénible pour configurer . Ne pas avoir une bonne IDE support est un gros problème).
Ce qui se passe, c'est que je m'assois pour essayer de développer mon application Web. À la fin de la journée, je me rends compte que j'ai passé environ 85% de la journée à déboguer les problèmes liés à Grails. Si ce n'est pas un problème Eclipse, c'est chargement rapide , récupération dans la vue , relations un-à-plusieurs , bizarre comportement de bogue de fichier vide , n étrange bug de propriété/getter - ça continue encore et encore. Ce n'est qu'un échantillon des problèmes que j'ai rencontrés aujourd'hui. Ma dernière rencontre avec Grails a soulevé tout un tas de problèmes différents.
Je me demande parfois si ça vaut le coup. Je suis curieux de savoir si d'autres ont vécu cela. Y a-t-il des gens qui utilisent Grails pour lancer de manière productive une application Web? Existe-t-il d'autres cadres de développement Web rapide que je devrais envisager?
Nous avions une équipe de 12 personnes tous seniors chevronnés Java qui ont appris Grails à partir de 0.6B et nous travaillons tous sur des projets basés sur Grails. Je ne reviendrais pas sur Java volontiers, et nous sommes tous soulagés d'avoir cassé le dos pour savoir comment arriver rapidement avec une application Grails.
Ce fut une lutte, ce n'était pas facile et il y avait/est une frustration.
Néanmoins, nous avons livré quelque chose très rapidement compte tenu de nos efforts continus. Il y a des bugs, dont beaucoup ont des solutions.
J'ai entendu parler de plusieurs exemples de développeurs qui sont bons à Java essayant de plonger dans des incantations profondes et complexes de projets Grails. Nous avons évité tous Java et sommes devenus purs) -Grails et Groovy. Nous nous sommes assurés de commencer simplement, de construire la complexité de la manière la plus simple et la plus pratique possible. Nous n'avons pas osé plonger au plus profond et espérons que nos connaissances Java Java étaient suffisantes) pour nous porter.
Nous avions finalement créé quelque chose d'énorme et de complexe qui fonctionnait fabuleusement et qui fonctionnait bien plus rapidement que d'écrire une version Java/Spring/Hibernate pure; et c'est sans décent IDE support et une situation bien pire en termes de bugs qu'aujourd'hui.
En ce qui concerne le support Eclipse, le seul véritable IDE à utiliser pour Grails/Groovy est Intellij - le support Eclipse est loin derrière, malheureusement: j'étais un amoureux d'Eclipse et je suis loin d'être un converti Intellij - le support Grails/Groovy souffle tout le reste.
Oui, Grails est immature par rapport au printemps peut-être. Ou Hibernate. Et je parierais qu'au cours des 1,5 premières années de leur existence, ils étaient tout aussi chargés de problèmes.
Cela étant, il vous incombe de veiller à garder la complexité au minimum absolu, à tester soigneusement en premier (à notre avis) et à développer la complexité progressivement et avec soin.
Il n'y a pas de solution de code rapide avec Java une fois que vous impliquez Spring/Hibernate dans la pile. La complexité que Grails incarne est le reflet de la complexité de Spring/Hibernate. Si vous sentez que votre temps est mieux dépensé le faire avec du Java pur, je ne dirais pas le contraire .. J'ai toujours mes WTF mais maintenant que la courbe d'apprentissage abrupte est derrière moi, je pense que je vais m'en tenir à Grails.
J'aime beaucoup rédiger une application Grails pour deux raisons:
- Je n'ai pas besoin d'utiliser Java
- Je peux utiliser Java
Je pense qu'après s'être familiarisé avec les Grails, on fait ses choses très rapidement et avec élégance.
Voilà pour le côté positif. Le côté négatif est la performance, qui me frappe sur deux aspects: le déploiement et le développement piloté par les tests.
Je n'ai pas réussi à exécuter plus de 3 applications Grails sur un seul serveur (loué), car j'ai rapidement atteint les limites de mémoire et de performances. Il y a tout simplement trop de cadres inclus.
De plus, le testeur de Grails ne vaut pas ce nom. Lorsque je lance des tests unitaires, ils doivent être effectués en un instant, pas en 10 à 20 secondes. Je me retrouve donc tout le temps à écrire de la logique métier en simple Java, car je peux la tester beaucoup plus rapidement. Mais je suppose que cela peut être résolu avec une meilleure intégration dans le IDE (Eclipse).
Je pense que le soutien de Spring aux Grails va être un grand coup de pouce. Si quelqu'un peut le faire passer CRUD sur le Web, ce sont ces gars-là.
Je pense aussi qu'il atteint une masse critique. Il y a plusieurs nouveaux livres qui arriveront sur le marché en 2009. Je pense que ceux-ci aideront le taux d'adoption.
Je suis entièrement d'accord avec les sentiments des affiches originales.
Nous sommes un Java + Spring shop et en avons profité pour essayer Grails. Nous avons d'abord créé une toute petite application de test qui s'est avérée assez simple à faire et qui a plutôt bien fonctionné. Le principal les problèmes que nous avons rencontrés ici étaient dus à notre manque de connaissances avec Groovy et Grails.
Suite à ce succès (regain de confiance), nous avons décidé de tenter un projet légèrement plus important. Cela a été une expérience beaucoup plus douloureuse. Comme mentionné par d'autres, nous avons découvert toutes sortes de bugs et de problèmes qui n'étaient pas immédiatement apparents à la surface. Les cycles de redémarrage de l'application deviennent extrêmement douloureux et à moins que vous n'ayez une très bonne couverture de test, c'est un cauchemar de faire une sorte de refactorisation.
Vraiment frustrant, le code échoue sans un seul message d'erreur! Cela ne fonctionne tout simplement pas et vous ne savez pas pourquoi?
J'aime la facilité d'utilisation des plugins pour JMS, Quartz et Remoting pour n'en nommer que quelques-uns. Élimine beaucoup de XML fastidieux.
J'aime presque GORM pour sa simplicité même si nous avons également eu plusieurs problèmes.
Je n'aime pas la nature vaguement typée de Groovy et le fait que vous devez exécuter votre application juste pour pouvoir attraper un tas d'erreurs, me rappelle trop de PHP ou Rails.
À la fin de la journée, nous nous demandons s'il est possible d'écrire un logiciel complexe à gérer en utilisant Grails ...
Nous avons une application Grails sur le point d'entrer en production ... alors nous verrons.
Nous utilisons grails + sur la couche web + Java avec hibernate et spring sur la couche service. Ce sont les trois couches classiques (web, logique, données) où le web est grails et la logique est comme d'habitude en Java, nous utilisons des objets bean qui représentent les données entre différentes couches.
Cela fonctionne assez bien et c'était la meilleure solution pour notre cas car les objets bean étaient déjà là, ainsi que la structure de la base de données. D'après notre expérience, je pense que Grails a une grande valeur en tant que couche de présentation Web, mais je m'en tiendrai à Java pour écrire les règles métier et conserver les données d'application - car Grails "est" Java , toute l'intégration Grails-Java est assez simple.
Nous utilisons Eclipse pour développer l'application Grails et sa mauvaise intégration, comme on l'a dit ici. Mais, comme le suggère un autre développeur, nous exécutons l'application Grails à partir de la ligne de commande et utilisons uniquement Eclipse pour enregistrer les fichiers source, et cela fonctionne plutôt bien, car l'application est mise à jour à la volée.
Je ne me sens pas encore à l'aise pour utiliser des grails ailleurs que dans la couche de présentation.
Je suis totalement avec toi! Grails semble toujours si rugueux sur les bords que c'est presque une blague de le comparer avec Rails. Si au moins le rapport d'erreur était un peu meilleur. Mais je suppose que c'est probablement aussi dû à l'énorme quantité de bibliothèques qu'il utilise sous les couvertures. Un mot: stacktrace! Je ne suis pas non plus un grand fan de l'approche model-> db (Rails a db-> model). L'échafaudage laisse également beaucoup de place à des améliorations. Ensuite, "aucun redémarrage requis" ne fonctionne pas non plus comme annoncé. (Je ne sais pas ce qui est pire - devoir redémarrer tout le temps ou parfois trouver des comportements étranges qui disparaissent lorsque vous redémarrez) Et ne me lancez pas sur GORM. (Quand il a fallu des heures pour trouver un moyen qui aurait été un simple SQL, vous commencez à vous demander si tout cet ORM vous fait vraiment gagner du temps) Peut-être aussi longtemps que c'est simple.
Je veux dire: c'est toujours l'un des meilleurs choix d'un framework quand vous venez du monde Java. (Tant de conneries inutiles là-bas qui s'appelle un framework web) ... il a Je souhaite juste que cela ne soit pas basé sur tant d'autres choses complexes.
Quoi qu'il en soit - espérons que ces choses seront triées. En ce moment, je me cache à playframework.org qui semble également très lisse et prometteur.
J'ai beaucoup plus d'expérience avec Ruby on Rails que je ne fais avec rien dans le monde Java, donc je ' m venant d'un point de vue différent. Dans l'ensemble, Grails is beaucoup plus rugueux que les Rails est, en partie à cause de son immaturité, et en partie parce que il s'appuie sur deux cadres incroyablement complexes sous les couvertures (Spring et Hibernate). Rails a également une communauté beaucoup plus grande.
Mais Groovy en tant que langue a fait d'énormes progrès et c'est un plaisir de travailler avec. Grâce aux améliorations apportées dans Groovy 1.6, Grails est un peu plus vif que JRuby on Rails, et vous obtenez un support XML incroyablement bon via GPath. Il y a beaucoup de fonctionnalités agréables que vous obtenez en étant sur la JVM (comme la concurrence et des tonnes de code threadsafe), mais sans avoir à fouiner avec Java (un langage dont je ne me soucie pas beaucoup) ), j'ai donc beaucoup de mal à me convaincre d'utiliser quoi que ce soit sur l'IRM.
Python a l'air tentant, cependant, je dois l'admettre.
Quant à vos problèmes Eclipse, je ne peux pas vous aider. J'utilise Vim et Emacs, principalement parce que je ne supporte pas d'utiliser des IDE. Pour les langages dynamiques comme Groovy, Ruby et Python, cependant, je ne pense pas que les IDE présentent vraiment de réels avantages, car il n'y a pas vraiment de place pour la génération de code, ou un besoin de compiler. Essayez peut-être de travailler sans IDE pendant un certain temps et voir si les choses sont plus fluides?
Donc, oui, je pense que Grails en vaut la peine. Ils ont fait un travail d'enfer pour faire fonctionner les choses aussi rapidement qu'ils l'ont fait, et les équipes Grails et Groovy sont toutes les deux vraiment, vraiment dévouées.
Cela en vaudra la peine une fois le plugin Eclipse terminé. Le plus tôt sera le mieux que je dis. Essayer de vendre du groovy à mon patron ne sera pas simple jusqu'à ce que cela se produise.
Je trouve que le plus grand avantage de Grails est que je n'ai plus à me soucier de la base de données - le schéma est automatiquement créé/mis à jour, et la persistance est en grande partie faite pour moi (plus d'écriture de requêtes SQL). C'est un énorme soulagement. L'autre chose qui est plutôt sympa, c'est qu'une fois que vous vous êtes installé sur les modèles de contrôleurs et de vues, l'ajout de nouveaux objets de domaine est assez rapide. Bien que je soupçonne que vous ferez au moins des changements continus pour vos opinions, en les adaptant aux vues existantes.
En ce qui concerne le IDE - il semble que IntelliJ soit la meilleure option, mais je suis heureux d'utiliser Netbeans 6.5. J'utilise MyEclipse pour tous les autres développements, mais Netbeans a juste un meilleur support Grails maintenant.
Je viens de commencer à utiliser Grails sur un nouveau projet ... ne pas avoir à écrire de fichiers xml mais avoir toujours la puissance de Spring et Hibernate est vraiment incroyable.
Utilisez IntellijIDEA pour le IDE cependant, j'ai en fait découvert Grails à travers le IDE (je pourrais être biaisé cependant, je haine Eclipse) .
J'étais un utilisateur Eclipse avant de commencer à utiliser Grails. Il est vite apparu que cela n'allait pas le couper. J'ai donc essayé Intellij et NetBeans. À l'époque, Intellij était meilleur en ce qui concerne Groovy et Grails. Cependant, NetBeans était gratuit et cela me suffisait. Depuis lors, les trois ont sorti de nouvelles versions ou de nouveaux plugins. J'utilise toujours NetBeans en raison du coût d'Intellij. Avec l'acquisition de G2One par Spring Source, l'une des attentes est un soutien accru pour Groovy et Grails dans Eclipse. Cela sera nécessaire pour une adoption accrue.
Utiliser Grails pour un nouveau projet est merveilleux. Une grande partie des bagages Enterprise Java Java n'est plus nécessaire. J'imagine que tenter de porter quelque chose serait difficile car jusqu'à ce que vous compreniez où sont les forces et les faiblesses d'un framework, il est difficile de l'utiliser efficacement. Il est promis que le support JSP sera plus facile dans Grails 1.1, je ne sais pas si l'utilisation d'une version bêta tout en essayant de trouver un nouveau framework est une bonne idée. Les tests ont également subi une révision majeure pour la nouvelle version. Si le temps vous permet d'envisager d'attendre car la version 1.1 devrait arriver très bientôt.
Si vous avez la possibilité d'essayer Grails dans un autre IDE lors du démarrage d'un projet à partir de zéro, je pense que vous le verrez sous un jour différent.
Totalement. Il y a tellement de cadres Java Java que la barre est placée assez haut pour les nouveaux arrivants, et c'est un témoignage de Grails qu'il a pu s'élever au-dessus dans un espace aussi encombré.
Il a encore quelques bords tranchants, mais ce n'est qu'une question de temps avant qu'ils ne soient collés, le projet sous-jacent en vaut vraiment la peine.
Les Grails peuvent être trop gros pour votre type d'application (en fonction des nombreux fichiers créés lors de la première initialisation et des ressources nécessaires). Si vous cherchez quelque chose de simple, Grails n'est peut-être pas ce que vous cherchez. Si vous cherchez quelque chose de simple et fonctionne, jusqu'à présent, je pense que Django peut bien faire votre travail. Jetez un œil à la simplicité (combien de fichiers il faut) pour créer une application CRUD à partir de - son tutoriel . À partir de là, vos applications peuvent (relativement) facilement évoluer à mesure que vos besoins et vos exigences augmentent.
Je ne suis pas sûr qu'ils pourront jamais faire les Grails correctement, vous savez. Et par droit, je veux dire aborder tous les détails (petits et grands) qui, au final, le rendent fragile et fragile. Je ne suis même pas sûr qu'il y ait une vraie équipe de développement (c'est-à-dire plus de 2 personnes) derrière.
Chaque fois que j'itère une fonctionnalité de mes projets Grails, en essayant d'améliorer quelque chose, c'est le même flux de travail: tout s'effondre, puis c'est une centaine de cycles de test "google", puis vous découvrez la raison pour laquelle vous ne pouvez pas le faire ce que vous voulez et vous faites autre chose.
En fin de compte, vous êtes frustré parce que vous ne voulez même pas toucher à tout ce qui fonctionne. Et les choses qui ne vont pas bien, vous les laissez tomber!
J'envisage de passer à Rails via JRuby. C'est peut-être le meilleur des deux mondes: un framework web capable avec une communauté active et large, une équipe de développeurs dédiée, une plateforme qui est pas basé sur des cadres douteux et complexes comme Spring ou Hibernate, un cycle de sortie rapide et ambitieux. Et JRuby parce que franchement, tant d'actifs Java dans mon sac à dos, je ne peux pas simplement les jeter.
Si votre expertise est en Java comme vous dites. Vous devriez jeter un œil à Play Framework - c'est un framework web inspiré de Ruby = on Rails avec un cycle de développement très court - enregistrez simplement votre fichier source Java et mettez à jour votre navigateur Web. Et si vous voulez essayer une autre langue, jouez Framework possède un module qui vous permet d'utiliser Scala à la place.
J'aime Play Framework car il est facile à comprendre et offre de bonnes performances. Vous pouvez également utiliser JPA et Hibernate pour la couche ORM si vous le souhaitez.