Repository-pattern und Business-Logik

Habe ich ein repository ( CustomerRepository ), ruft Daten aus der Daten-Schicht. Die meisten der business-Logik in den entity-Klasse ( Customer ), dass das repository entweder akzeptiert oder zurückgibt.

Aber, wo stellst du die Globale Entität, die business logic (das gilt für alle Kunden)?

Zum Beispiel, ich kann nicht wollen, um alle Kunden zu bestimmten Benutzern. Ich will nicht zu setzen, die Logik in der repository.

InformationsquelleAutor Dan dot net | 2009-06-18

  1. 21

    Ich Stimme mit Robert Munteanu.

    Grundsätzlich, wenn Sie roll-up-your business-Logik, ist nicht inhärent in Ihrem Modell in eine middle-tier. Die mittlere Ebene ist die business-Schicht /business objects /business-Logik-Schicht /etc, aber nur bezeichnet als service-tier. Es muss nicht sein einen webservice, die eine Breite Verwendung des Begriffs service, dass es Aggregate, die Funktionalität von einem bestimmten Anwendungsbereich.

    Würden Sie im Grunde einen CustomerService-Klasse, die enthält die repository-Referenz. Die Präsentationsschicht würde Verweis auf die service-Ebene-Klasse.

    Gibt es eine weitere Unterscheidung, die gemacht werden können, als eine Vermutung aus Ihrem Namen, den Sie verwenden .net, und wahrscheinlich mithilfe von LINQ to SQL-repository, wie in NerdDinner.

    Repository in der Regel gibt IQueryable um die service-Schicht, so dass der service-layer-Kette zusammen mehrere Abfragen erstellen unterschiedliche Ergebnismengen. Der Service wertet dann den Ausdruck mit ToList oder eine andere ähnliche Methode und gibt zu, dass der presentation layer.

    Die MVC Storefront von Rob Conery ist das, was sich mir auf dem repository-Muster, aber leider hat er umgestaltet werden, die service-Schicht aus, ohne wirklich zu erklären, dass die Entscheidung in den videos. Also ich war besorgt, dass dies möglicherweise nicht der beste Weg.
    Ich war konfrontiert mit einem ähnlichen Problem, ist das die beste Architektur? Ich hielt sich Gedanken über Schnittstellen mit Verträgen, die auf der Oberseite der Schicht mit Fabriken und nur darauf bedacht ist, es funktioniert. Ich finde zu oft sind die Menschen weit über die Architektur-Lösungen. Ist der Zweck, zu bauen in diesem moment eine codebase, eine Hommage an seine eigene Mächtigkeit und Vollkommenheit der Schichten und Ebenen? Ich denke, so lange, wie Sie Ihre Daten speichern, Sachen in Ihrem repository haben, sollten Sie Ihre "business-Logik" in Ihren business-services und UI-Sachen in Ihren Ansichten, die Sie sind gut zu gehen. Vollbringen, was die software tun soll, umgestalten, wie Sie gehen
    und erreichen das Ziel der software.
    Lähmung jetzt>
    Rückkehr IQueryable<T> aus den repositories Ruinen die Daten zugreifen Abstraktion repository gibt Sie aber. Ein IQueryable ist ein Objekt, das gibt Ihnen die Möglichkeit, Daten abzufragen, es nicht geben Ihnen die Daten. Da ist es sehr schwer zu schreiben unit-tests für Ihre service-Klassen, denn Sie haben für den Umgang mit der zugrunde liegenden Datenbank in Ihre Dienste nun (nicht alle Linq-Anbieter implementieren alle extension-Methoden). Wenn Ihr repository gibt materialisierten Daten haben, können Sie nur mock-Weg in unit-tests und nicht darum kümmern, wenn Sie Ihre backing-store ist eine SQL-Datenbank, oracle, file-system, ...

    InformationsquelleAutor blu

  2. 7

    Wickeln Sie es hinter einem service.

    Was bedeutet das überhaupt in diesem Fall?
    Ich habe irgendwie das denken von Dienstleistungen, als einen Ort für alles, was sonst noch in der Domäne-Modell.
    Stimmen. Erstellen CustomerService mit einer Methode, wo das update allen Kunden.

    InformationsquelleAutor Robert Munteanu

  3. 5

    Legen Sie es in ein anderes repository (BusinessRuleRepository) und haben CustomerRepository verwenden.

    ODER

    Wenn die business-Logik ist nur die Begrenzung der Ergebnisse, die ein Benutzer sehen kann, die Sie möglicherweise verwenden möchten, eine Fassade-Muster, mit einer Fabrik. In diesem Fall würden Sie haben eine ICustomerRepository, dass Griffe Ihre CustomerRepository und LimitedCustomerRepository (die Kapseln CustomerRepository), und eine CustomerRepositoryFactory, gibt die entsprechenden ICustomerRepository für den Benutzer.

    InformationsquelleAutor C. Ross

  4. 0

    Ich denke, dass die Trennung dieser Arten von Funktionen in einer service-Schicht ist der Weg zu gehen.

    Vor kurzem habe ich ein system gebaut, das zu tun, komplexe Prognosen mit vielen Entitäten, die mit historischen Daten. Dass alle Daten zugreifen bits, die in das repository für jede Entität. Die komplizierten Prognose Logik hielt ich in einer service-Schicht und übergeben die repository-Objekte wie benötigt werden.

    Zusätzlicher bonus war, dass ich hatte eine einfache Möglichkeit zu setzen alle Prognosen Logik auf externen Systemen einfach durch das erstellen einer web-api-Schicht.

    InformationsquelleAutor WouldRatherBuildAMotor

Schreibe einen Kommentar