對於MVP設計中的View接口，IView成員應該如何抽象？

Question

我還在學習MVP。我有一個IView和一個主持人。我有一個自定義列表控件，我已經爲這個應用程序編寫。我想添加一些項目，一次一個。我應該公開IView.AddItem（Item）還是應該公開IView.MyCustomList屬性？

這是一個風格的問題，或者是否有正確回答這個問題？

Answer 1

是的，這完全是一個風格問題，無論你覺得更舒適。

Answer 2

通過不公開您的CustomList，您可以更好地控制如何將項目添加到您的CustomList中。 暴露AddItem方法將更好地保護您的列表免受可能的濫用。

您可以選擇，這取決於您希望在列表中保留多少控制。

Answer 3

我個人認爲好的風格會保留MVP模式的目的並保持代碼清潔。

如果我理解正確，您的CustomList屬性將具有您的自定義控件的類型。通過視圖接口公開這樣的屬性將導致所有與該接口一起工作的代碼（演示者）依賴於您的控件（並將其作爲依賴項引用）。這是可能的，並且可能適用於您的要求，但是違反了MVP設計模式。您可能想要將視圖實現和演示者分離到不同的程序集中。但兩者都必須參考你的控制。 MVP旨在將用戶界面特定的交互和特定的控制功能（在大多數情況下依賴框架/供應商）分開，並將其從業務邏輯（演示者）中隱藏起來。

在您的場景中，我建議將AddItem方法暴露給演示者 - 視圖實現負責處理用戶控件或與顯示數據相關的任何事宜。另一方面，演示者將專注於檢索數據並執行一些業務邏輯。我猜你不需要同時支持不同的用戶界面技術（如ASP.NET Web窗體，WPF/Silverligth或ASP.NET MVC），但是如果你假設必須移植一個ASP.NET MVC網站到一個destktop WPF應用程序，並堅持到MVP設計模式，那麼你會（在最好的情況下）必須在每個UI技術中實現視圖接口，爲演示者，服務和所有業務邏輯的東西保持相同的代碼庫（實際上，從ASP.NET MVC到桌面將是一件很冒險的事情，但這個例子應該強調，演示者和業務邏輯不需要修改）。

---

PS。 Java中的某些框架具有表示UI組件的抽象接口（UI模型），並且可以在不同的UI技術中重用。在這種情況下，通過它的UI模型接口（它必須實現）公開一個UI組件是可以接受的。