Ist das Konzept von Repositories (speziell bei NHibernate) überflüssig?

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.

JuyJuka, ich hatte mal einen Entwurf für EF Repositories gemacht, da die Fragen eine zeitlang sehr häufig waren, besonders im Zusammenhang mit dem EF und ASP.NET MVC - das liegt auch noch im Internen; aber mir fehlt die Zeit das qualitativ fertig zu stellen, sodass es für alle anderen User nicht sichtbar ist.

Für Repositories gibt es an für sich Gründe:
* Minimieren des Code-Aufwandes (Generic Repositories)
* Minimierung von Code-Wartung
* Einheitliche Abfragen, Applikations-weit standardisierte Abfragen (Sortierung & Co)
* Direktes Kompilieren der Queries -> Performance-Steigerung

Generell muss man sie - wie Du sagst - nicht verwenden. In den wenigsten Fällen macht das MS bei den EF Beispielen. Aber es ist einfach sehr empfehlenswert.

Die wichtigsten Gründe hat Abt schon aufgezählt, aber ich muss auch Juy Juka zustimmen. Wenn komplexere Abfragen sinnig in DetachedCriteria bzw. ICriterions ausgelagert werden können, fände ich den Lösungsansatz ohne Repositories legitim.

Ich persönlich arbeite gerade an einem Projekt in dem beides benutzt wird.
Dort habe ich ein generisches Repository das alle Basisfunktionen mitbringt wie: Get(), GetAll(), Delete() und Save(). Alle Funktionen sind natürlich virtual zum überschreiben.
Die Abfragen, Persistieren und Löschen läuft nur über die Repositories, da gerade beim Löschen einiges an Handarbeit anfallen kann. So kann ich bequem einfach vom generischen Repository ableiten und mir spezifizierte Repositories bauen.

Bei einigen Fällen habe ich auch Collections auf meinen Entitäten und ich greife meistens direkt auf diese zu anstatt die über ein Repository zu holen, da ich sowieso immer die gesammte Collection bearbeiten muss und nicht nur einzelne Datensätze daraus.
Sollte man die Collection vorher noch filtern müssen, wäre es wirklich ratsam ein Repository zu bemühen um die gefilterte Collection zu bekommen, anstatt auf der Collection auf der Entität zu arbeiten - so wie es Abt schon beschrieb - da man sonst unnötig Datensätze aus der DB lädt.

Der allgemeine Vorteil den ich an Repositories sehe ist:*Man kann relativ einfach die Repositories austauschen wenn man die DB oder den OR-Mapper wechseln muss. *das Repository Läd/Speichert immer nur mit Transaktionen, somit muss man das nicht immer expliziet bei jeder Aktion angeben.

• Standardisierung beim Speichern von ApplicationNames wenn sich mehrere Anwendung die gleiche DB teilen.

Wie ich oben schon bemerkte, ist das von Projekt zu Projekt unterschiedlich, aber ich würde euch empfehlen Repositories zu nutzen. Da das Projekt dadurch wartbarer und leichter zu erweitern wird.

MfG
Rabban

Hallo Rabban, Halo Abt,

* Einheitliche Abfragen, Applikations-weit standardisierte Abfragen (Sortierung & Co)

Dann hätte ich aber lieber die Abfragen als Objekt (siehe DetachedCriteria/ICriterions) und so eine Schnittstelle zum einhacken in den ORM sollte besser im ORM sein und nicht "außernherum" gebaut. Aber dafür können die Leute die den ORM verwenden nichts. 😃

* Direktes Kompilieren der Queries -> Performance-Steigerun

Gilt ja nicht für jeden ORM.

•Man kann relativ einfach die Repositories austauschen wenn man die DB oder den OR-Mapper wechseln muss.

Also DB wechseln sollte der ORM können! Aber ORM wechselen ist ein Argument.

•das Repository Läd/Speichert immer nur mit Transaktionen, somit muss man das nicht immer expliziet bei jeder Aktion angeben.

Also das Transaktions-Handling sollten die Entwickler schon im Auge behalten, trotz aller Einfachheit und Abstraktion ist das so wichtig, dass mir es lieber ist wenn man es nicht ignoriert.

•Standardisierung beim Speichern von ApplicationNames wenn sich mehrere Anwendung die gleiche DB teilen.

Das ist jetzt aber schon sehr spezielle, oder?

Gruß
Juy Juka