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.
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.
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...
"Wer seinem Computer Mist erzählt, muss immer damit rechnen..." (unbekannt)
"Der Computer rechnet damit, dass der Mensch denkt..." (auch unbekannt)
mein blog