所以我使用多個委托來傳遞槽資料，但我不知道這是否正確。我只想維護 1 個主要物件，以確保如果用戶存在/關閉應用程式，編輯資料將在不在 VC1 中時保存。現在通過使用委托，我確信資料在主物件中并且一切正常。你們能不能把我送到正確的方向，告訴我這是要走的路嗎？提前致謝！
VC1:
Main object, holds all data that needs to be saved
Delegate for VC2
VC2:
Specific object overview from VC1
Delegate for VC3
Delegate function called -> PassDataToVC1(editsForSpecificObject)
VC3:
Edit's data from specific object. -> Gives
Delegate function called -> PassDataToVC2(edits)
Maybe even a 4th VC depending what I'm going to do.
uj5u.com熱心網友回復：
對于您選擇的架構，您所做的基本上是正確的：
如果您有一個規則，即只有 VC1 知道完整資料并可以保存它，那么您需要將資料中的更改傳遞回 VC1。
如果您的規則是將資料傳遞回 VC1 的方式是使用協議和委托架構，那么您必須使 VC1 成為您的協議的委托。將單個物件（您的 VC1）擴展為采用多種協議并沒有錯；這確實是一個標準的 Swift 模式。
但是，我認為這對您來說很難看的原因是那些不是很好的規則。我將按相反的順序解決它們：
為什么要委托？在現代 Swift 中，有更簡潔的方式來傳遞資料。現代應用程式架構通常是反應式的，這意味著資料處理程式是該資料更改的發布者，并且資料的中央存盤訂閱這些發布者。因此，資料存盤可以直接聽到任何更改，而視圖控制器不必將這些更改特別發送給任何人。
為什么是視圖控制器？這可以說是您的架構中最薄弱的一點。視圖控制器知道關于資料存盤和保存它的機制的任何業務是什么？您應該有一個單獨的資料存盤物件，由一些安全持久的物件（例如應用程式委托）保留。這個物件存盤和保護資料，并且知道（或有一個知道的服務助手）如何持久化它。您可以使用依賴注入來處理參考將此物件傳遞給每個視圖控制器——這還具有使您的代碼非常可測驗的額外好處。更好的是，如果您將這個想法與我在上一段中概述的反應性的使用相結合，您將擁有一個干凈的“無接觸”架構，它可以正常作業，其中每個物件都只做自己的作業，而不是其他物件。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/384096.html