2014-07-16 127 views
0

我一直在想我的這一個頭......依賴注入VS單,動初始化

我工作的一個大項目,現在,應用程序正在採取的許多不同的服務優勢,因爲: 評論,喜歡,帖子,購買等..

我有一個類爲每個服務。

現在,我來到了一個地步,我想限制註冊用戶而已,對於一些行動,帖子,評論,等等..

截至目前每類使用只具有類的方法,如下所示:

@interface UpdateOrderServies : NSObject 

+(void)deleteOrder: (STOrder *)order 
     andReturn: (void(^)(NSError *error))errorBlock; 

+(void)updateOrder: (STOrder *)order 
     andReturn: (void(^)(NSError *error))errorBlock; 

但是現在,我想首先檢查用戶是否註冊,如果不是,則不返回值。 所以我figgerd是最好的出路是改變類SINGEL基調,並要求每一個類被調用時,如果用戶registerd像這樣:

+(id) getInstance { 

    static UpdateOrderServies *__sharedDataModel = nil; 
    static dispatch_once_t onceToken; 
    dispatch_once(&onceToken, ^{ 
     __sharedDataModel = [[UpdateOrderServies alloc]init]; 

    }); 

    if (![__sharedDataModel userIsRegisterd]) { 
     return nil; 
    } 

    return __sharedDataModel; 

} 

和它的作品,但是,好了,它不是一個非常好的答案,你可以看到..我想要更通用的東西。 我正在考慮使用颱風依賴注入,但沒有地方我可以檢查每個電話,如果用戶註冊... 任何想法更好的方式來處理這個問題?更多動態...

感謝

+2

爲什麼不在用戶首次「登錄」或以其他方式標識自己時,用一個封裝了所有授權的「能力」對象等等來使用它,而不是使用簡單的用戶標識來標識用戶,以及查詢該對象以測試用戶的能力。 –

+1

@HotLicks「爲什麼不在用戶登錄時識別用戶」。 。該步驟是身份驗證。接下來是定義調用給定服務所需的權限 - 這部分稱爲授權。我們可以將授權作爲每個服務調用的一部分,但這會破壞單一責任原則 - 因此推薦使用AOP。 –

+0

@JasperBlues - 將「責任」放在用戶的能力對象中。必須呈現該能力才能執行授權操作。這對我來說似乎是一個「單一責任」計劃。 –

回答

0

此基礎上你的問題,我覺得你不是在找依賴注入,但面向方面編程。 (Aspect Orientes Programming,AOP)旨在準確解決上述問題 - 這些問題貫穿系統中的許多模塊。示例:

  • 每次用戶與服務進行交互,應檢查安全性。
  • 所有交易應該有一個審計跟蹤
  • 每家商店interraction應導致Genius推薦

如果我們使用這些跨領域的要求正常的面向對象編程中,我們打破單一職責原則和一個應該幾乎涉及一個主題的類現在扮演着更多的角色,這會讓人感到困惑,重複和混亂。

AOP將這些橫切關注點模塊化,然後使用方法攔截確定應該應用這些橫切關注點的所有位置。 (在AOP中,我們稱之爲點切表達式)。

在Objective-c中,您可以使用ISA-swizzling,消息轉發或使用NSProxy來執行手動AOP--這些都是在運行時實現方法攔截的方法。或者,您可以使用Pete Steinberger和團隊的圖書館和一個名爲'Aspects'的圖書館。這個庫目前還沒有一個切點表達式語言,但仍然比使用ObjC運行時直接攔截方法簡單得多。

的授權方面將如何工作總結:

  • 在登錄時進行身份驗證,我們我們的用戶,使用用戶名/密碼挑戰,OAuth令牌或相似。驗證用戶後,我們現在可以授權服務調用。
  • 確定需要授權的每項服務以及所需的權限(您可以使用角色,功能等任何方案)。
  • 良好的面向對象的原則說,每個班級應該有一個單一的責任。所以你的服務客戶端應該都是關於調用遠程服務的。我們可以編輯服務客戶端來評估登錄用戶的權限並決定是否繼續。但是這將是混亂和重複的。相反,我們將在步驟2中使用這些信息(每項服務需要許可),並將該評估委託給我們的授權模塊。
  • 現在AOP步驟:對於每個服務調用,我們都會告訴我們的AOP庫攔截服務客戶端方法並首先調用授權模塊。

這樣你的交叉要求(授權客戶端調用)不會重複。現在您可以爲了簡單起見,決定讓每個服務調用調用授權模塊,但它仍然有助於瞭解AOP背後的理論和橫切關注點。

依賴注入/颱風

依賴注入並沒有真正直接關係到你的問題,但它肯定能幫助我們避免你的單身客戶的陷阱:

  • 創建一個明確的合同在你的類之間 - 增加代碼的凝聚力。
  • 確定應用程序中的關鍵'actors',並描述它們被組裝成整體的方式。可以將一名演員換成另一名演員來完成同樣的合同。
  • 簡化使用模擬和存根的單元測試。
  • 簡化集成測試 - 可以將一個參與者替換爲另一個參與者,以使系統進入所需狀態。例如,只修補一個授權模塊。