Laravel存儲庫模式和多對多關係

Question

在我們的新項目中，我們決定使用六邊形架構。我們決定使用存儲庫模式來獲得更多的數據訪問抽象。我們使用命令總線模式作爲服務層。 在我們的儀表板頁面中，我們需要大量數據，因此我們應該使用3級多對多關係（用戶 - >項目 - >技能 - >審查），同時技能也應該處於活動狀態（狀態= 1）。

問題在這裏上升，我應該把這個放在哪裏？

1. $ userRepository-> getDashboardData（$ userId）。

2. $ userRepository-> getUser（$ userId） - > withProjects（） - > withActiveSkills（） - > withReviews（）;

3. $ user = $ userRepository-> getById（）; $ projects = $ projectRepository-> getByUserId（$ user-> id）; $ skills = $ skillRepository-> getActiveSkillsByProjectsIds（$ projectIds）;

在這種情況下，我找不到存儲庫模式的好處，除了編碼接口可以通過模型接口實現。 我認爲解決方案3是完美的，但它增加了很多工作。

Answer 1

您必須從面向對象的角度決定（例如）返回的「用戶」是否具有其中的一組技能。如果是這樣，返回的用戶將已經擁有這些對象。

在使用常規對象的情況下，儘量避免使用子實體，除非它是合理的。例如，.. '用戶'實體負責確保子實體按業務規則進行操作。傾向於使用其他存儲庫來根據任何其他條件來選擇其他類型的實體。

以這種方式談論「關係」會讓我覺得你正在使用ActiveRecord，否則他們只是子對象。關係數據庫中存在「關係」。如果你像AR一樣混合數據庫記錄/對象，它只會悄悄進入你的對象。

在使用ActiveRecord對象的情況下，您可能會考慮在存儲庫上使用特定的方法來加載正確配置的成員對象。 $members->allIncludingSkills()或者什麼的。 這是因爲您在返回多個實體時必須解決N + 1問題。然後，您需要對結果集使用eager-loading，並且您不希望爲每個請求使用相同的加載配置。因此，您需要一種方法來爲每個請求描述配置。一種方法可以執行此操作將針對不同的請求調用存儲庫上的不同方法。

但是，對於我..我不希望有一堆對象只是..無限伸手可及..例如..你可以有一個$member->posts[0]->author->posts[0]->author->posts[0]->author->posts[0]。

我寧願儘量保持「平坦」。

$member = $members->withId($id); 
$posts = $posts->writtenBy($member->id); 

或類似的東西。 （只需打開我的頭頂）。

沒有人喜歡噸的嵌套數組和ActiveRecord可以被濫用的地步，其對象本質上是數組與方法和潛力無限嵌套。所以，它可以成爲處理數據的便捷方式。我會努力防止濫用關係作爲一個概念，並儘可能保持結構平坦。

這不僅非常有可能在沒有ORM「關係」功能的情況下編碼..它通常更簡單..您可以看出，此功能增加了很多麻煩，因爲ORM必須提供多少功能才能嘗試減輕疼痛。

真的，這有什麼意義？它只是讓你不必使用特定成員的ID來進行查找？也許，我猜猜看，有很多不同的事情會變得更容易？

如果您希望能夠獨立測試您的代碼，那麼在ActiveRecord的情況下，存儲庫實際上特別有用。否則，您可以創建範圍，而不是使用Laravel的內置功能來防止在任何地方都需要冗餘（因而易碎）的查詢邏輯。

創建特別爲UI存在的模型也是完全合理的。 例如，您可以使用多個ActiveRecord模型，該模型使用相同的數據庫表，僅用於特定的用戶界面用例。儀表板爲例。如果你有一個新的用例..你只需創建一個新的模型。

這對我來說是設計系統的核心。問自己..好吧，當我們有一個新的用例時，我們需要做什麼？如果答案是肯定的，那麼我們的架構確實是這樣的，我們只是這樣做，而我們並不需要惹惱其他人......那麼太好了！否則，答案可能更像..我不知道..我想修改一切，並希望它的作品。

有很多方法來處理這個東西。但是，我會建議避免使用大量複雜的工具來換取更簡單的方法/解決方案。存儲庫是抽象數據持久性以允許單獨測試的好方法。如果您想單獨測試，請使用它。但是，我不確定我在銷售ORM關係如何使用對象模型方面賣得很多。

例如，我們是否擁有一些包含以下內容的大量成員對象？

• 所有評論過該成員留下
• 所有技能部件具有
• 所有建議該成員已取得
• 所有朋友邀請的成員已派出
• 所有的朋友，成員有已建立

我不喜歡這些大型對象的想法，這些對象被設計成僅僅是容器的絕對一切G。我更喜歡將對象分解爲專門爲用例設計的位。

但是，我在散散步。總之..

1. 不要濫用ORM關係功能。
2. 最好有多個專門爲用例設計的小對象，而不是一些可以完成所有工作的大對象。

只是我2美分。