在PHP

Question

中使用分形而不是PHP的优势我偶然发现了PHP联盟Fractal，它表明目的是确保存储和输出（客户端）之间的输出格式。

我一直在使用API​​超过一年，并且我为大多数希望返回的实体构造了toArray（）函数。借助Eloquent，你可以重载toArray（）函数并从那里装饰，如果你已经用Eloquent模型附加了你的实体模型。

例子：

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

如果API应该是快，重量轻，不PHP联赛的分形有什么优势在实现toArray（）或有格式（$ data）函数从存储库/经理吗？这是由于OOP吗？如果有的话，有人可以举个例子吗？

Answer 1

对我的优点是：通过分形的资源通过模型执行

• 一致的响应格式对象
• 能力相当容易地与串行器的一个简单的开关改变整个应用程序的响应格式（例如，从json-api到hal以及可能更多）。对于json-api，它会执行无聊的事情，如分割实际的响应数据和根元数据。您也可以根据Accept标题轻松更改响应，这对数组来说可能更难（您需要对其进行重构，当然，您不希望控制器中出现混乱）。
• 自动化链接生成例如的，对于分页

我觉得前两个并不互斥分形，反而会具有响应格式的任何抽象的目的。

什么是我不清楚，是像Fractal属于哪里？我非常喜欢这种模式应该能够代表自己的观点，就像它与__toString一样。但是，人们可能会再次争辩说，这比演示模型更值得关注。通过使用分形的分页，嵌入支持变得更加清晰，因为（对我而言）会略微超出演示本身。速度问题当然是有效的，但你可以在别处进行优化，例如，通过将整个响应内容缓存在清漆或一些laravel软件包中，如果您没有基础架构，它们会执行类似的作用（注意，它不适用于每个用例，授权或不同的用户特定响应就是例证） 。

至于例子，我可以推荐两个，包文档旁边：

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

很想看到的类似分形怎么可以放入一个更大一些的书面记录，结构化项目。