nicht angemeldet
Tach!
ich möchte auf die Frage die ich bereits von 22.08 gestellt habe aufgreifen. Bezogen auf das Beispiel Repository (leider in Englisch aber nicht tragisch) erkenne ich die strukturen aber nicht die eigentliche Funktion, weil es, wie mir scheid, BuiltIn-Funktionen sind (oder externe Funktionen, Packages, PlugIns).
Die eigentlichen Funktionen sind hier nur Ein- bis Zweizeiler, weil das Entity Framework (ein ORM) die meiste Arbeit erledigt, um mit dem DBMS zu sprechen. Zudem ist für dieses Beispiel nicht viel zu tun. Stell dir vor, es käme noch weitere Funktionalität hinzu, wie das Filtern nach bestimmten Werten oder das Sortieren. Der Controller gibt nur die Parameter ans Repository und das kümmert sich darum, mit dem ORM (oder welcher Datenbankzugriffslogik auch immer) zu sprechen und die Parameter wie gewünscht zu übergeben.
Kurz gesagt: Der Controller möchte nur Daten haben oder loswerden. Es interessiert ihn nicht, wie genau das passieren soll, das übernimmt das Repository.
Ich hatte gedacht das die BuisenessLogic und Database das Repository eine Zwischenklasse/n ist/sind die Objekte so modifiziert, dass sie sich bequem in eine Ablage stapeln lassen, in dem Fall Database. Im beispiel sehe ich nichts von SQL noch keine Interaktion der Datenbank mit SQL.
Soweit richtig, aber da ist noch eine weitere Schicht zwischen Repository und der Datenbank, nämlich der ORM in Form des Entity Frameworks im Falle des verlinkten Beispiels.
Controller - Repository - Datenbankzugriff (z.B. ORM) - Datenbank
Es kann sein, dass die Business-Objekte umgebaut werden müssen. Ein Schüler-Objekt, das eine Liste der belegten Kurse in einer Eigenschaft hat, wird im DBMS in zwei Tabellen abgelegt. Das Repository kümmert sich darum, dass in Richtung ORM die beiden Tabellen angesprochen werden. Es kann auch sein, dass das Repository weniger zu tun hat, nämlich dann, wenn der ORM bereits Informationen zu den Beziehungen hat (zum Beispiel aus den Fremdschlüsseln analysiert), und selbständig die Kurse des Schülers liefern kann. Dann muss das Repository nur noch in Auftrag geben, die Daten von Schüler X zu besorgen, "aber bitte inklusive Kurse", anstatt neben den Schülerdaten eine zweite Abfrage zu den Kursen mit where ID_Schüler=X abzusetzen. Wenn sich die Daten auf solch eine einfache Weise aus dem ORM holen lassen, kann man auch auf die Zwischenschicht Repository verzichten. Und das ist auch der Fall, wenn man die Einsteigertutorials zum ASP.NET MVC anschaut, die kommen ohne Repository aus.
Nochmal der Hinweis, Respositorys sollten/müssen kein Bestandteil eines MVC-Frameworks sein. Die Businesslogik und damit welche Abfragen an die Datenhaltung gestellt werden müssen, kennt nur der Verwender. Es gibt nichts, das man ihm in irgendeiner Form sinnvoll vorbereiten könnte, das über grundlegendes CRUD hinausgeht. Aber das bietet bereits ein guter ORM.
dedlfix.
Rolf B