我正在构建一个 Laravel 5.3 应用程序，该应用程序从多个潜在来源中提取数据。这是一个具有 3 个来源的后备系统：
所有 3 个来源都非常简单，可以通过以下两种方法以相同的方式访问：
function get($id)function query($type, $string)我知道围绕实现此功能的不同方法有各种术语，但在阅读文档后我不确定最干净的方法是什么。每个数据源是否应该实现为Repository？包裹在容器中的ServiceProvider？我发现文档很详尽，但也缺乏整体/高级别的解释，所以任何指针都值得赞赏。
【问题讨论】：
标签： php laravel laravel-5.3 service-provider laravel-facade
使用类似集合的接口在域和数据映射层之间进行调解，以访问域对象。 Repository 封装了持久化在数据存储中的一组对象以及对它们执行的操作，从而提供了持久层的更加面向对象的视图。 Repository 还支持在域和数据映射层之间实现清晰分离和单向依赖的目标。
考虑到这一点，你可以说 Eloquent 本身是存储库模式的一个更大的实现，但它仍然是一个存储库。因为它是一个 ActiveRecord 实现，所以 Repository 和 Storage 机制之间没有任何真正的分离。
具体到您的问题，Laravel 不会真正涵盖存储库模式本身，就像它不涵盖服务类或单例一样：教您这些模式不是 Laravel 的责任，它只是为您提供手段如果您选择实施这些模式，则可以更轻松地组织这些模式。
说了这么多，我同意你的观点，每个数据源都实现自己的RepositoryInterface。从那里，您可以注册自己的ServiceProvider，然后实例化一个自定义服务类，其目的是返回适当的存储库。
如果确定适当的存储库在逻辑上很简单，并且仅依赖于负责备用数据源的控制器，则您可以使用Contextual Binding 并完全跳过服务类。
不管怎样，有几种方法可以给这只猫剥皮，但你走在正确的轨道上。
编辑：顺便说一句，如果您想严格按照“书本”行事，您可能希望分离出分别连接到每个数据存储的不同存储类，您然后可以酌情查询。然后，您的存储库（无论其存储来源如何，都可能包含相同类型的数据集合）可以对返回的结果负责。
否则，如果您想尽可能坚持使用 Eloquent，您可以查看 multiple data connections 来容纳您的每个数据集。
【讨论】：