目前正在构建一个从另一个 API 提取数据的 API。
考虑到整个瘦/胖模型/控制器的论点，我只是有点不确定我应该如何表示一些数据，并且我无法找到明确的答案，所以我希望在这里对此进行讨论。
由于模型代表与数据的交互，因此感觉就像我的调用被映射到使用 Fractal 或 Jenssengers "Laravel Model" 之类的模型中。
目前我的控制器中有发送发送请求的操作，但感觉这对控制器来说责任太大了。
所以我只是想就 Laravel 项目中我应该把这个逻辑放在哪里提出一些意见！
谢谢
编辑：
从进一步的研究看来，存储库设计模式可能是一个可能的解决方案！
【问题讨论】：
标签： php laravel model-view-controller
这两种方法都不是特别好的解决方案。实际上，控制器负责处理 HTTP 请求，您的模型代表您的业务领域。那么第三方数据在哪里适合呢？
嗯，数据本身可能应该由模型来表示。但是，从第三方提供商获取数据的方法实际上应该委托给服务提供商，然后您可以轻松切换到使用不同的 API，从而将您自己与单个提供商解耦（最简单的例子是支付网关，有您在控制器中为 Paypal 集成而硬编码的所有逻辑将使得以后添加第二个付款选项变得极其困难。
举个例子；假设您有一个应用程序，可以为用户提供他们最喜欢的足球队的最新结果。
您的应用程序可能具有以下端点：
/team/{team}/players
/team/{team}/fixtures
/team/{team}/results
这些可以映射到以下控制器方法：
PlayerController@getPlayersInTeam($team);
FixturesController@getFixturesForTeam($team);
ResultsController@getLatestResultsForTeam($team);
请注意，这里有三个不同的控制器，而不是一个控制器。通过这种方式，您可以将控制器分配给您希望返回给用户的模型的 type。
现在显然，您不应该在每个控制器中进行 API 调用。但是，你为什么要在你的模型中这样做呢？术语“瘦控制器，胖模型”是一种反模式，它确实弊大于利。
为什么不使用专门负责从 API 为您的模型获取数据的服务？
interface FootballTeamData
{
public function getPlayersInTeam(Team $team);
public function getTeamFixtures(Team $team);
public function getTeamResults(Team $team);
}
现在，您可以实施此合同并轻松切换从第三方获取数据的方式，而无需接触您的模型 - 这是您的业务领域，因此不应该与第三方 API 高度耦合.
您现在还可以从瘦控制器、和瘦模型中受益。没有理由不存在只有几行代码的类，也不应该是胖的。
祝你好运！
【讨论】：