| 

.NET C# Java Javascript Exception

Domain Klasse aus Entity-Bean ableiten

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Domain Klasse aus Entity-Bean ableiten

koeberle - 02.09.2009 16:11
Ist es möglich eine Domain-Klasse aus einer bestehenden Entity-Bean (JPA) abzuleiten (class MyDomainClass extends MyEntityBean')? Und wenn ja bekomme ich den ganzen Magic-Kram von Grails gratis dazu?

Christian


Re: Domain Klasse aus Entity-Bean ableiten

koeberle - 03.09.2009 10:36
christian schrieb:
-------------------------------------------------------
> Interessanter Gedanke. Der Komfort von Grails
> hängt sehr eng mit der "Grails-DSL" zusammen, also
> z. B. Gorm-Konstruktion wie "hasMany". Das liest
> und schreibt sich zwar schön, entspricht aber eben
> keinem Standard.

Dem kann ich nur zustimmen. Um Entitäten zu beschreiben, ist Grails klasse. Der Code ist kompakt, und alles zu einem Thema steht an einer Stelle. Bei Hibernate mit XML finde ich es furchtbar, dass die Klassen und die Konfiguration getrennt sind, ist natürlich für zum umkonfigurieren besser. Bei JPA kann ich zwar die Konfigurationen mit dem Code mischen, aber die Konfigurationen verteilen sich dann über den ganzen Code,dass ist irgendwie auch nicht schön. Das es kein Standart ist ist eigentlich nicht so tragisch, wenn es nur möglich währe aus dem Code meiner Domain-Klasse Code für eine JPA-Entity-Bean zu machen. Und wenn ich Garils mehr als beschreibende Sparche ansehe, müsste es doch möglich sein daraus anderen Code zu generieren, der dann auch 'magische Methoden besitzt', nur dass die dann nicht mehr so magisch sind, da sie dann explizit im Code stehen.

>Um Domain-Klassen auch in anderen
> Systemen verwenden zu können, wäre JPA natürlich
> besser. Bei Grails besteht außerdem eine
> Abhängigkeit zu den "magischen" (sprich dynamisch
> hinzugefügten) Methoden, obwohl man die in den
> Domain-Klassen selbst vielleicht eher selten
> nutzt.
>
> Gorm in JPA zu übersetzen, könnte ich mir noch
> einigermaßen vorstellen. Wobei es spätestens bei
> den dynamischen Gorm-Methoden, die Domain-Klassen
> hinzugefügt werden, problematisch werden dürfte.
> Die dynamischen Methoden sind allgemein ein
> Hindernis für Portabilität. Sie bilden letztlich
> sowas wie eine implizite Schnittstelle - man
> verlässt sich einfach darauf, dass sie da sind.
> Ich halte es für praktisch unmöglich, solche
> Klassen in anderen Systemen einzusetzen.
>
> Letztlich besteht bei Grails also eine verdammt
> enge Kopplung zwischen den eigenen Klassen und dem
> Framework. Um dein Ziel der universell
> einsetzbaren Komponenten zu erreichen, wäre es
> besser, von Anfang an auf Standards wie JPA
> aufzubauen. Dabei geht dann allerdings der Komfort
> einer DSL verloren. Den Ansatz mit JPA verfolgt
> übrigens Spring Roo.


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Domain Klasse aus Entity-Bean ableiten" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.