Grails (maintenant) en vaut-il la peine?

Question

Je sais que c'est un doublon, cependant, le Graal monde a évolué considérablement depuis que la question a été posée plus d'un an, comme il a l'IDE de soutien dans Eclipse, donc merci de ne pas juste aveuglément la fermer.

Je pensais que la réponse était oui et ont entrepris un nouveau projet avec le Graal 1.2.0 et ont flirté avec le Groovy/Graal bits de la STS Intégration Eclipse.

Je pense que la question mérite revoir après un an de Graal de l'évolution, lorsque la réponse est certainement mélangé.

Donc, comme un expérimenté Java développeur web, j'ai ces questions et apprécierais mes hypothèses contestées:

• Est-Graal maintenant en vaut la peine vs Ruby ou rouler vos propres?
• Il a surmonté son buggy commencer?
• Est-il vraiment de conférer le développement rapide des avantages? (J'avoue j'ai du mal maintenant, je suis au-delà de la vaste configuration de base pour faire mon application sur mesure qui n'est pas la liste et la page)
• Est-il effectuer pour le monde réel de la production des applications? (Il se sent lourd)
• Est le plug-in Eclipse meilleur qu'il ne l'était et adapté à l'usage? (Je ne pense pas encore)

Merci

EDIT: Je suis en train d'apprendre que je pars et j'ai un couple de important de saisines à faire à propos de la vie avec le cadre - plutôt que de cadre capacités d'eux-mêmes. J'ajoute, parce que je pense qu'ils devraient être les considérations et sont basées sur mon expérience et de l'opinion, et peut aider quelqu'un qui est en train de décider d'aller de l'graal. Je peut également faire preuve de mon manque d'expérience avec le cadre, de sorte que rien de tout cela est destiné à l'extérieur et des critiques. Je suis un développeur expérimenté et c'est ce que j'ai trouvé:

Le débogage est vraiment dur. En fait, il est presque impossible, surtout en tant que débutant dans ce cadre, ce qui est quand vous avez besoin de votre fidèle débogueur ami le plus. J'ai passé beaucoup plus de temps que je dois le suivi des problèmes d'erreurs de syntaxe dans le code pour le faire avec se référant au domaine de champs qui font silencieux échecs quelque part dans la pile.

La journalisation est franchement horrible. Vous disposez de deux modes, "rien d'utile" et "une quantité excessive de trucs inutiles". Mon journal de débogage a été 128mo après une seule demande de page et ne contient rien au sujet de mon erreur. L'ensemble de la question de l'exploitation forestière besoins de réexamen dans le cadre de mon avis.

La STS Eclipse IDE est de peu de valeur. Autre que sa mise en surbrillance de la syntaxe, il n'est pas beaucoup d'utilisation. Vous ne pouvez pas déboguer le code de sorte qu'il est glorieux de l'éditeur. Les conseils de code sont disparates et il n'y a pas de GSP soutien à tous ce que je peut voir. Il est aussi le plus lent du plug-in Eclipse que j'ai sur mon ordinateur de bureau - par environ 2 minutes pour démarrer. Il est terriblement lente. Je reprend un éditeur de texte (que vous remarquerez tout le tutoriel en ligne des vidéos aussi) et de la coutume, sa mise en surbrillance de la syntaxe.

J'ai de graves préoccupations au sujet de la performance. Un peu trop tôt pour le dire, mais je suis déjà de me trouver en modifiant la base de données en raison de la mise en veille prolongée. Peut-être que c'est normal, mais je suis vraiment d'avoir à garder mon nom de domaine modèle simple pour les conventions de rendement performant de requêtes.

Et une dernière chose, la convention que votre logique du modèle de domaine et votre modèle de base de données doit être identique n'est pas une puce par défaut et risque de ne jamais être le cas dans le monde réel. Je sais que vous pouvez séparer les deux, mais il crée un degré de complexité qui je pense pourrait être évité si les conventions ont été étendues. Il y a l'insuffisance de la documentation à propos de la composition et de ce que vous devez faire pour le faire fonctionner dans la pratique.

Answer 1

J'ai été en utilisant Graal plus de 4 mois maintenant et je vais essayer de vous donner mon sentiment personnel sur Graal et de sa facilité d'utilisation.

Est-Graal maintenant en vaut la peine vs Ruby ou autre rouleau de votre propre?

Bien sûr, la réponse n'est pas " Oui " ou "Non", mais ça dépend. Cela dépend de vos besoins (vous devez être dans le Monde Java?), sur vos préférences (préférez-vous le domaine de développement orienté, préférez-vous Groovy...)? Cependant, je peux répondre que le Graal est une alternative sérieuse aux Rails. Je crois que quelle que soit votre application Rails, vous pouvez le faire avec le Graal. Mais selon la nature de votre projet, cela peut prendre plus ou moins de temps. Encore une fois, si vous êtes familier avec les Rails, mais pas avec le Graal, Rails est l'option la plus sûre.

Il a surmonté son buggy commencer?

Oui. Si vous jetez un oeil à mes premiers messages (dans ce site web ou d'autres), j'ai été se plaindre beaucoup sur Grain de bugs. Mais, vous avez juste besoin de se rappeler que le Graal est un peu rude sur les bords (pas trop de l'utilisation du domaine de l'héritage ,par exemple) et une fois que vous êtes familier avec le cadre, vous n'avez pas trop de mauvaises surprises. Je ne dis pas que le Graal n'est pas buggé. Il est certainement plus que les Rails. Mais aussi, il est plus facile d'utilisation que buggy. Un conseil : utilisez aussi peu de plugins que possible. Parce que beaucoup d'entre eux sont buggés et certains ne sont pas compatibles entre eux. Donc, ne pas inclure le graal plugin, sauf si vous êtes sûr que le graal plugin est à jour, non-intrusive et testé (par vous-même).

Est-il vraiment de conférer le développement rapide des avantages?

Oui. Vous ne pas besoin de traiter avec DB design. La Configuration est presque fait pour vous depuis le début grâce à la Convention plutôt que Configuration". Votre application est facilement maintenable. Le seul inconvénient que je vois est que développeur front-end qui n'est pas aussi riche que d'autres technologies (comme les Rails ou ASP)

Est-il effectuer pour le monde réel de la production des applications?

Je ne peux pas dire car je ne l'ai toujours pas aller sur mon site en direct, mais je suis assez confiant car sky.com est l'aide de Graal et les sites d'attirer un trafic important - autour de 7 millions de pages vues par jour . De nouveau, la performance dépend beaucoup de votre architecture de l'application et les décisions de conception.

Est le plug-in Eclipse meilleur qu'il ne l'était et adapté à l'usage?

Aucune idée. Je suis à l'aide de l'Ide, mais je suppose que ce n'est pas beaucoup mieux qu'il y a un an selon la plaignante messages que je vois sur le Graal royaume.

J'espère que cela aide.

Answer 2

Commencé un Rails de projet récemment, avait fait quelques trucs avec le Graal.

Ma principale chose avec des Rails est qu'il y a beaucoup de choses qui est complètement opaque pour le dev (je déteste ça), ce qui tend à augmenter lorsque vous commencer à ajouter plus de plugins/générateurs/libs/etc, parce que, pour les associer, vous aurez besoin de patch quelque chose. Vous obtenez la sensation que rails+plugins sont juste un géant DSL hack qui commence à se rompre si vous utilisez une mauvaise combinaison de plugins+versions.

Avec le Grain, bien que l'écosystème est bien plus petit, tout tend à être relativement uniforme. Le DSL approche n'est pas très utilisé, et en utilisant des classiques mais ennuyeux design (je veux dire en utilisant les classes,interfaces,etc. au lieu de DSLs), il est beaucoup plus facile de comprendre comment les travaux de tuyauterie.

Faire un 1-de-1 titre de comparaison, voici comment ça se passe:

• Langage d'Implémentation: je préfère Ruby plus Groovy, bien que je ne sais pas Ruby. Groovy se sent comme une bonne intention-mauvais-de la mise en œuvre de la langue, où certaines fonctions sont soudées sur le dessus de la syntaxe. Je fais allusion à certaines classes spéciales qui semble n'être là que pour permettre à certains hack.
• Cadre Caractéristiques: Rails est très en avance sur celui-ci. Vous pouvez configurer la plupart des aspects de Rails (ex: les plans, les templates, css/js packers, validation, tests de cadres, etc) de plusieurs façons. Graal est à la traîne sur ce, bien que la flexibilité suffisante pour la plupart des cas d'utilisation.
• Plugins: Rails a une tonne de plugins qui peut être vu comme une bénédiction ou un cauchemar. Certains plugins ne sont pas entretenus, d'autres ne jouent pas bien avec certaines caractéristiques ou plugin et il y a beaucoup de fourches. J'apprends à coller avec le plus fondamental et le plus utilisé des plugins (authlogic, haml, etc) Graal a d'excellentes plugins pour les bases (autorisation/de l'authentification, de l'ORM, etc) et quelques autres plugins pour les petits trucs
• Test: Rails a une tonne de façons pour les tests, mais ce n'est pas nécessairement bon. Certains tests de cadres ne sont pas bien jouer avec des plugins, etc. Graal a moins de tests de plugins, mais encore une fois, ils ont tendance à mieux s'intégrer avec quelques-uns des principaux plugins (car il n'y a pas que de nombreux plugins pour intégrer)
• Base de données: Graal gagne de loin.
  • Je visez plutôt la modélisation de mes classes de domaine au lieu de piratage de ma db.
  • Mise en veille prolongée (qui est utilisé sous le capot) est à des années loin de ses Rails de contrepartie. Bien qu'il n'y a datamapper pour les Rails (ce qui est plus de nature similaire à Hibernate de ActiveRecord), je pense qu'il n'est pas assez mature. Graal ont aussi des migrations par un plugin.
  • Vous avez de grandes cache impls pour la mise en veille prolongée (JBoss cache, EhCache, etc) qui peuvent booster vos performances à travers le toit
• Bibliothèques: j'ai l'impression que Ruby a beaucoup de bibliothèques pour les nouveaux trucs comme NoSQL ou de services dans le Cloud, alors que Java a une foule de bibliothèques pour les vieux trucs comme Excel de traitement. N'oubliez pas que les bibliothèques Java sont généralement beaucoup plus rapide que le Rubis
• Arête de coupe: Rails est plus hype, qui se traduit par avoir plus de ressources derrière elle. Cela signifie que si vous r'essayer d'intégrer MongoDB ou Riak avec des Rails, il y a un bon changement que quelqu'un a déjà fait. Graal est à la traîne, principalement parce qu'il n'est pas si populaire, afin que la communauté a tendance à se concentrer sur la résolution de la journée-à-jour, les problèmes au lieu d'utiliser tous les avant-gardistes et des trucs comme NoSQL,etc

Voici un exemple:

• La plupart graal plugins générer le code dans le formulaire de modèles et/ou de services. Le reste est généralement géré par une bibliothèque. Vous pouvez vérifier le modèle/code de service, voir ce qu'il fait et de le modifier.
• La plupart des Rails de plugins généralement crochet avec les Rails de l'API, ce qui signifie que vous vous retrouvez l'appel d'une fonction ou d', y compris certains de module, et ensuite utiliser le plugin propre DSL. Cela fonctionne très bien quand ça marche, mais quand ça casse c'est horrible et vous finissez par avoir à patcher certains trucs, ou d'installer un autre plugin ou plug-in. Je devine un plus aguerris des Rails de dev est plus à l'aise avec cela, mais je ne suis pas.

---

Conclusion:

• Si vous souhaitez bord de saignement, n'ont pas l'esprit de quelques correctifs, en faveur d'une large communauté et/ou n'avez pas l'esprit à l'aide de ActiveRecord-style DB, aller avec Rails. En outre, Ruby comme une langue, c'est très élégant
• Si vous en faveur de la classe-conception de l'interface au lieu de DSLs, préférez la modélisation de votre application grâce à des modèles, n'ont pas besoin de fonctionnalités remarquables et sont familiers avec l'écosystème Java, aller avec le Grain

Answer 3

Il est très fortement la peine!

Nous sommes en utilisant le Graal dans plusieurs projets, tous les d'eux avec une grande réussite pour les raisons suivantes:

• Facile - C'est l'un des plus faciles cadres que nous avons jamais utilisé

• Héritage de la réutilisation de code, Tout ce que nous avons à faire est de prendre notre héritage de code et de le jeter sur la lib ou le dossier src et c'est fait. Tout simplement génial pour nous.

• Héritage structure de base de données - C'est un outil génial si vous voulez générer des visualisations de données sur les bases de données existantes.

Maintenant, au sujet de la viabilité:

• Bugs: nous n'avons pas eu trop de bugs depuis la version 1.1 (version 1.0 était trop buggé pour nous)

• Outils: Netbeans est vraiment une amélioration sur ce front, mais il n'est même pas proche d'autres outils comme Intellij IDEA (grand soutien!). La même chose peut être dit à propos de l'Éclipse.

• Portabilité: nous n'avons jamais été confrontés à un problème unique sur nos projets.

Answer 4

Nous avons une demi-douzaine de Graal applications en production maintenant, et tout Graal est différente de la liste des frameworks java et nécessite un certain temps d'apprentissage, il a payé car nous avons utilisé des techniques Agiles. Détails:

• Nous utilisons IntelliJ. Ce n'est pas très cher et a payé de retour dans quelques semaines pour nous.
• Automatique de test, d'Intégration Continue et de refactoring sont un must, comme pour tous les code de langage dynamique. Si vous avez déjà une pratique du TDD ou au moins avoir une bonne couverture de code de tests, alors il n'ajoute pas de travail supplémentaire.
• Hibernate est livré par défaut avec le Graal, mais vous pouvez utiliser d'autres infrastructures de persistance. Il y a 5 persistance des plugins disponibles aujourd'hui
• L'enregistrement est clairement pas un sujet de préoccupation dans Graeme Rochers' esprit, mais il a constamment amélioré. Je n'ai pas été confronté à un problème où une erreur n'a pas été enregistré, mais que vous devez assurez-vous d'attraper les exceptions correctement dans votre code)
• Le débogage est clairement pas sur le radar (mais cela n'a pas amélioré). Nous ne comptez pas sur le débogage de toute façon.

Cela dit, comme avec toutes les nouvelles technologies, je vous recommande de créer des prototypes, des revues de code, la programmation en binôme, et peut-être utiliser certaines de consultation.

Answer 5

Il vaut vraiment la peine. Je l'ai utilisé pendant plus d'un an maintenant et il aime. J'ai utilisé à s'éloigner de ces types d'outils rad, mais il a changé ma façon de travailler. Avec la version 1.2, il a obtenu encore mieux avec une meilleure trace de la pile d'info (en particulier pour les fournisseurs de services internationaux).

Le seul problème que j'ai eu avec mise à l'échelle a été mise en veille prolongée et sa mémoire cache, ce qui n'est vraiment pas un graal question. Même ceux que je n'aime pas hiberner en général, le chemin du graal enveloppe avec GORM est une œuvre d'art pour moi. Les critères de fermeture aspect est merveilleux de travailler avec.