清潔架構：服務器上的交互邏輯

我一直在玩Clean Architecture和VIPER。清潔架構：服務器上的交互邏輯

昨天有朋友問我爲什麼不把Interactor邏輯放在服務器上，只是將處理後的數據同步到iOS客戶端，而不是發送原始數據和處理Interactor。這將帶來很多好處，因爲可以隨意更改邏輯，在多個客戶端（例如iOS和Android）上覆制的代碼較少等。

例如，假設我們有一個Profile s和Post s的列表。每篇文章都有一個圖片和一個profileID。

假設我們想要一個顯示所有帖子圖片的表格視圖的屏幕，當用戶點擊帖子時，我們會在單獨的屏幕上顯示相應的配置文件。在配置文件中，我們將顯示該配置文件發佈的名稱和所有圖像。

如果我們把客戶端上的邏輯，我們會同步數據是這樣的：

{ 
    profiles: [ 
     { 
      id: "...", 
      name: "..." 
     }, 
     ... 
    ], 
    posts: [ 
     { 
      profileID: "...", 
      imageURL: "..." 
     } 
    ] 
}

那麼我們就會有一個ShowPostsInteractor，將剛剛返回數據的所有帖子和ShowProfileInteractor，這將過濾的帖子數據抓取剛剛從該配置文件的職位，那麼這將某些數據返回的觀點一樣，：

{ 
    name: "...", 
    imageURLs: ["...", ...] 
}

的第二個選擇是在服務器上保留這個邏輯，在這種情況下，同步處理數據將是：

{ 
    profiles: [ 
     { 
      id: "...", 
      name: "...", 
      imageURLs: ["...", ...] 
     }, 
     ... 
    ], 
    posts: [ 
     { 
      profileID: "...", 
      imageURL: "..." 
     } 
    ] 
}

（注意profiles加入imageURLs）

而且ShowProfileInteractor將只是通過配置文件數據，因爲它是認爲，因爲它不必再篩選職位（這是由服務器完成）。

當然，第二種方法重複了一些數據，但因爲它只是字符串，所以這不會非常相關。

我見過更經常做的第一種方法。所以我的問題是，爲什麼我不做第二種方法（在服務器上留下儘可能多的邏輯），或者從客戶端刪除所有交互器，讓控制器直接訪問網關，因爲不會處理數據？

來源

2016-07-26 Rodrigo Ruiz

我可能是錯的，但我不認爲乾淨建築的設計是考慮到移動或SPA應用程序。我一直認爲它是一個以服務器端的交互器爲中心的老式Web應用程序。

的理由是，該建築應該是

獨立的用戶界面。用戶界面可以輕鬆更改，而不需要更改系統的其餘部分。一個Web UI可以使用控制檯界面來代替，例如，在不改變業務規則

推交互件到客戶端失敗這一目標，IMO。

來源

2016-07-27 12:07:09 guillaume31

所以你會實施我給的第二個例子？另外，至於移動的清潔架構，看看VIPER（https://www.objc.io/issues/13-architecture/viper/） –

好吧，所以它看起來像他們把服務器視爲另一個數據存儲。這是有道理的。我仍然不完全相信Clean Architecture非常適合移動設備。 '在iOS應用程序或控制檯應用程序中可以使用相同的Interactor'，如VIPER中所述，與'用另一個UI替換UI'不完全相同。一般來說，能夠推遲移動設備中的架構決策比Web應用程序IMO中的要少得多。 – guillaume31

關於你的問題，我會說是的，特別是如果你打算增加更多的移動平臺。用多種客戶語言編寫交互器使其不易維護。但是，您願意在服務器和客戶端上進行多少處理也是該等式的重要組成部分。我不知道VIPER是否適合將交互器移到服務器端。 – guillaume31

清潔架構：服務器上的交互邏輯

回答

相關問題