Rolling Responsibility Pattern Repository

    In vielen Diskussionen über die Anwendbarkeit des Repository-Musters habe ich festgestellt, dass die Menschen in zwei Lager aufgeteilt sind. Im Rahmen dieses Textes werde ich sie bedingt als Abstraktionisten und Konkretisten bezeichnen. Der Unterschied zwischen den beiden besteht darin, wie sie sich auf die Bedeutung des Musters beziehen. Die erste Überlegung, dass es sich lohnt, ein Repository zu haben, ist da Hiermit können Sie die Details der Datenspeicherung abstrahieren. Die zweiten sind der Ansicht, dass wir diese Details nicht vollständig ignorieren können. Daher ist die Idee des Endlagers selbst bedeutungslos und seine Verwendung ist Zeitverschwendung. Die Auseinandersetzung zwischen ihnen wird in der Regel zu einem Holivar.

    Was ist los mit dem Repository? Natürlich ist alles in Ordnung mit dem Muster selbst, aber der Unterschied liegt im Verständnis der Entwickler. Ich habe versucht, dies zu untersuchen und bin auf zwei Hauptpunkte gestoßen, die meiner Meinung nach der Grund für die unterschiedliche Einstellung zu ihm sind. Eine davon ist die „rollende“ Verantwortung des Endlagers, die andere ist die Unterschätzung von Unit-Tests. Unter dem Schnitt werde ich das erste erklären.

    Umzugsverantwortung des Repository


    Beim Aufbau der Architektur einer Anwendung fallen jedem sofort drei Ebenen ein: eine Präsentationsschicht (Presentation Layer), eine Geschäftslogik (Business Layer) und eine Datenschicht (Data Layer) ( siehe MSDN ). In solchen Systemen verwenden Geschäftslogikobjekte Repositorys, um Daten aus physischen Speichern abzurufen. Repositorys geben Geschäftsentitäten anstelle von unformatierten Datensatzgruppen zurück. Dies ist sehr oft durch die Tatsache gerechtfertigt, dass wir, wenn wir den Typ des physischen Speichers (Basis, Datei oder Dienst) ersetzen müssten, eine abstrakte Repository-Klasse erstellen und einen bestimmten Speicher implementieren würden, den wir benötigen. Es sieht

    Bild

    ungefähr so aus: Martin Fowler und MSDN sprechen von der gleichen Trennung.. Wie üblich ist eine Beschreibung nur ein vereinfachtes Modell. Obwohl dies für ein kleines Projekt korrekt aussieht, ist es daher irreführend, wenn Sie versuchen, dieses Muster auf ein komplexeres zu portieren. Bestehende ORMs sind da noch verwirrender implementieren viele Dinge aus der Box. Angenommen, ein Entwickler kann nur mit dem Entity Framework (oder einem anderen ORM) Daten abrufen. Wo soll beispielsweise der Cache der zweiten Ebene oder die Protokollierung aller Geschäftsvorgänge abgelegt werden? In einem Versuch, dies zu tun, ist es offensichtlich, dass er versuchen wird, die Module nach Funktionalität zu trennen, der SPR von SOLID zu folgen und daraus eine Komposition zu erstellen, die möglicherweise so aussieht:

    Bild

    Spielt das Repository die gleiche Rolle wie zuvor? Die offensichtliche Antwort lautet "NEIN", da jetzt keine Daten aus dem Speicher abgerufen werden. Diese Verantwortung wurde auf eine andere Einrichtung übertragen. Auf dieser Grundlage entsteht die erste Diskrepanz zwischen den Lagern der Abstraktionisten und der Konkretisten.

    Anstelle einer Analyse


    Wenn wir in der Regel akzeptieren, dass alle Begriffe unabhängig von Codeänderungen ihre Bedeutung behalten sollen, ist es in der ersten Phase richtig, das Objekt nicht als Repository zu bezeichnen, das einfach Daten zurückgibt. Dies ist das DAO-Muster von reinem Wasser, weil Ihre Aufgabe ist es, eine bestimmte Datenzugriffsschnittstelle (Ling, ADO.NET oder etwas anderes) zu verbergen. Gleichzeitig weiß das Repository möglicherweise nichts über solche Details und sammelt alle Datenzugriffssubsysteme in einer einzigen Komposition.

    Denken Sie, dass ein solches Problem besteht?

    Jetzt auch beliebt: