Hallo Rabban, Hallo Abt,
danke für die Hilfe mit einer ICollection hat NHibernate es korrekt erkannt und nicht in der Datenbank aktualisiert.
... eine virtual IList<T> oder etwas vergleichbares nutzt ...
Richtig erkannt, wir wissen garnicht was für eine Collection da eigentlich drin steckt.
...keine Repositories..
... Am sinnigsten wäre es aber wohl wirklich, wenn ihr euch ein Repository schreibt das die Collection zu dieser Entität in der Sortierung zurück gibt, wie ihr es braucht.
Somit wäre die neue Collection auch Lazy und ihr könnt darin wild rumsortieren oder verändern wie ihr wollt, ohne die Versionsnummer von Entität A zu verändern.
Wie Rabban sagte muss man keine Repositories in NHibernate verwenden. Aber dank der ganzen Optionen von NHibernate (Selekt-Bedingungen auf Typen-Ebene, Sortierkriterien, Vererbung, ...) und dem OO-Prinzip der Kapselung ist das ganze Konzept von Repositories eigentlich überflüssig! Weil:
- der Großteil aller Abfragen auf die Objekte sowieso dynamisch, je nach Benutzerwunsch/-eingabe, ist.
- nur wenige komplexe Bedingungen wiederverwendet werden müssen.
- die komplexen Bedinungen einfacher als eigene Implementationen von ICriterion (bzw. in den jeweiligen alternativen Abfrage-Syntaxen)* umgesetzt werden und so dynamisch an den passenden Stellen verwenden** werden können (statt Methoden aus Repositories).
Sehr viel Erfahrung mit NHibernate im speziellen und Repository-Pattern im Allgemeinen habe ich aber nicht. Falls jemand gute Gründe für das Repository-Pattern hat, würde es mich freuen sie zu lesen.
Gruß
Lecrell & Juy Juka
* wir verwenden nur DetatchedCriteria als Abfrage-Syntax, der Einfachkeit halber.
** dank Mikrokern/ServiceLocator kann man dies dann global Konfigurieren/Austauschen.
