À l'aide de classes java dans Graal

Savoir juste comment bien Groovy et Graal excel à s'intégrer avec existant de code Java, je pense que je pourrais être un peu plus optimistes que Michael au sujet de vos options.

Première chose, c'est que vous êtes déjà à l'aide de Spring et Hibernate, et depuis les classes de votre domaine sont déjà Pojo ils devraient être faciles à intégrer. Toutes les beans Spring, vous pourriez avoir peut être spécifié dans un fichier XML comme d'habitude (dans grails-app/conf/spring/resources.xml) ou bien plus simplement en utilisant le Printemps bean builder fonction du Graal. Ils peuvent être consultés par le nom de n'importe quel contrôleur, la vue, le service, etc. et a travaillé avec, comme d'habitude.

Voici les options, comme je les vois, pour intégrer les classes de votre domaine et de schéma de base de données:

• De contournement de GORM et de charger ou d'enregistrer votre domaine d'objets exactement comme vous êtes déjà en train de faire.

  Graal ne vous force pas à utiliser GORM, donc cela devrait être assez simple: créer un .jar de votre code Java (si vous ne l'avez pas déjà) et le déposer dans le Graal de l'application lib répertoire. Si votre projet Java est Mavenized, c'est encore plus facile: Graal 1.1 fonctionne avec Maven, vous pouvez donc créer un pom.xml pour votre Graal application et ajouter votre projet Java en tant que dépendance comme dans les autres (Java) projet.

  De toute façon vous serez en mesure de import vos classes (et de toutes les classes de support) et procéder comme d'habitude. En raison de Groovy de l'étroite intégration avec Java, vous serez capable de créer des objets, de les charger à partir de la base de données, les modifier, les enregistrer, de les valider, etc. exactement comme vous le feriez dans votre projet Java. Vous n'obtiendrez pas de toutes les commodités de GORM de cette façon, mais vous avez l'avantage de travailler avec des objets de manière à déjà fait sens pour vous (sauf peut-être avec un peu moins de code grâce à Groovy). Vous pouvez toujours essayer d'abord cette option pour obtenir quelque chose de travail, puis considérez l'une des autres options plus tard si il semble de bon sens à l'époque.

  Un conseil si vous n'essayez cette option: résumé de la réelle persistance de code dans un Grain de service (StorageService peut-être) et vous avez votre contrôleurs de l'appel de méthodes sur elle plutôt que sur le traitement de la persistance directement. De cette façon, vous pouvez remplacer ce service par quelque chose d'autre en bas de la route, si nécessaire, et aussi longtemps que vous maintenez la même interface que les contrôleurs ne seront pas touchés.

• Créer un nouveau Graal domaine de classes sous-classes de vos classes Java.

  Cela pourrait être assez simple si vos classes sont déjà écrit que bon les haricots, c'est à dire avec des getter/setter pour l'ensemble de leurs propriétés. Graal va voir ces propriétés héritées, comme il le ferait si elles ont été écrites dans le plus simple Groovy style. Vous serez en mesure de préciser comment valider chaque propriété, à l'aide de simples contrôles de validation (pas nulle, n'est pas vide, etc.) ou avec dispositif de fermeture plus compliqué les choses, peut-être d'appeler les méthodes existantes dans leurs super-classes POJO.

  Vous aurez presque certainement besoin d'ajuster les mappages par la GORM cartographie DSL pour s'adapter à la réalité de votre schéma de base de données. Les relations de l'être où il pourrait devenir difficile. Par exemple, vous pourriez avoir une autre solution où GORM s'attend à une table de jointure, mais il se peut même être un moyen de contourner les différences de ces. Je vous conseille d'apprendre autant que vous pouvez au sujet de GORM et de sa cartographie DSL et puis expérimenter avec quelques-uns de vos classes pour voir si c'est une option viable.

• Ont Graal utiliser votre Pojo et Hibernate mappages directement.

  Je n'ai pas essayé moi-même, mais selon le Graal du Hibernate page Intégration de ce qui est censé être possible: "Graal vous permet également de rédiger votre modèle de domaine en Java ou de ré-utiliser un modèle de domaine qui a été cartographiés à l'aide d'Hibernate. Tout ce que vous avez à faire est de placer le nécessaire " hibernate.cfg.xml fichier et correspondant mappages de fichiers dans le '%PROJECT_HOME%/grain-app/conf/hibernate' annuaire. Vous serez toujours en mesure d'appeler l'ensemble de la dynamique persistante et méthodes de requête autorisée dans GORM!"

  Googler "gorm héritage" tourne un certain nombre de discussions utiles et des exemples, par exemple ce blog par Glen Smith (co-auteur de le bientôt-à-être-publié Graal dans l'Action), où il montre un fichier de mapping Hibernate utilisé pour intégrer avec "l'héritage DB de l'Enfer". Graal dans l'Action a un chapitre intitulé "Advanced GORM Kungfu" qui promet une discussion détaillée de ce sujet. J'ai une pré-version PDF de l'ouvrage, et bien que je n'ai pas réussi à faire à ce chapitre encore, ce que j'ai lu jusqu'à présent est très bonne, et le livre couvre de nombreux sujets qui ne sont pas suffisamment discuté dans d'autres Graal livres.

Désolé je ne peux pas proposer une expérience personnelle sur cette dernière option, mais ça me paraît faisable (et très prometteur). Quelle que soit l'option que vous choisissez, faites-nous savoir comment il se révèle!

OriginalL'auteur John Landahl