Hallo Leute und ein gutes neues Jahr 2011!

Was sind so Eure Erwartungen oder Anforderungen an ein ORM?
Wo seht Ihr Vorteile bzw. Nachteile?

Z.B.
- native Objekte mit Feldern u. Properties oder ein integriertes VTF (ValueTypeFramework)
- Datenbankunabhängig bzw. einfache generalisierte Schnittstelle für Datenspeicherung
- einfache Abfragemöglichkeiten
- Ressourcenschonend
- einfache Anbindung an visuelle Komponenten
- einfache Webanbindung mittels XML, JSON/BSON -> RESTful
- Verwendung von Attributen oder lieber Metadaten zur erweiterten Definition
- ....

Bin mal gespannt auf Eure Reaktionen/Anregungen/Wünsche...

Bloß keine starre Bindung mehr zwischen DB und GUI! Die GUI sollte auf alle möglichen Public-Properties bindbar sein. Ob die dann von "eigenen" Klassen oder Entitäten des ORM stammen, sollte der GUI egal sein.

Ein Framework zur Verfügungstellung von Data-Services verleitet IMHO dazu die ganze Arbeit wieder auf dem Client zu machen, statt direkt im Webservice. Darauf könnte ich also verzichten.

Ein ORM sollte sowohl mit Attributen als auch mit "externen" Metadaten klar kommen. Am Besten auch mit der Kombinationa us beidem.

Zitat von mquadrat:

Bloß keine starre Bindung mehr zwischen DB und GUI! Die GUI sollte auf alle möglichen Public-Properties bindbar sein. Ob die dann von "eigenen" Klassen oder Entitäten des ORM stammen, sollte der GUI egal sein.

Korrekt, aber das ist nicht ORM, sondern MVP (ModelViewPresenter) oder MVC (ModelViewController). Das kommt erst später, via RTTI auf StandardControls und erweiterbar für andere Komponenten oder "Ansichts"-Schnittstellen.

Zitat von mquadrat:

Ein Framework zur Verfügungstellung von Data-Services verleitet IMHO dazu die ganze Arbeit wieder auf dem Client zu machen, statt direkt im Webservice. Darauf könnte ich also verzichten.

Was ja eigentlich der Sinn hinter der Abbildung von Geschäfts-Entitäten ist. Sie sollen so realitätsnah wie möglich ihre Aufgaben abbilden, sind also demnach eher Fat-Client-Systeme. Allerdings ermöglichen sie auch die Auslagerung von Prozessen auf den Server.

Zitat von mquadrat:

Ein ORM sollte sowohl mit Attributen als auch mit "externen" Metadaten klar kommen. Am Besten auch mit der Kombinationa us beidem.

Das ist eine elementare Designfrage. Erstere Variante ist angenehmer für den Programmierer (was zusammengehört ist auch an einer Stelle definiert), letzteres ist, je nach Implementierung, "offener" für Veränderung. Letztendlich müsste dann nach Prioritäten entschieden werden, welche Definition Vorrang hat (Attribute versus externe Metadaten), sonst wundert sich einer...

Hi,

einfache Klassen mit Standardtypen:
1. lassen sich so bestehende Klassen einfacher übernehmen
2. Tools wie Modelmaker tun sich damit einfacher (ich weiß da kann man auch eigene Typen definieren)

Zitat:

- Datenbankunabhängig bzw. einfache generalisierte Schnittstelle für Datenspeicherung

versteh ich nicht was du damit meinst - ist doch im Sinne eines ORM das ganze in Schichten aufzubauen und dadurch erreichst Du dcoh schon weitestgehende DB-Unabhängigkeit

Zitat:

- einfache Abfragemöglichkeiten

Ja, es sollte die Möglichkeit geben, eine TDataSource/TQuery aus dem ORM ruas zu bekommmen um notfalls auch mal ein Grid für eine Übersicht füllen zu können bzw. bei aufwendigen Reports auch auf eine StoredProcedure zugreifen zu können

Zitat:

- Ressourcenschonend
- einfache Anbindung an visuelle Komponenten

ist IMHO selbstverständlich, wobei die Anbindung per MGM bzw, MVP Pattern passieren muss - das ist einfach flexibler. Vermutlich müsste auch eine Anbindung per TDataSource möglich sien um die Objekte auch direkt an einen Report anzuschließen.


Grüße

Zitat von Lemmy:

