财产,还是财产?

Jaa*_*jan 5 c# dns wpf

我想弄清楚什么会给我最好的代码.我意识到,这当然有点主观.

我有一个访问数据库的应用程序,我已经编写了一个程序集,该程序集从使用此程序集的所有应用程序中隐藏有关此数据库的详细信息.

我还有一个WPF应用程序,它使用这个程序集来显示我想使用数据绑定的各种成本计算.

数据绑定只能用于对象的属性(就我工作而言).这意味着我需要一个对象,最好是INotify支持和一系列对象.但是,我更喜欢在处理数据库访问的程序集之外保留INotify和WPF.

其他人如何解决这个问题:将WPF内容保存在数据库层之外(例如INotify)和WPF内部允许绑定?写一个包装?或者大多数人将"属性"/"INotify"类作为数据传输对象直接放入数据库层?

Kla*_*sen 7

其他人通过实现MVVM设计模式来解决这个问题.


Ray*_*rns 3

你正在错误的观念下工作。 INotifyPropertyChanged不是WPF东西。考虑:

  1. 它是一部分System.dll
  2. 它在System.ComponentModel命名空间中
  3. 自 2.0 版本以来,它已成为 NET Framework 的一部分
  4. 大多数现成的 NET Framework 数据对象都支持它,包括 ADO.NETDataRowView和 ComponentModel 的ObservableCollection.
  5. WinForms、ASP.NET、WPF 和许多第三方包自动使用它来与数据对象进行交互。

既然微软生产的所有自动生成的数据层都实现了INotifyPropertyChanged,为什么你要以不同的方式对待你的数据层呢?显然,当属性发生变化时,您的数据层需要以某种方式通知其客户端。为什么不使用.NET Framework的内置机制呢?

在我看来,任何包含可变对象的数据层都应该理所当然地实现属性更改通知INotifyPropertyChanged被设计成这样的通知机制,那么为什么不按预期使用它呢?

更一般地说:添加额外的包装层通常只是低效的代码膨胀。有时这是必要的,甚至是有益的,但不要只是为了做而做。很多时候,合理设计的数据层对象与视图模型配合得很好。只有当您的视图模型与数据层不同或您需要额外的功能时,您才应该考虑引入额外的复杂性,并且只能根据具体情况而定。