我今天正在研究Fractal（tldr：数据对象/集合到json格式库），并看到了使用它的一些好处。但是，它的功能似乎跨越了我正在处理的应用程序的多个层次。因此出现了一个问题 - 利用Fractal的代码属于哪里？型号，服务，控制器，其他一些地方？项目文档文档中给出的示例似乎倾向于将其放在控制器中或者正确的路由回调中（更复杂的示例似乎来自Laravel应用程序，并且作者在其关于API的书中提到过它）。
我担心的是耦合 - 如果我把它放在控制器中，正如大多数用法示例所示，那么我将来会对它进行相当的约束。我的第一直觉是将它抽象一点，将该抽象绑定到契约然后再使用它。可能听起来过于设计，但我正在努力的API正在实现＃34;要符合JSON-API，所以交换这样一个＆＃34; json格式化程序＆＃34;对于别的东西听起来不那么疯狂此外，我仍然需要格式化错误消息，而Fractal似乎根本没有触及它。
我想利用对Eloquent的分页器和嵌入式资源的支持，因为这总是很痛苦。只有这样才能使它在演示/控制层尴尬（至少可以说）。即使在Fractal文档中，他们也会向控制器类添加一些额外的方法来准备Fractal对象。这对我来说似乎有点奇怪，但也许它只是我。这就是为什么要把它放在这里。
我知道这可能是一个偏好问题，但我指望某人有一个合理的声音:)。或者也许是一个更好的解决方案，请记住自动化和json-api合规性是关键原因。
答案 0 :(得分：0)
我用一个专有系统的API类做了一次，我的应用程序需要与之接口。 API返回的对象看起来很像模型，所以我为我需要的对象实现了许多类，并实现了一个库来进行API调用并返回对象。幸运的是，我只需要对API的读访问权限，因此我的库只实现了可用操作的一小部分。
也许您可以将所需的所有功能（Fractal和任何Eloquent功能）抽象到已定义接口的库类中。这样所有Fractal代码都在一个地方，如果你需要替换它，你只需重写你的自定义库类（这可能是很多工作，但可能比搜索整个代码中散布的Fractal引用更好）。