Usando clases de java en grails

Question

Tengo una aplicación Java \ Spring \ Hibernate, completa con clases de dominio que son básicamente POJO de Hibernate

Hay una pieza de funcionalidad que creo que se puede escribir bien en Grails.

Deseo reutilizar las clases de dominio que he creado en la aplicación principal de Java

¿Cuál es la mejor manera de hacerlo?

¿Debo escribir nuevas clases de dominio extendiendo las clases de Java? esto suena de mal gusto O ¿Puedo 'generar' controladores fuera de las clases de dominio de Java?

¿Cuáles son las mejores prácticas para reutilizar objetos de dominio Java en Grails \ Groovy? Estoy seguro de que debe haber otros que escriban algunas piezas en grails \ groovy

Si conoces un tutorial que habla sobre dicha integración, ¡sería genial!

PD: soy un novato en el tema de los grails, así que puede que me falte lo obvio. Gracias !!!

Answer 1

¿Realmente quieres / necesitas usar Grails en lugar de solo Groovy?

Grails realmente no es algo que pueda usar para agregar una parte a una aplicación web existente. Toda la " convención sobre configuración " Enfoque significa que tienes que seguir las reglas de Grails, de lo contrario no tiene sentido usarlo. Y una de esas reglas es que los objetos de dominio son clases Groovy que están muy mejoradas " " por el tiempo de ejecución de Grails.

Puede ser posible que amplíen las clases existentes de Java, pero no apostaría por ello, y todas las partes de Spring e Hibernate de tu aplicación actual deberían descartarse, o al menos tendrías que gastar Mucho esfuerzo para que funcionen en Grails. Estarás luchando contra el marco en lugar de beneficiarte de él.

En mi opinión, tienes dos opciones:

• Vuelva a escribir su aplicación desde cero en Grails mientras reutiliza la mayor cantidad posible del código existente.
• Mantenga su aplicación como está y agregue nuevas cosas en Groovy, sin usar Grails.

Este último es probablemente mejor en su situación. Grails está destinado a crear nuevas aplicaciones web muy rápidamente, ahí es donde brilla. Agregar cosas a una aplicación existente simplemente no es para lo que fue creado.

EDITAR: En cuanto a la aclaración de los comentarios: si planea escribir básicamente una interfaz de entrada / mantenimiento de datos para datos utilizados por otra aplicación y tener la base de datos como el único canal de comunicación entre ellos, eso podría funcionar bastante bien con Grails; Ciertamente, se puede configurar para usar un esquema de base de datos existente en lugar de crear su propio a partir de las clases de dominio (aunque este último es menos trabajo).

Answer 2

Knowing just how well Groovy and Grails excel at integrating with existing Java code, I think I might be a bit more optimistic than Michael about your options.

First thing is that you're already using Spring and Hibernate, and since your domain classes are already POJOs they should be easy to integrate with. Any Spring beans you might have can be specified in an XML file as usual (in grails-app/conf/spring/resources.xml) or much more simply using the Spring bean builder feature of Grails. They can then be accessed by name in any controller, view, service, etc. and worked with as usual.

Here are the options, as I see them, for integrating your domain classes and database schema:

• Bypass GORM and load/save your domain objects exactly as you're already doing.

  Grails doesn't force you to use GORM, so this should be quite straightforward: create a .jar of your Java code (if you haven't already) and drop it into the Grails app's lib directory. If your Java project is Mavenized, it's even easier: Grails 1.1 works with Maven, so you can create a pom.xml for your Grails app and add your Java project as a dependency as you would in any other (Java) project.

  Either way you'll be able to import your classes (and any supporting classes) and proceed as usual. Because of Groovy's tight integration with Java, you'll be able to create objects, load them from the database, modify them, save them, validate them etc. exactly as you would in your Java project. You won't get all the conveniences of GORM this way, but you would have the advantage of working with your objects in a way that already makes sense to you (except maybe with a bit less code thanks to Groovy). You could always try this option first to get something working, then consider one of the other options later if it seems to make sense at that time.

  One tip if you do try this option: abstract the actual persistence code into a Grails service (StorageService perhaps) and have your controllers call methods on it rather than handling persistence directly. This way you could replace that service with something else down the road if needed, and as long as you maintain the same interface your controllers won't be affected.

• Create new Grails domain classes as subclasses of your existing Java classes.

  This could be pretty straightforward if your classes are already written as proper beans, i.e. with getter/setter methods for all their properties. Grails will see these inherited properties as it would if they were written in the simpler Groovy style. You'll be able to specify how to validate each property, using either simple validation checks (not null, not blank, etc.) or with closures that do more complicated things, perhaps calling existing methods in their POJO superclasses.

  You'll almost certainly need to tweak the mappings via the GORM mapping DSL to fit the realities of your existing database schema. Relationships would be where it might get tricky. For example, you might have some other solution where GORM expects a join table, though there may even be a way to work around differences such as these. I'd suggest learning as much as you can about GORM and its mapping DSL and then experiment with a few of your classes to see if this is a viable option.

• Have Grails use your existing POJOs and Hibernate mappings directly.

  I haven't tried this myself, but according to Grails's Hibernate Integration page this is supposed to be possible: "Grails also allows you to write your domain model in Java or re-use an existing domain model that has been mapped using Hibernate. All you have to do is place the necessary 'hibernate.cfg.xml' file and corresponding mappings files in the '%PROJECT_HOME%/grails-app/conf/hibernate' directory. You will still be able to call all of the dynamic persistent and query methods allowed in GORM!"

  Googling "gorm legacy" turns up a number of helpful discussions and examples, for example this blog post by Glen Smith (co-author of the soon-to-be-released Grails in Action) where he shows a Hibernate mapping file used to integrate with "the legacy DB from Hell". Grails in Action has a chapter titled "Advanced GORM Kungfu" which promises a detailed discussion of this topic. I have a pre-release PDF of the book, and while I haven't gotten to that chapter yet, what I've read so far is very good, and the book covers many topics that aren't adequately discussed in other Grails books.

Sorry I can't offer any personal experience on this last option, but it does sound doable (and quite promising). Whichever option you choose, let us know how it turns out!

Answer 3

This post provides some suggestions for using grails for wrapping existing Java classes in a web framework.