2010-09-10 25 views
0

考慮一種表單從服務中獲取其數據並使用MVP模式實現的情況。我是否需要在單獨的課程中隔離服務訪問權限,還是可以將其保留在Model類本身中。在我的特殊情況下,模型類只能作爲傳遞給最終調用服務的數據訪問類的傳遞。數據訪問類具有用於服務回調和在特定時間間隔內查詢服務以進行任何更新的邏輯。使用單獨的類連接到服務時使用MVP表單

我在問這個,因爲我想保持我的代碼結構儘可能簡單,並且只在需要的時候使用額外的類。但我也不想簡化它,以至於將來的維護/擴展會變得非常困難。

回答

1

簡單的代碼結構(意味着少量的類)並不一定意味着易於維護(see Ayende's recent post on this)。我的建議是遵守單一責任原則(SRP)。模型在MVP中的職責是將數據封裝到視圖但是在您的情況下它承擔另一項責任:從服務中獲取數據。除此之外,我還看到另外兩個問題:

  1. 如果對服務的調用失敗會發生什麼?那麼你將被迫在視圖的代碼中處理這個問題。
  2. 主持人對你的情況有什麼責任?

在我看來,你的架構不是真正的MVP(但沒有看到代碼,我可能是錯的)。

此外,MVP模式的實際實施取決於您使用的GUI技術。我的一般建議:

  • 堅持Passive View模式。
  • 保持模型愚蠢。我通常使用簡單的POCO/POJO類,沒有回調。我在WinForms中使用C#視圖事件來通知演示者任何UI事件。
  • 使模型易於查看:模型通常應該根據視圖的需要來實現,以便將視圖代碼保持在最低限度。
  • 演示者是國王。保持演示者(和其他服務/存儲庫)中的所有業務邏輯。

UPDATE:回答您的評論:

  • 是的,你應該將數據存儲在您的模型。
  • 如果我理解正確,您將在模型中公開事件/回調來處理異常。然後讓視圖獲取數據,並且在服務調用失敗的情況下,演示者通過(再次)調用視圖來讓用戶知道服務失敗。我看到幾個問題,這種方法:

    1. 當服務出現異常時,可創造令人費解的執行路徑:主持人 - >查看 - >模型 - >演示 - >視圖。這對於調試和單元測試可能非常棘手。
    2. 您如何知道其中當異常發生時,視圖(用填充視圖和模型數據的方式)?

我通常的做法,是由主持人做所有的獲取和異常處理以前視圖獲取其手中的模型數據。這樣我就不需要模型中的任何回調,因爲我可以在演示器中用簡單的try-catch塊來處理異常。該模型僅僅成爲靜態數據的持有者,而不是後端服務的入口。

+0

我正在使用被動視圖模式。演示者創建並處理視圖和模型。業務邏輯(過濾,搜索和導出數據)在主講人中。該模型的責任是獲取數據並將其轉換爲視圖消耗的綁定列表(通過演示者)。但數據需要存儲在某個地方。我是否將其存儲在模型中?另外,我認爲如果服務失敗,模型會返回一個信息,然後通知用戶「服務不可用」。我仍然不明白爲什麼模特不會直接訪問servuce – EndlessSpace 2010-09-10 19:31:49

+0

如果您覺得您的方法適合您,請繼續使用它。我根據您的評論更新了我的答案。 – 2010-09-11 03:43:56

+1

我想我已經明白你在這裏想告訴我什麼。我將根據您的輸入更改我的mvp課程。視圖只會由演示者更新。模型存儲所有數據。演示者管理從模型中獲取數據,更新視圖並響應視圖中的事件。希望這會讓我的代碼更容易被任何第三人理解。感謝您的輸入。 – EndlessSpace 2010-09-13 15:54:47

1

演示者可以使用將與Web服務進行通信的存儲庫。

public class SomePresenter 
{ 
    private readonly ISomeView _view; 
    private readonly ISomeRepository _repository; 

    public class SomePresenter(ISomeView view, ISomeRepository repository) 
    { 
     _view = view; 
     _repository = repository; 
    } 

    public void Foo() 
    { 
     var model = _repository.GetModel(); 
     // TODO: work with the model and update the view 
    } 
} 

當實例化演示者時,您會傳遞一個真正的存儲庫實現,它將與Web服務進行通信。

0

這樣的類通常稱爲服務代理。 Service Agent用於服務和客戶端之間的鬆散耦合以及用於支持一些中間邏輯。根據你的描述你的數據訪問類已經是一個服務代理。