我應該讓業務對象與WPF中的用戶界面分開嗎？

Question

WPF的處理視圖模型的方式使得在UI中使用業務對象變得非常誘人。你有沒有看到這個問題？爲什麼或爲什麼不這樣做？

Answer 1

微軟產品團隊的指導（例如Blend團隊正在使用的）是Model-View-ViewModel架構，這是流行的MVC模式的變種。一個好的起點是http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx。 WPF博士在這個話題上也有很好的文章。

基本上，他們主張創建一個ViewModel層，該層使用綁定友好的業務對象，如ObservableCollection等。另外，如果您最終可能遷移到Silverlight 2，那麼您可能希望將業務對象保留在UI層之外，以便您可以更換UI技術（直到WPF和Silverlight與源代碼兼容）。

Answer 2

不是一個WPF大師，我不能確定，但​​分離你的M，V和C的通常原因是你可以獨立於視圖測試控制器，反之亦然。

當然，沒有任何事情會阻止你，但是如果它是分開的，它應該有更多的可測試性（即單元測試）。 MVP模式，通常是MS推廣的模式，更多地圍繞主持人（即您的WPF表單），具有更多的控制權，而且這也很好......

Answer 3

我想我看到它在不同的光。我嘗試儘可能地避免使用UI，因此我可以使用任何需要的UI呈現（即web，WPF，WinForms）。表示層中的業務邏輯越多，如果您遷移到不同的用戶界面，則以後可能需要重寫的內容越多。

Answer 4

只要你正在做的事情是查看他們這不是在UI中的業務對象的問題。換句話說，如果你想改變一個屬性，或者刪除一個屬性，或者創建一個新屬性，你應該發送一條消息給控制器，主持人或者其他任何要做的事情;然後應該在視圖中更新結果。

什麼你不應該做的是使用你的對象（或你的對象的任何其他方法或屬性）的ToString方法來影響他們會如何出現在視圖中。您應該使用DataTemplate s來表示您的對象的視圖。如果您需要更復雜的表示形式，則可以使用IValueConverter將對象更改爲其可視表示形式。

Answer 5

根據您的應用程序體系結構或您計劃重新使用組件和對象的方式，您可以從用戶界面（本例中爲WPF）中選擇一定程度的獨立性。

這裏是我的經驗樣本：

我曾與WPF只是一點點工作，在 一個相對較小的項目，其中已經定義了 業務層， ，我們只需要創建一個用戶界面。當然，接口 已定義它自己的規則和對象 ，它正在與工作，而且由於 應用大部分是通過擴展 DependencyObject（主要用於定義只是我們選擇創建自己的 特定對象， UX Data Binding目的）。

有些人可能會說，這是不正常 使用依賴對象，因爲它們 不是可序列化（實際上他們 是 - 對XAML），他們帶來了 依賴於WPF（在 System.Windows命名空間），以及一些 其他論點。此外， DependencyObjects支持其他 選項，如attached properties 和dependency properties。其他 可能喜歡使用例如 INotifyPropertyChanged如果它 是有意義的，而其他人可能會說 所有這些模式不屬於 其他層比UI。 （如果您想了解更多有 一些很好的WPF data binding articles在MSDN庫， 包括 性能比較和用戶界面的最佳實踐）

這是一種糟糕的是微軟選擇添加一些的例如System.Windows命名空間的好處，而不是像System.ComponentModel那樣，在我看來它們可能更有用（通過提供所有這些重要模式不僅適用於WPF，還適用於.NET框架）。

當然這只是一個開始，我們中的許多人都知道，事情將最終演變到正確的方向。 （具有脫離主題的風險：以Silverlight 2.0框架爲例，這是一個匆忙釋放，WPF模型中的一些對象丟失，有些不在其自然位置。）

在最終，一切都取決於你，你的編程風格，你的架構決定和你對這項技術的瞭解。

如果用某種方式做這件事比看書更自然，那麼在做出任何決定之前，請考慮why you should和why should you not！