在乾淨的MVP中，誰應該處理組合交互者？

我見過MVP架構的好例子（here和here）。兩者都只呈現簡單的交互器，但我想知道如何處理更復雜的用例，其中包含步驟，這些步驟在其他用例中重複出現。在乾淨的MVP中，誰應該處理組合交互者？

例如，我的API需要令牌來驗證任何電話。我創建了一個交互器來獲取該令牌（GetToken）。我想獲取用戶的最後一次登錄日期（GetLastLoginDate），然後獲取該日期和當前發生的更改列表（GetVersionChanges）。

這些交互器應該鏈接在哪裏？我想讓它們分開，因爲它們中的一些在代碼的其他部分被重用。我提出了兩種解決方案。

演示者應鏈接所有的交互器。這種解決方案只要用例不復雜並且沒有許多先決條件就可以工作。在我看來，這不是正確的地方，因爲它給主持人帶來了另一種責任。
交互器可以使用許多庫（沒有乾淨的建築規則被打破，然後）。爲什麼不在其他交互器中使用TokenRepository？因爲獲取令牌要比到達存儲庫複雜得多。重複其他交互器中的步驟不會重複使用已有的代碼。

這兩種解決方案都有缺陷，違背了基本原則（DRY，單一責任原則）。

來源

2017-12-18 canihazurcode

如果我是你，我會探微放在一個單獨的交互器（可能命名爲getTokenInteractor）獲得令牌的邏輯並調用交互器從您的其他交互器誰需要它。這樣，它會在交互器中選擇使用令牌（或者調用或不使用getTokenInteractor），也可以在交互器中檢索並處理錯誤。我會爲你的「getVersionChanges」用例做同樣的事情，讓一個交互器鏈接這些調用。

讓我們想象一下，你有一個主持人誰需要顯示的版本變化。他將調用第一個交互器（GetVersionChangesInteractor），他將首先檢查他是否有一個令牌（通過調用getTokenInteractor），然後調用GetLastLoginDateRepository檢索日期，並在該日期調用GetVersionChangesRepository並最終將結果提供給演示者。

這樣一來，你的業務邏輯可以在交互件費的100％，你的演示者可以專注他怎麼會顯示在屏幕上。

順便說一句，如果你的API需要一個令牌每叫你應該在一個攔截器將其移動，所以你不必在每次調用來對付它。

來源

2017-12-18 17:06:54 RDO

如果您想查看詳細示例，請在此處填寫以下主題：https：// plainionist。 github.io/Implementing-Clean-Architecture-UseCases/ – plainionist

這可能是MVPC模式是你所追求的。 This是我多年前寫的東西（儘管代碼示例很差，請原諒！）

來源

2018-01-24 10:11:50 muszeo

在乾淨的MVP中，誰應該處理組合交互者？

回答

相關問題