在PHP中使用Fractal比使用toArray()有什么优点

Question

我偶然发现了PHP and Fractal，它的目的是确保存储和输出(客户端)之间的输出格式。

我使用API已经有一年多了，我已经为我希望返回的大多数实体构造了toArray()函数。在Eloquent的帮助下，如果您已经将实体模型附加到Eloquent模型，您还可以重载toArray()函数并从中进行修饰。

示例：

public function toArray()
{
    $array = parent::toArray();
    $array['extra'] = true;
    ...
    return $array;
}

如果Apis应该是快速和轻量级的，那么PHP and的Fractal相对于实现toArray()或具有来自存储库/管理器的格式($data)函数有什么优势？是因为OOP吗？如果是这样的话，谁能举个例子？

Answer 1

对我来说这样做的好处是：

通过通过Fractal的资源objects

• ability传递模型来强制执行
• 一致响应格式，以便通过简单的序列化程序切换(例如，从json-api到hal，甚至更多)，相当容易地更改整个应用程序的响应格式。对于json-api，它会做一些无聊的事情，比如拆分实际的响应数据和根元数据。此外，您可以很容易地更改响应依赖于Accept头，这可能很难使用数组(您需要重新构造它，当然您不希望在控制器中出现这种混乱)。
• 自动生成链接，例如，用于分页

我认为前两个不是Fractal所独有的，而是对响应格式化进行抽象的目的。

对我来说不清楚的是，像Fractal这样的东西属于哪里？我非常支持这样的观点，即模型应该能够表示自身，就像它对__toString所做的那样。但话又说回来，有人可能会说，这更多的是对演示文稿的关注，而不是模型。使用分形的分页，嵌入支持变得更加不清晰，因为这(对我来说)偏离了表示本身的范围。

速度问题当然是有道理的，但你可以在其他地方进行优化，例如，如果你没有基础设施，可以将整个响应内容缓存在清漆或一些执行类似角色的laravel包上(需要注意的是，它并不适用于所有用例，授权的或各种特定于用户的响应就是最好的例子)。

至于示例，除了包文档之外，我还可以推荐两个：

• http://www.sitepoint.com/fractal-practical-walkthrough/
• http://laravelista.com/laravel-fractal/

我很想看看像Fractal这样的东西是如何适应更大的结构化项目的。