Fractal這樣的圖書館屬於哪裏？

Question

我正在研究Fractal（tldr：數據對象/集合到json格式化庫），並看到了使用它的一些好處。然而，它的功能似乎跨越了我正在處理的多個應用程序層。因此出現了一個問題 - 使用Fractal的代碼屬於哪裏？模型，服務，控制器，其他地方？在項目文檔的文檔中給出的示例似乎贊成將其放在控制器中或正確的路由回調（更復雜的示例似乎來自Laravel應用程序，作者在他的API書中提到它）。

我的擔心是耦合 - 如果我將它放在控制器中，就像大多數使用示例所示的那樣，那麼我將來會非常注意它。我的第一本能是抽象一點，將抽象概念綁定到合約上，然後再使用它。可能聽起來超過了工程設計，但我正在研究的API「有抱負」爲JSON-API兼容，因此將這樣的「json格式化程序」換成別的東西聽起來不那麼瘋狂。除此之外，我仍然需要格式化錯誤信息，而Fractal似乎根本就沒有觸及。

我想利用對Eloquent的paginator和嵌入式資源的支持，因爲這總是很痛苦。只有做到這一點，在演示/控制層纔會變得尷尬（至少可以說）。即使在Fractal文檔中，他們也會在控制器類中添加一些額外的方法來製作Fractal對象。這對我來說似乎有點奇怪，但也許只是我。這就是爲什麼要在這裏。

我知道這可能是一個偏好問題，但我指望有人有合理的聽起來一個:)。或者也許是一個更好的解決方案，請記住自動化和遵從性是主要原因。

Answer 1

我曾經爲我的應用程序需要連接的專有系統的API類做了一次這樣的事情。 API返回的對象看起來很像模型，所以我爲我需要的對象實現了一些類，並實現了一個庫來使API調用並返回對象。幸運的是，我只需要讀取API的訪問權限，所以我的庫只實現了可用操作的一小部分。

也許你可以將你需要的所有功能（包括分形和任何雄辯功能）抽象到你定義了一個接口的庫類中。這樣所有的Fractal代碼都在一個地方，如果你需要替換它，你只需重寫自定義庫類（這可能是很多工作，但可能比查找分散在代碼中的引用更好）。