我需要实现从某个远程数据源检索数据的逻辑。现在我需要决定——我需要哪个概念：Provider、Repository 或 Service。
其实我不太明白这两者之间的巨大差异。是的，我知道存储库是更具体的数据，不应该包含任何业务逻辑。另一方面，提供者除了管理数据外，还可能包含一些业务规则。Service 除了管理数据外，还可以包含一些业务逻辑。那么Service和Provider有什么区别。
从另一个角度来看，我认为使用服务是更好的方法来表明它是远程访问的抽象。
结论：所有这些方法看起来都很合理，我完全对此感到困惑。如果有人能帮助我，将不胜感激。
存储库和服务不是相互排斥的。事实上，它们经常一起使用。
服务层位于您的领域对象之上，并为业务操作提供粗粒度接口。它通常描述您的应用程序的用例。服务层使用存储库来获取您的域对象，并在可能的情况下将进一步的执行委托给它们。
Repository 就像一个持久域对象的集合。它提供了使用某些标准查找正确对象的方法。它还提供了保存这些对象的方法。
野外存储库的实现差异很大。存储库可以提供类似的方法
List<Person> findPersonByName(String name)
或更通用的方法与标准对象
List<Person> find(Criteria criteria)
我不熟悉提供者模式。
所有这些方法看起来都很合理，我完全对此感到困惑。
难怪您会感到困惑，因为如今人们似乎对任何事情都求助于服务和提供者，而这恰恰相反；）
存储库模式的定义更加精确：它是一组相同类型的对象，您可以从中查询、添加或删除，对调用者显示为内存中的集合，但实际上映射到幕后的持久存储。
如何找到一个真正描述您的对象所做的名称而不是使用淡化的、破烂的概念包？我完全支持所有开发人员都能立即识别的模式和共享习语，但是当它们不再意味着任何精确时，我看不到单词的使用......
简单来说，您的服务 Service S 使用 Repository R 进行数据库 CRUD 或搜索操作。假设你有不同的服务 S1、S2、S3，每一个都有相同的合约（接口）但不同的实现，你需要一个提供者来选择在什么上下文中使用哪一个。您可以使用依赖注入覆盖提供者模式，这样您的代码耦合度就会降低并且不负责实例化服务，您的客户端将使用 DI 容器实例化正确的服务
Repository封装了特定的数据逻辑来获取数据，例如 ICustomerRepository 可以有 SqlCustomerRepository、MySqlCustomerRepository 的实现。但是，DataProvider抽象了数据逻辑并使用配置的方式来解析数据。数据可以来自数据库、平面文件或 NoSql 数据库。此外，与注入服务的存储库实现不同，DataProvider 的配置可以在上下文中更改。另一方面，正如 Nefron 解释的那样，Service在实体中定义的业务逻辑上运行。