17

I need to implement logic which will be retrieve data from some remote datasource. And now I need to decide - which concept should I need: Provider, Repository or Service.

Actually I do not understand very well all great difference between that. Yeas, I know that repository is something more data specific and should not contain any business logic. Provider for other hand may contain some business rules in addition to manage data. And Service also could contain some business logic in addition to manage data. Then what is the difference between Service and Provider.

From the other point of view, I think that using service is better approach to show that it's an abstraction for remote access.

In conclusion: All this approaches looks reasonable and I completely confused with it. Will be pretty much appreciate if someone will help me with it.

Ph0en1x
  • 9,943
  • 8
  • 48
  • 97
  • 1
    http://stackoverflow.com/questions/623090/is-the-repository-pattern-the-same-as-the-asp-net-provider-model – Ray May 17 '14 at 21:33
  • http://forums.asp.net/t/1649824.aspx?Provider+Model+vs+Repository+Pattern – Ray May 17 '14 at 21:39

4 Answers4

14

The Repository and Service are not mutually exclusive. In fact, they are often used together.

The service layer sits on top of your domain objects and provides a coarse-grained interface for business operations. It usually describes the use cases of your application. The service layer uses repositories for obtaining your domain objects and delegates further execution to them where possible.

The Repository acts like a collection of persistent domain objects. It provides methods for finding the right objects using some criteria. It also provides methods for saving those objects.

The implementations of repository in the wild vary quite a bit. Repositories could provide methods like

List<Person> findPersonByName(String name)

or a more generic approach with criteria objects

List<Person> find(Criteria criteria)

Additional reading: service layer, repository

I'm not familiar with the Provider pattern.

Karen Joyce Lowe
  • 65
  • 6
Nefron
  • 699
  • 6
  • 11
2

In simple Words you have your service Service S that uses Repository R for database CRUD or search operations. Suppose that you have different services S1, S2, S3 each one have the same contracts (Interface) but different implementations, you need a provider that choose which one to use in what context. You can override the Provider Pattern using Dependency Injection so your code is less coupled and isn't reponsible for instanciating the services, your client will instantiate the proper service with DI Container

riadh gomri
  • 869
  • 1
  • 15
  • 21
1

All this approaches looks reasonable and I completely confused with it.

No wonder you're confused, since people seem to resort to Services and Providers for about anything and its opposite these days ;)

The Repository pattern is more precisely defined though : it's a set of objects of the same type that you can query from, add to or remove from, appearing as an in-memory collection to callers but actually mapped to a persistent storage behind the scenes.

What about finding a name that really depicts what your object does rather than using watered-down, rag bags of concepts ? I'm all for patterns and shared idioms that are immediately recognizable to all developers, but I can't see the use of words when they don't mean anything precise any more...

guillaume31
  • 13,738
  • 1
  • 32
  • 51
1

Repository encapsulates a specific data logic to get data, for example ICustomerRepository can have SqlCustomerRepository, MySqlCustomerRepository implementations. However, DataProvider abstracts data logic and uses configured means to resolve the data. Data can come from database, flat file or NoSql Database. Moreover, DataProvider's configuration can be changed within context unlike a repository implementation injected into a service. On the other hand, as Nefron explained that Service operates over business logic defined in entities.

Mohsin Syed
  • 1,449
  • 1
  • 9
  • 6
  • How about general "external" operations like "EmailSender" class? What would be its suffix? On the one hand its not a Repository not a DataProvider and on the other hand its not an internal application dependency so according to your answer we can't call it a Service. – Uri Abramson Feb 05 '17 at 14:12