MVP - 應該能夠直接調用演示者方法，還是應該始終提高事件？

我一直在使用ASP.NET的MVP模式。我堅持從視圖中提出主持人事件的定義模式。MVP - 應該能夠直接調用演示者方法，還是應該始終提高事件？

它讓我感到震驚，我可以在演示者中暴露視圖可以直接調用的方法。

從技術上講，使用直接方法調用將需要更少的代碼。另一個好處是我傾向於在提供類似功能的多個視圖中分享演示者。這意味着有時候某些事件處理程序被迫在視圖中註冊，只是爲了遵守共享的演示者界面，但在那個特定視圖中根本不使用。

一個這樣的例子是日記視圖，在一個視圖中允許您取消約會，而在另一個視圖中則不會。其餘的主持人事件用於加載數據，並保存預約用於兩者。我不想寫兩個幾乎提供相同功能的獨立演示者。

我想聽聽別人認爲誰在積極使用MVP。是否有任何理由可以想到爲什麼從視圖直接調用方法的主持人在MVP中不好？

來源

2010-02-04 Junto

我使用直接方法調用，並沒有看到任何worhtwhile理由定義事件發言人。您使用的事件稱爲「相信演示者」風格。它確實提供View Presenter的完全解耦，但增加了複雜性。

來源

2010-02-05 16:12:20 epitka

所以，如果我理解你是對的，你說這個模式有幾種口味，你可以根據你的喜好混合搭配這些口味。我真正有興趣知道的是，爲什麼通過事件完成解耦可能被認爲是更好的選擇。這是出於可測性的原因嗎？方法調用感覺像一個需求，事件，一個請求。我對我正在使用的模式感到滿意，但有時我認爲重新評估這些架構決策是一件好事！ – Junto 2010-02-07 21:52:55

實際上，您使用的模式可能會使測試複雜化，但是您已將演示者的視圖完全解耦。是的，有多種口味，主要口味稱爲被動視圖和監督控制器。 – epitka 2010-02-08 03:21:26

你能否回答http://stackoverflow.com/questions/8851933/event-bubbling-and-mvp-asp-net？ – Lijo 2012-01-16 06:15:13

如果您的視圖直接調用演示者，那麼它將像mvc中那樣緊密耦合。我不明白爲什麼一些框架採取這種方法而不是提出這個觀點的事件。

來源

2010-09-14 04:09:49 Ant

我們可以編寫一個接口，其中包含我們想要從視圖調用的所有方法。演示者將實現這個接口。然後我們可以傳遞這個接口的實例來查看，並且查看可以在這個接口上調用方法。這將減少兩者之間的耦合。

來源

2012-01-20 05:49:24

MVP - 應該能夠直接調用演示者方法，還是應該始終提高事件？

回答

相關問題