EF 如何在 WPF/Silverlight 应用程序中工作？
一段时间以来，我一直在尝试同时思考 2 个概念，学习 MVVM（其中一件困难的事情就是试图弄清楚要使用哪个框架。我们甚至不知道有多少个框架，直到几周前），我也在尝试学习 Entity Framework 4.2。
这是我们要编写的 WPF 应用程序。
我已经拿到了 Julia Lerman 的书，并且正在参加 EF 的在线培训课程，但有一件事我仍然不明白，也没有看到任何示例，那就是如何处理 INotifyPropertyChanged 接口之类的东西对于通过 EF 创建的类，无论我们是否使用 MVVM，使用 INotifyPropertyChanged 都是至关重要的。
那么，让我在这里问一个简单的问题：
您是否允许 EF 创建反映数据库中所有数据的所有数据访问类，然后复制大部分代码，以便我可以让它与 INotifyPropertyChanged 一起使用？或者还有其他方法可以做到这一点吗？
I've been trying for a while to wrap my mind around 2 concepts at once, learning MVVM (and one of the hard things has been trying to figure out which framework to use. We didn't even know how many there were until a few weeks ago) and also I'm trying to learn Entity Framework 4.2.
This is for a WPF app that we're going to be writing.
I've gotten Julia Lerman's book and I'm also going through an online training course on EF, but one thing I still don't get, and haven't seen any example of yet, is how to handle something like the INotifyPropertyChanged interface with the classes created via EF, regardless of whether we use MVVM or not, working with INotifyPropertyChanged is vital.
So, let me ask here the plain question:
Do you allow EF to create all of the data access classes that reflect all of the data in your database, and then duplicate much of that code so I can get it to work with INotifyPropertyChanged? Or is there some other way of doing that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当我想到必须将每个数据对象映射到一个新的数据对象（仅在其之上实现 INPC）时，我感到很困惑。
然后我发现了一个技巧：假设您要使用 WCF，它会自动实现 INPC。
对于集合，只需进入服务引用配置，并进行设置，以便它为您提供 ObservableCollection 作为默认集合类型。
就这样，您就可以使用 MVVM =)
I was baffled when the thought came to me, that I'd have to map every data object to a new one only implementing INPC on top of it.
Then I found a trick: assuming you're going to use WCF, it automatically implements INPC.
For the collections, just go into the Service Reference configuration, and set it so that it gives you ObservableCollection as default collection type.
That's it, you're set for MVVM =)
由于
ViewModel是根据View的需求创建的，因此仅在非常简单的情况下才会使用ViewModel和您的Entity 是同一个类。通常您有一个
Entity类和一个ViewModel类。INotifyPropertyChanged只是其中的原因之一。还有其他一些，例如转换、验证、有意义的错误消息、聚合等。Because the
ViewModelis created with the needs of theViewin mind, only in very simply cases theViewModeland yourEntityare the same class. Normally you have anEntityclass and aViewModelclass.INotifyPropertyChangedis only one of the reasons for this. There are others like conversions, validation, meaningful error messages, aggregation etc.我之前在几个 WPF 应用程序中使用过实体框架。第一次使用EF数据库。要完全按照我想要的方式获得模型是相当棘手的，一旦它开始工作，我就必须在我的实体类上完成并实现 INotifyPropertyChanged。
最近，我开始使用 EntityFramework CodeFirst 4.1，我发现处理所有属性更改的内容要容易得多。我通常创建一个基类，并在其上实现 INotifyPropertyChanged 并从中继承我的实体。
至于 ViewModel，我也开始担心这个框架或那个框架。后来我决定自己推出。当然，这些框架有一些有趣的功能，但对于学习来说，我发现通过创建自己的 ViewModelBase 类并从中继承我的所有 ViewModel 来进入它要容易得多。
ViewModelBase 通常实现 INotifyPropertyChanged。后来我创建了一个 ViewModel 监视器类，其中包含 ViewModel 的集合。为了查找它们，我给了 ViewModelBase 一个FriendlyName属性，这样继承的ViewModel的每种类型都可以为其设置一个名称（我的类型通常是RecordMaintenanceViewModel、NavigationViewModel、ShellViewModel等），并且我通常会继承我使用的特定于视图的ViewModel那些。因此，在我的运输程序中的ShipmentView上，ShipmentViewModel是从CollectionViewModel继承的，而CollectionViewModel是从ViewModelBase继承的。通过这种方式，我将功能划分为多个独立的部分，使我能够处理特定的场景。
我通常将我的 ViewModel 基础移植到每个项目，并且经常采用我的中间 ViewModel；有时我必须重新创建它们。
I have previously used Entity Framework in several of my WPF applications. The first time I used EF Database first. It was pretty tricky to get the model exactly the way I wanted it, and once it was working, then I had to go through and implement INotifyPropertyChanged on my entity classes.
Recently, I have started using EntityFramework CodeFirst with 4.1, I have found it is much much easier to handle all of the property changed stuff. I generally create a base class with INotifyPropertyChanged implemented on it and inherit my entities from that.
As far as the ViewModel, I also started out worrying about this framework or that framework. Later I decided to just roll my own. Sure, the frameworks have some interesting capabilities, but for learning, I found it much easier to get into it by creating my own ViewModelBase class and inheriting all of my ViewModels from that.
ViewModelBase typically implements INotifyPropertyChanged. Later I created a ViewModel monitor class which would have a collection of ViewModels. To look them up, I gave ViewModelBase a FriendlyName property so that each type of inherited ViewModel could have a name set for it (my types are typically RecordMaintenanceViewModel, NavigationViewModel, ShellViewModel, etc) and I generally will inherit my used view-specific ViewModels from those. So on the ShipmentView in my shipping program, The ShipmentViewModel is inherited from a CollectionViewModel, which is inherited from the ViewModelBase. In this way I have functionality divided up into discreet sections allowing me to handle specific scenarios.
I generally port my ViewModel base over to every project, and often take my middle ViewModels; sometimes I have to recreate them though.