2010-01-25 114 views
5

我想弄清楚什麼會給我最好的代碼。當然,我認爲這有點主觀。要財產,還是不要財產?

我有一個應用程序訪問我已經編寫了一個程序集的數據庫,該程序集隱藏了使用此程序集的所有應用程序中關於此數據庫的詳細信息。

我也有一個WPF應用程序,利用這個程序集來顯示我想要使用數據綁定的各種成本計算。

數據綁定只可能對象的屬性(據我開始工作)。這將意味着我需要一個對象,最好使用INotify支持和一系列對象。不過,我寧願將INotify和WPF事物保存在處理數據庫訪問的程序集之外。

其他人如何解決這個問題:將WPF事情保存在數據庫層之外(如INotify)並且在WPF中允許綁定?寫一個包裝?或者大多數人將'property'/'INotify'類作爲數據傳輸對象直接放入數據庫層?

回答

3

你是一個誤解下勞動。 INotifyPropertyChanged不是是一個WPF的東西。試想一下:

  1. 這是System.dll
  2. 它是System.ComponentModel命名空間部分
  3. 自版本它在.NET框架一直是部分2.0
  4. 這是大多數NET Framework數據對象進行的支持該框包括ADO.NET的DataRowView和ComponentModel的ObservableCollection
  5. 它automaticaly使用的WinForms,ASP.NET,WPF,和許多第三方包與數據對象的接口。

由於所有自動生成的數據層微軟生產的工具INotifyPropertyChanged,爲什麼你應該對待你的數據層有什麼不同呢?顯然你的數據層需要在屬性改變時以某種方式通知它的客戶。爲什麼不使用.NET Framework的內置機制?

在我看來任何包含可變對象的數據層都應該實現屬性更改通知,理所當然INotifyPropertyChanged被設計成這樣的通知機制,爲什麼不按照它的意圖使用它?

更爲一般的說明:添加額外的包裝層通常只是低效率的代碼膨脹。有時這是必要的,甚至是有益的,但不要僅僅爲了這樣做而做。作爲視圖模型,很多時候合理設計的數據層對象都可以很好地工作。只有在視圖模型與數據層分離的地方或者需要額外功能的地方,您應該考慮引入額外的複雜性,然後才根據具體情況進行處理。

1

我認爲最簡潔的解決方案是在您的WPF程序集中編寫一個包裝對象,並將INotify類型保留在數據庫程序集之外。沒有理由將INotify的複雜性添加到數據庫層,除非它提供了特定的優勢。

7

其他人通過實施MVVM設計模式解決此問題。

0

寫的包裝。如果包裝非常直接,你甚至可以建立一個發生器來生成所有基於源DTO的類

0

你可以看看PostSharp,這只是面向方面編程(AOP)的一種東西。有很多examples將INotify *編織成模型類。我還沒有開始在一個真正的項目上使用PostSharp,但在我們嘗試過的一些測試場景中,它看起來很有前景。

0

還有一點要注意,是非常有用的 - 如果你知道你要綁定的屬性是不變的(即一個單獨的對象或東西,會被初始化一次並沒有碰過),你需要使它INotifyPropertyChanged - 一個簡單的屬性將正常工作。