C++ O/R Mapping Framework
-
Ich bin auf der Suche nach einem O/R Mapping Framework für C++. Leider konnte ich bisher keines finden, dass in etwa mit Hibernate(Java) vergleichbar wäre.
Kennt jemand von euch ein empfehlenswertes?
-
Sowas gibt es leider (soweit mir bekannt) nicht. Das kommt wohl daher, das C++ keine Reflection-Mechanismen hat, wie es bei C# und Java der Fall ist. Weiterhin benutzen viele, die C++ Objekte persistieren wollen, eher OO-Datenbanken, wie Intersystem Cache, EyeDB, Objektivity, Versant Object Database oder wie sie alle heißen.
Ich hatte mal einen O/R-Mapper für C++ als Middleware gesehen. D.h. man schaltet den O/R-Mapping-Server vor die RDBMS und bekommt für den C++-Client Stubs generiert. MIr fällt dafür leider der Name nicht mehr ein. War auch ein kommerzielles Produkt.
Es gibt aber NHibernate für .NET, welches du vielleicht über C++/CLI nutzen kannst (was eigentlich der Sinn von C++/CLI ist). Bin aber was das Thema angeht, leider nicht der richtige Ansprechpartner.
-
DB-Experte schrieb:
Ich bin auf der Suche nach einem O/R Mapping Framework für C++. Leider konnte ich bisher keines finden, dass in etwa mit Hibernate(Java) vergleichbar wäre.
Kennt jemand von euch ein empfehlenswertes?
Das wurde in der Vergangenheit über DLL'S, IDL's, Def's, Registry und SO's abgewickelt. Diese sind genauso in der Lage eine Persistenz einzurichten, wie bei JDO, Hibernate oder EJB. Das Framework ist hier nichts anderes als eine Komponente. Aber wenn Du einmal DLL's oder SO's entwickelt hast, weiß Du das in Java OO-Datenobjekte um ein Vielfaches pflegeleichter sind.
-
Für CORBA (IDL) uä gibt es solche Sachen.
Ansonsten würde sich vielleicht anbieten über boost::serialize ein eigenes Mapping zu realisieren.
Vielleicht bietet auch die dtl (database template library), das was du suchst.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Datenbanken verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Vielen Dank für eure Antworten!
Prof84 schrieb:
Das wurde in der Vergangenheit über DLL'S, IDL's, Def's, Registry und SO's abgewickelt. Diese sind genauso in der Lage eine Persistenz einzurichten, wie bei JDO, Hibernate oder EJB. Das Framework ist hier nichts anderes als eine Komponente. Aber wenn Du einmal DLL's oder SO's entwickelt hast, weiß Du das in Java OO-Datenobjekte um ein Vielfaches pflegeleichter sind.
Hast Du Anwendungsbeispiele dafür, wie so etwas exemplarisch aussieht, wenn man das über DLL's oder SO's macht. Würdest Du sagen, dass es heute kaum noch Anwendungsbereiche für C++ im Bereich verteilter Informationssysteme gibt? Ich muss zugeben, dass ich derzeit auch Zweifel habe, wenn man sieht wie sehr JEE derzeit im Middleware Bereich die Wirtschaft dominiert.
rüdiger schrieb:
Für CORBA (IDL) uä gibt es solche Sachen.
Ich dachte CORBA wär eine reine Protokollfamilie für den Zugriff auf entfernte Objekte? Ich habe mich vor längerer Zeit mal mit TAO auseinander gesetzt, fand es aber für mein Einsatzgebiet etwas zu kompliziert und hab mich dann für den XML-Bloat SOAP entschieden.
-
DB-Experte schrieb:
Hast Du Anwendungsbeispiele dafür, wie so etwas exemplarisch aussieht, wenn man das über DLL's oder SO's macht. Würdest Du sagen, dass es heute kaum noch Anwendungsbereiche für C++ im Bereich verteilter Informationssysteme gibt? Ich muss zugeben, dass ich derzeit auch Zweifel habe, wenn man sieht wie sehr JEE derzeit im Middleware Bereich die Wirtschaft dominiert.
naja, habe schon bessere Quelle gefunden:
http://msdn2.microsoft.com/en-us/library/h90dkhs0(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/z4zxe9k8(VS.80).aspx
http://www.velocityreviews.com/forums/t279311-c-and-persistent-objects.htmlC++ in Enterprise Lösungen ist heute seltener.
Üblich eigentlich nur noch im High-Performance Bereich.
Die Typensicherheit und Plattformunabhängigkeit von J2EE und die relative leichte Entwicklng führten zur Marktdominanz von Java in Mainstram Anwendungen.
Aber XML-basierte SOA ist eine ebenso mächtige Alternative.
-
Danke für die Links Prof84!
Prof84@home schrieb:
Aber XML-basierte SOA ist eine ebenso mächtige Alternative.
Ein sehr interessantes Thema mit dem ich mich in nächster Zeit auch intensiver beschäftigen werde. Ich bin derzeit kein Experte was SOA angeht, jedoch setzen afaik die "Großen" auch auf Java basierte ESB's. Mir sind leider als ESB's auch nur Celtix und der große Bruder Artix von IONA näher bekannt. Du kennst Dich anscheinend mit SOA recht gut aus, welche Produkte setzt Du ein, bzw. sind Dir C++ ESB's bekannt die mit Celtix mithalten können?
-
DB-Experte schrieb:
Du kennst Dich anscheinend mit SOA recht gut aus, welche Produkte setzt Du ein, bzw. sind Dir C++ ESB's bekannt die mit Celtix mithalten können?
SOA ist ein Paradigma! Was hat das mit Tools zu tunen?
In der aktuellen Objektspektrum ist eine Übersicht aller XML Webservice Standards zu finden, wobei sich der SB/SOA nicht zwingend als auf das WAN beziehen muss. Es kann sich auch um eine einfache Kommunikation von Tools mit einer Datenpräsentationsschicht handeln.Konkrete Tools, die ich selber einsetzte, waren AXIS and SOAP
http://ws.apache.org/axis/index.html
http://ws.apache.org/soap/index.htmlandere Tools
http://ws.apache.org/LAN Service Orientierung konzepiere ich heute mit einer anderen Perspektive - der des Modelbusses - zur Illustration http://www.eclipse.org/mddi/!