Gibt es im Zusammenhang mit der n-Tier-Anwendung einen Unterschied zwischen dem, was Sie als Datenzugriffsklassen betrachten würden, und Ihren Repositories?
Ich tendiere dazu, ja zu denken, aber ich wollte nur sehen, was für ein anderer Gedanke. Ich denke, der Job des Repositorys besteht darin, die rohe Abfrage selbst zu enthalten und auszuführen, wobei die Datenzugriffsklasse den Kontext erstellt, das Repository ausführt (den Kontext übergibt) und das Datenmodell dem Domänenmodell zuordnet und das Ergebnis zurücksenden ...
Was denkt ihr? Wird in einem Linq to XML-Szenario auch eine Änderung angezeigt (vorausgesetzt, Sie ändern den Kontext für das relevante XDocument)?
Prost Anthony
UPDATE:
Dies ist die Art und Weise, in der ich normalerweise zuvor Dinge implementiert hätte:
%Vor%Sehen Sie irgendwelche inhärenten Probleme hier mit dem Muster im Allgemeinen ...
Was das Repository anbetrifft, in dem ich gedacht habe, es zu verwenden, ist es, anstatt die Abfrage direkt in der GetAll-Methode von TermDa zu haben, ich würde es so ändern, dass es eher so aussieht:
%Vor%Seht ihr, wie es funktioniert oder nicht? Mit oder ohne das Repository sehe ich, dass eines der beiden die Business-Schicht vollständig davor schützt, etwas über die Datenzugriffsmethoden / -technologien zu wissen ...
>Ja, es gibt einen großen Unterschied.
Ein DAL (z. B. ein Tabellendaten-Gateway) ist ein Datenbank -Konzept. Es ist verantwortlich für die Ausgabe von Abfragen an die Datenbank und die Rückgabe von Datensätzen.
Ein Repository ist ein Domänen Konzept. Es ist dafür verantwortlich, strukturierte Anfragen zu akzeptieren und stark typisierte Objekte zurückzugeben.
In der Praxis sehr unterschiedlich.
Aktualisierung:
Die Frage scheint eine erhebliche Menge an Verwirrung widerzuspiegeln, also lassen Sie mich versuchen, mit einem Codebeispiel zu klären. Hier ist ein Entwurf, den Sie verwenden könnten, wenn Sie kein ORM verwenden und stattdessen alle Ihre eigenen Mappings durchführen. Nichts davon ist Produktionsqualitätscode, es ist nur für Bildungszwecke:
Datenzugriff:
%Vor%Domäne:
%Vor%Zuordnung:
%Vor%Repository:
%Vor%Macht das jetzt mehr Sinn? Die DAL beschäftigt sich mit Daten. Das konkrete Repository kann Datenzugriffsklassen kapseln, aber das abstrakte Repository (seine öffentliche Schnittstelle) behandelt nur Domänenklassen.
Noch einmal möchte ich die Leser daran erinnern, dass dies dem Code für Produktionsqualität noch nicht einmal nahe kommt und dass die meisten Apps heute ein ORM oder zumindest eine bessere Form des automatischen Mappings verwenden. Dies dient nur zur Veranschaulichung.
Sie scheinen einen guten Griff zu haben. "Datenzugriffsklassen" können viele verschiedene Formen annehmen. Es ist eine Art von Klasse, die etwas mit Datenzugriff zu tun hat. Ihr Repository ist (A) ein Muster zur Behandlung Ihrer Datenpersistenz und (B) ein Platz innerhalb Ihres Datenzugriffsschemas (wenn Sie ein Repository implementieren).
Eine Herausforderung Ihrer Datenzugriffsstrategie besteht darin, Flexibilität und wiederverwendbare Funktionen gleichzeitig bereitzustellen. Gleichzeitig effizient sein. Während Sie gleichzeitig mit Ihrer Geschäftslogik arbeiten, entkoppelt werden, aber auch zusammenhalten . Tricky.
Das Repository ist ein Muster, das vorgibt, mit diesem Gleichgewicht zu helfen. Ihr Code zum Übersetzen der db (oder was auch immer) zu / von Entitätsklassen befindet sich an einer Stelle für jede Entität. Ihre "Datenzugriffsklassen" können aus Ihren Repository-Klassen sowie aus Klassen bestehen, die SQL-Arbeit tatsächlich verarbeiten. Sie sollten sicherlich nicht alle SQL-Cruft in jeder Ihrer Repository-Klassen tun.
Beispiel: Sie könnten mit einer ineffizienten, aber einfachen Reflektion beginnen, um Ihre Entitätsobjekte auszufüllen, wobei Sie fast keine Arbeit in Ihren Repository-Klassen ausführen. Später können Sie es effizienter für Entitäten mit hohem Volumen machen, aber das ist vollständig von anderen Teilen Ihres Systems verborgen. Und später verschieben Sie einige Konfigurationen in XML, aber der Rest Ihres Systems hat keine Ahnung von dieser Änderung.
LINQ-to-sql und Entity-Framework nutzen das Repository-Muster wirklich aus, da das, was die Repository-Klassen zurückgeben, tatsächlich ein IQuerable dieser Entität ist. Business-Klassen können zusätzliche Kriterien anwenden, und diese Kriterien machen es tatsächlich zum sql, während sie weiterhin eine vollständige Kapselung aus der Datenpersistenz bereitstellen. Es ist wirklich cool.
Tags und Links linq linq-to-sql repository-pattern linq-to-xml