Hi,
einfache Klassen mit Standardtypen:
1. lassen sich so bestehende Klassen einfacher übernehmen
2. Tools wie Modelmaker tun sich damit einfacher (ich weiß da kann man auch eigene Typen definieren)

Sehe ich prinzipiell auch so, aaaber: mittels internem VTF (ValueTypeFramework) lassen sich z.B. externe Entity-Modellierung oder Undo/Redo (leichter) realisieren - die Frage ist, wie wichtig wäre das? Oder reicht eventuell ein Cloning im MVP bei Datenübernahme aus, ala der Klasse TRecall?

Zitat:

versteh ich nicht was du damit meinst - ist doch im Sinne eines ORM das ganze in Schichten aufzubauen und dadurch erreichst Du dcoh schon weitestgehende DB-Unabhängigkeit

Da hast Du recht. Ich habe mich etwas missverständlich ausgedrückt. Ich meinte eigentlich, Anbindung generalisieren für verschiedene Systeme, oder spezialisieren für eine DB (Datenanbindung). Aber vergessen wir das, Du hast recht, es ist ja doch ein "Schichtkäse"

Zitat:

Ja, es sollte die Möglichkeit geben, eine TDataSource/TQuery aus dem ORM ruas zu bekommmen um notfalls auch mal ein Grid für eine Übersicht füllen zu können bzw. bei aufwendigen Reports auch auf eine StoredProcedure zugreifen zu können

Dafür gibt's z.B. die postcardware SnapObjects...

Zitat:

ist IMHO selbstverständlich, wobei die Anbindung per MGM bzw, MVP Pattern passieren muss - das ist einfach flexibler. Vermutlich müsste auch eine Anbindung per TDataSource möglich sien um die Objekte auch direkt an einen Report anzuschließen.
Grüße

Das ist klar, sonst macht's wenig Sinn. Die meisten Repoting Tools erlauben ja auch die Einbindung von Daten ohne TDatasource...

Clemens

Hi,

Zitat von webcss:

Sehe ich prinzipiell auch so, aaaber: mittels internem VTF (ValueTypeFramework) lassen sich z.B. externe Entity-Modellierung oder Undo/Redo (leichter) realisieren - die Frage ist, wie wichtig wäre das? Oder reicht eventuell ein Cloning im MVP bei Datenübernahme aus, ala der Klasse TRecall?

Schon.. habe das mal bei Delphi 7 + Bold gesehen bzw später dann auch bei ECO. Ist schon ne coole Sache wenn sich die DB aus dem Objektmodell generiert. ALlerdings muss ich sagen, dass mir tiOPF immer besser gefallen hat. Bzw. das Modell das ich im Kopf habe

Zitat von webcss:

Dafür gibt's z.B. die postcardware SnapObjects...

LOL - da kannst Du dein VTF aber in die Tonne treten (oder zumidnest musst Du dann bei SnapObjects einiges einstellen)... Außerdem alle Delphiversionen ab 2009. Ich finde SnapObjects auch geil - habe es bei "meinem" OPF auch eingesetzt, aber dann bei Delphi 2009 verworfen und für die Reportansteuerung auf ein MemoryTable von Jedi umgestellt, bzw. dieses entsprechend erweitert, damit das meine Klassen "fressen" kann. Funktioniert ganz gut...

Zitat von webcss:

Das ist klar, sonst macht's wenig Sinn. Die meisten Repoting Tools erlauben ja auch die Einbindung von Daten ohne TDatasource...

Mach ich bisher ungern - zumindest bei FastReport ist das wohl eine ganz schön aufwändige Sache

Zitat von Lemmy:

LOL - da kannst Du dein VTF aber in die Tonne treten (oder zumidnest musst Du dann bei SnapObjects einiges einstellen)

Nö, weil wir greifen ja immer nur auf properties zu. Wo die tatsächlichen Werte gehalten werden, in Fields oder in einem VTF, ist da vollkommen egal...
TDatasource will ja auch keiner

Zitat:

Zitat:

Das ist klar, sonst macht's wenig Sinn. Die meisten Repoting Tools erlauben ja auch die Einbindung von Daten ohne TDatasource...

Mach ich bisher ungern - zumindest bei FastReport ist das wohl eine ganz schön aufwändige Sache

Dafür gibt's dann das MVP/MGM/MVC, wie auch immer. Der Report ist dann nur ein View Object