Utilizzo delle classi Java in Grails

Question

Ho un'applicazione Java \ Spring \ Hibernate - completa di classi di dominio che sono sostanzialmente POJO Hibernate

C'è una funzionalità che penso possa essere scritta bene in Grails.

Desidero riutilizzare le classi di dominio che ho creato nell'app Java principale

Qual è il modo migliore per farlo?

Devo scrivere nuove classi di dominio estendendo le classi Java? sembra pacchiano Oppure posso "generare" controller dalle classi di dominio Java?

Quali sono le migliori pratiche sul riutilizzo di oggetti del dominio Java in Grails \ Groovy Sono sicuro che ce ne devono essere altri che scrivono alcuni pezzi in grails \ groovy

Se conosci un tutorial che parla di tale integrazione, sarebbe fantastico !!!

PS: sono un principiante in Grails-Groovy, quindi potrebbe mancare l'ovvio. Grazie !!!

Answer 1

Vuoi davvero / hai bisogno di usare Grails piuttosto che solo Groovy?

Grails non è davvero qualcosa che puoi usare per aggiungere una parte a un'app Web esistente. L'intera "convenzione sulla configurazione" approccio significa che devi praticamente giocare secondo le regole di Grails, altrimenti non ha senso usarlo. E una di quelle regole è che gli oggetti di dominio sono classi Groovy che sono pesantemente "migliorate" dal runtime di Grails.

Potrebbe essere possibile farli estendere le classi Java esistenti, ma non ci scommetterei - e tutte le parti Spring e Hibernate della tua app esistente dovrebbero essere scartate, o almeno dovresti spendere molti sforzi per farli lavorare in Grails. Combatterai contro il framework piuttosto che trarne profitto.

IMO hai due opzioni:

• Riscrivi la tua app da zero in Grails riutilizzando il più possibile il codice esistente.
• Mantieni la tua app così com'è e aggiungi nuove cose in Groovy, senza usare Grails.

Quest'ultimo è probabilmente migliore nella tua situazione. Grails ha lo scopo di creare nuove app Web molto rapidamente, ecco dove brilla. L'aggiunta di elementi a un'app esistente non è proprio ciò per cui è stata creata.

Modifica Per quanto riguarda il chiarimento nei commenti: se stai pianificando di scrivere sostanzialmente un frontend per l'immissione / manutenzione dei dati per i dati utilizzati da un'altra app e hai il DB come unico canale di comunicazione tra loro, che potrebbe effettivamente funzionare abbastanza bene con Grails; può certamente essere configurato per utilizzare uno schema DB esistente anziché crearne uno proprio dalle classi di dominio (sebbene quest'ultimo sia meno lavoro).

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.