将导航属性与实体框架绑定
我还有一个关于使用 C# 和实体框架进行绑定的问题。
在这里，我希望将导航属性绑定到列表框或列表视图。
我在不同的帖子中看到，如果我使用列表后面的代码更新集合，则不会收到通知，因为集合不处理通知（无论如何，它总是相同的问题）。
例如，人们建议使用 ObservableCollection ，但是，这是我的问题，这基本上是重复集合，因此，如果我修改它，我必须在代码隐藏中处理事实上，更改也必须应用于“原始”导航属性，对吗？
如果是这样，我在想：为什么不在分部类中创建一个名为 MyObservableNavigationProperty 的自定义属性。然后，我只能与该集合交互，在集合更改时捕获事件并将更改应用到“原始”集合。这是一个很好的方法吗？或者我在这里感到很困惑......
I have another question about binding using C# and the entity framework.
Here, I'm looking to bind a navigation property to a listbox or a listview.
I saw on different posts that if I update the collection using code behind the list would not be notified because the collection does not handle notification (it's always the same problem anyway).
People suggested to use an ObservableCollection for example, but, and here is my question, this comes down to basically duplicate the collection and hence, if I modify it, I'd have to handle in code-behind the fact that the change has also to be applied to the "original" navigation property right?
If that's the case, I was thinking: why not create a custom property called, say, MyObservableNavigationProperty in a partial class. I could then interact only with this collection, catch the event when the collection is changed and apply the change to the "original" collection. Is that a nice way to do the trick? or am I getting all confused here....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常手动编码我的实体。它提供的灵活性通常比使用设计器生成某些属性所节省的时间更有用，特别是因为 EF4 可以 生成代理来执行重要的跟踪/延迟加载位。
也就是说，如果您没有该选项，您可以尝试使用 ADO.NET如果可能的话，自我跟踪实体生成器模板来生成您的实体。它生成的集合继承自
ObservableCollection。如果这是不可能的，那么我认为你的部分类解决方案是可行的方法。
I usually code my entities by hand. The flexability it provides is generally more useful than the time saved using the designer to generate some properties, especially since EF4 can generate proxies to do the important tracking/lazy loading bits.
That said, if you don't have that option you could try using the ADO.NET Self-Tracking Entity Generator Template to generate your entities if possible. The collection's it generates inherit from
ObservableCollection<T>.If that isn't possible, then I think your partial class solution is the way to go.