要财产，还是不要财产？
我试图找出什么会给我最好的代码。我意识到这当然有点主观。
我有一个访问数据库的应用程序，我为其编写了一个程序集，该程序集向使用该程序集的所有应用程序隐藏了有关该数据库的详细信息。
我还有一个 WPF 应用程序，它利用该程序集来显示我想在其中使用数据绑定的各种成本计算。
数据绑定只能用于对象的属性（就我开始工作而言）。这意味着我需要一个对象，最好具有 INotify 支持和一系列对象。但是，我更愿意将 INotify 和 WPF 事物保留在处理数据库访问的程序集之外。
其他人如何解决这个问题：将 WPF 事物保留在数据库层（例如 INotify）之外并在 WPF 内部允许绑定？写一个包装？或者大多数人是否将“property”/“INotify”类作为数据传输对象直接放入数据库层？
I am trying to figure out what would give me the nicest code. Which is a little subjective of course, I realize.
I have an application that accesses a database for which I have written an assembly that hides details about this database from all the applications that make use of this assembly.
I also have an WPF application that makes use of this assembly to display various cost calculations in which I would like to use databinding.
Databinding is only possible to properties of objects (as far as I got to work). This would mean I would need an object, preferably with INotify support and a range of objects. However, I would prefer to keep INotify and WPF things outside the assembly that handles database access.
How do others solve this: Keep WPF things outside the database layer (such as INotify) and inside your WPF allow binding? Write a wrapper? Or do most people put a 'property'/'INotify' class as data transfer object directly into the database layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
其他人通过实施 MVVM 设计模式来解决此问题。
Other people solve this by implementing the MVVM design pattern.
你正在错误的观念下工作。
INotifyPropertyChanged不是 WPF 的东西。考虑：System.dll的一部分System.ComponentModel命名空间中既然 Microsoft 生产的所有自动生成的数据层都实现了 INotifyPropertyChanged，为什么您要以不同的方式对待您的数据层呢？显然，当属性发生变化时，您的数据层需要以某种方式通知其客户端。为什么不使用.NET Framework的内置机制呢？
在我看来，任何包含可变对象的数据层都应该理所当然地实现属性更改通知。
INotifyPropertyChanged被设计成这样的通知机制，那么为什么不按其预期使用它呢？更一般地说：添加额外的包装层通常只是低效的代码膨胀。有时这是必要的，甚至是有益的，但不要只是为了做而做。很多时候，合理设计的数据层对象与视图模型配合得很好。只有当您的视图模型与数据层不同或您需要额外的功能时，您才应该考虑引入额外的复杂性，并且只能根据具体情况而定。
You are laboring under a misconception.
INotifyPropertyChangedis not a WPF thing. Consider:System.dllSystem.ComponentModelnamespaceDataRowViewand ComponentModel'sObservableCollection.Since all the automatically-generated data layers Microsoft produces implement
INotifyPropertyChanged, why should you treat your data layer any differently? Obviously your data layer needs to notify its clients somehow when properties change. Why not use NET Framework's built-in mechanism?In my opinion any data layer containing mutable objects should implement property change notifications as a matter of course.
INotifyPropertyChangedwas designed to be such a notification mechanism, so why not use it as it was intended?On a more general note: Adding an extra wrapper layer is generally just inefficient code bloat. Sometimes it is necessary and even beneficial, but don't do it just for the sake of doing it. Many times reasonably designed data layer objects work very well as view models. Only where your view model diverges from your data layer or where you need additional functionality should you consider introducing extra complexity, and then only on a case-by-case basis.
我认为最干净的解决方案是在 WPF 程序集中编写一个包装器对象，并将
INotify类型保留在数据库程序集中。没有理由将 INotify 的复杂性添加到数据库层，除非它提供了特定的优势。I think the cleanest solution is to write a wrapper object in your WPF assembly and keep the
INotifytypes out of the database assembly. There is no reason to add the complication ofINotifyto the database layer unless it provides a specific advantage.写一个包装器。如果包装非常简单，您甚至可以构建一个生成器来根据源 DTO 生成所有类
Write a wrapper. If the wrapping is pretty straight-forward you could even build a generator to generate all classes based on the source DTO's
您可以查看 PostSharp，这正是面向方面编程 (AOP) 的用途。有很多将 INotify* 编织到模型类中的示例。我还没有开始在实际项目中使用 PostSharp，但在我们尝试过的一些测试场景中它看起来很有希望。
You might look into PostSharp, this is just the kind of thing Aspect Oriented Programming (AOP) is for. There are a lot of examples weaving INotify* into model classes. I haven't started using PostSharp on a real project yet but it's looked promising in some test scenarios we've tried it on.
还有一件事需要注意，这很有用 - 如果您知道要绑定的属性是不可变的（即单例对象或将初始化一次且从未触及的对象），则您不会需要使其成为 INotifyPropertyChanged - 一个简单的属性就可以正常工作。
One more thing to note that's useful - if you know that the property you're binding to is immutable (i.e. a singleton object or something that'll be initialized once and never touched), you don't need to make it INotifyPropertyChanged - a simple property will work fine.