flux多個商店實例

Question

在一個flux應用程序中，通過所有者id將數據分爲多個存儲區，我們是否應該使用一個內部將數據分成多個存儲區的存儲區或每個存儲區一個存儲區實例？

例如，我們有一個應用程序用戶，他是多個運動員的教練。每位執教過的運動員都有零或更多的鍛鍊，並且教練可以同時查看一名或多名運動員的鍛鍊。

我們可以爲所有運動員提供一個健身房;商店必須確保將所有數據分成運動員桶，並且每個商店方法都需要運動員ID參數。

或者，我們可以爲每個運動員ID設置一個商店實例。這簡化了商店邏輯和方法簽名，但是我們必須管理更多商店實例。

有沒有人有這種方法的經驗？任何以這樣或那樣的方式進行的優點或缺點？或者，哪種方式是「流動方式」，爲什麼？

Answer 1

Flux的方式是創建單件商店。因爲我們習慣以ORM風格的MVC模式思考模型，所以它們不是模型。存儲僅在應用程序初始化的時刻實例化。他們管理邏輯和數據的「域」。

這些單件商店向調度員註冊回調。回調是數據進入商店的唯一方式。商店還提供getter方法作爲公共API--數據傳播的唯一途徑。沒有二傳手。商店是他們自己的世界，完全控制着他們的數據和行爲。

就你而言，聽起來像是運動員和鍛鍊的邏輯域，所以我會創建一個AthleteStore和一個WorkoutStore，並在它們各自的商店中維護這兩件事的集合。例如，我想像你會得到像getWorkoutsByAthleteID()這樣的獲得者。