2012-05-19 13 views
7

Ich muss Logik implementieren, die Daten von einer Remote-Datenquelle abgerufen werden. Und jetzt muss ich entscheiden, welches Konzept ich brauche: Provider, Repository oder Service.vergleichen Repository vs Provider vs Service

Eigentlich verstehe ich nicht sehr gut alle großen Unterschied zwischen dem. Ja, ich weiß, dass das Repository etwas mehr datenspezifisches ist und keine Geschäftslogik enthalten sollte. Provider für andere Hand kann einige Geschäftsregeln zusätzlich zu Daten verwalten. Und der Dienst könnte neben der Datenverwaltung auch eine Geschäftslogik enthalten. Was ist dann der Unterschied zwischen Service und Provider?

Aus der anderen Sicht, denke ich, dass die Verwendung von Service ist besser Ansatz zu zeigen, dass es eine Abstraktion für den Fernzugriff ist.

Fazit: All dies nähert sich sieht vernünftig und ich völlig verwirrt damit. Würde mich sehr freuen, wenn mir jemand dabei helfen würde.

+1

http://stackoverflow.com/questions/623090/is-the-repository-pattern-the-same-as-the-asp-net-provider-model –

+0

http://forums.asp.net/t /1649824.aspx?Provider+Model+vs+Repository+Pattern –

Antwort

8

Das Repository und der Service schließen sich nicht gegenseitig aus. In der Tat werden sie oft zusammen verwendet.

Die Serviceschicht befindet sich oben auf Ihren Domänenobjekten und bietet eine kursorientierte Oberfläche für Geschäftsvorgänge. Es beschreibt normalerweise die Anwendungsfälle Ihrer Anwendung. Die Service-Schicht verwendet Repositorys zum Abrufen Ihrer Domänenobjekte und delegiert die weitere Ausführung an sie, wo dies möglich ist.

Das Repository verhält sich wie eine Sammlung persistenter Domänenobjekte. Es bietet Methoden zum Finden der richtigen Objekte anhand einiger Kriterien. Es bietet auch Methoden zum Speichern dieser Objekte.

Die Implementierungen von Repository in freier Wildbahn variieren ziemlich viel. Repositorys konnte

List<Person> find(Criteria criteria) 

Zusätzliche Leseobjekte mit Kriterien Methoden wie

List<Person> findPersonByName(String name) 

oder einen generischen Ansatz bieten: service layer, repository

Ich bin nicht vertraut mit dem Provider-Muster.

0

All diese Ansätze sieht vernünftig aus und ich verwechselte komplett mit es.

Kein Wunder, dass Sie verwirrt sind, da die Menschen für alles und sein Gegenteil zu Dienstleistungen und Anbieter zu greifen scheinen in diesen Tagen;)

Das Repository Muster mehr definiert ist genau obwohl: es ist eine Reihe von Objekten ist des gleichen Typs, den Sie abfragen, hinzufügen oder entfernen können und der Anrufer als in-memory-Sammlung angezeigt wird, aber tatsächlich im Hintergrund hinter den Kulissen einem permanenten Speicher zugeordnet ist.

Wie wäre es, einen Namen zu finden, der wirklich darstellt, was Ihr Objekt tut, anstatt verwässerte Lumpenbeutel mit Konzepten zu verwenden? Ich bin immer für Muster und gemeinsame Redewendungen, die für alle Entwickler sofort erkennbar sind, aber ich kann die Verwendung von Wörtern nicht sehen, wenn sie nichts genaueres mehr bedeuten ...

0

In einfachen Worten haben Sie Ihren Service Service S, der Repository R für Datenbank CRUD oder Suchvorgänge verwendet. Angenommen, Sie haben unterschiedliche Dienste S1, S2, S3, die jeweils die gleichen Verträge (Interface) haben, aber unterschiedliche Implementierungen, Sie benötigen einen Provider, der entscheidet, welcher in welchem ​​Kontext verwendet wird. Sie können die Provider-Muster mit Dependency Injection außer Kraft setzen, damit Ihr Code weniger gekoppelt ist und reponsible nicht die Dienste für Instanziierung, Ihr Kunde den richtigen Service mit DI Container

0

Repository instanziiert kapselt eine bestimmte Datenlogik zu erhalten Daten, zum Beispiel ICustomerRepository, können SqlCustomerRepository, MySqlCustomerRepository Implementierungen haben. DataProvider abstrahiert jedoch die Datenlogik und verwendet konfigurierte Mittel zum Auflösen der Daten. Daten können aus der Datenbank, der Flat-Datei oder der NoSql-Datenbank stammen. Darüber hinaus kann die Konfiguration des DataProviders im Kontext geändert werden, anders als bei einer Repository-Implementierung, die in einen Service eingefügt wird. Auf der anderen Seite, wie Nefron erklärte, dass Service über Business-Logik in Entitäten definiert operiert.

+0

Wie wäre es mit allgemeinen "externen" Operationen wie "EmailSender" Klasse? Was wäre sein Suffix? Auf der einen Seite ist es kein Repository, kein DataProvider und auf der anderen Seite ist es keine interne Anwendungsabhängigkeit, so dass wir es Ihrer Antwort entsprechend nicht als Service bezeichnen können. –