在軟件體系結構中應在哪里實現INotifyPropertyChanged接口？

Question

我目前正在創建一個項目，該項目的規模足以將其體系結構中的知名層仔細分離。

對於數據訪問層（DAL），我僅使用.NET實體框架。

對於業務層，我定義了業務對象，隨后的開發人員可以使用這些業務對象，他們可以使用它們創建客戶端並處理UI。

由於我還必須開發一個客戶端應用程序以進行演示，因此我意識到使用ObservableCollection<T>而不是列表可能會非常有幫助，並且對象應盡可能多地實現INotifyPropertyChanged接口，以便UI自動檢測更改並立即顯示更新。

但是，我想知道從架構的角度來看這是否真的是正確的方法。 也就是說，從技術上講 ，我認為業務層不應該與UI顯示有關，因為我們並不真正“知道”程序員可能將其用於什么； 例如，他可能只想將這些對象用於計算目的。 因此，我想知道什么是慣例？

我應該在業務層中實現這些功能嗎（不會有性能問題）？ 我是否應該在包含所有這些功能的另一層中創建某種“裝飾器”對象？

Answer 1

正如Skliwz在評論中提到的那樣 ，正確的放置位置是在專門綁定到UI層的對象中。

如果您將業務對象直接綁定到UI層，並且發現INotifyPropertyChanged接口實際上並不屬於您的業務對象，那么這清楚地表明您應該出於不同目的使用不同的對象

例如，您可能希望使用“ 模型視圖”視圖模型模式創建視圖模型 。

但是，如果發現您的業務對象將由其他系統監視，並且需要通知它們何時更改，則INotifyPropertyChanged接口是合適的。 但是，在您的特定情況下，聽起來並非如此。