WPF“请稍候”使用后台工作人员的动画 - 这可能吗
最近，在我们开始使用后台工作程序从实体加载数据后，我们的 WPF/Entity Framework 4.0 应用程序变得不稳定。我们这样做是为了在 BG 工作人员从数据库检索数据时运行“请稍候”旋转图形，但我们开始随机遇到大量与 EF 相关的连接问题和其他无法解释的错误。 Microsoft EF 团队成员的帖子似乎表明 EF 不是“线程安全”的，一旦我们删除 BG 工作人员，问题确实就消失了。
这给我们留下了一个 UI 体验问题——在数据加载时，我们不再有一个用户友好的“请稍候”旋转器运行。有没有人对其他方法有什么建议，可以在不将数据负载放入 BG 工作人员的情况下完成此操作？
谢谢
Recently our WPF/Entity Framework 4.0 application has become unstable after we began using backgroundworkers in order to load data from the entity. We were doing so in order to have a 'Please Wait'-spinner graphic running while the BG worker retrieved data from the database, but we began experiencing numerous EF-related connection issues and other inexplicable errors at random times. A post from a Microsoft EF team member seemed to suggest that EF is not 'thread safe' and once we removed the BG workers the problems did indeed go away.
This leaves us with a UI-experience issue - we no longer have a nice user-friendly 'Please-Wait' spinner running while the data is loading. Does anyone out there have any suggestions as to other ways in which this can be done without placing the data-load into a BG worker?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以采取中间步骤。创建一个运行直到应用程序关闭的单个线程，而不是BackgroundWorker。该线程创建连接并处理所有数据库通信。向其发送消息，让它完成工作，然后接收结果。它将释放 UI，同时防止多个线程同时使用 EF。
You can take an in-between step. Instead of a BackgroundWorker, create a single thread that runs until your app closes. That thread creates your connections and handles all database communication. Post messages to it, have it do the work, then receive the results. It will free up the UI, while preventing multiple threads from using EF simultaneously.
我以前使用过BackgroundWorkers，它们实际上是为了在后台执行委托给它们的任务，引发与任务相关的事件，并在完成后死亡。最常见的示例是从后台线程更新进度条。 UI 元素只能从 UI 线程更新，因此出于这个原因，需要在 UI 线程上引发事件的 BackgroundWorkers。
让BackgroundWorker 做一些需要持久性的事情，比如通过数据库连接进行的操作，似乎纯粹因为它们的瞬态性质而引起麻烦。
I've used BackgroundWorkers before and they're really meant for doing the task delegated to them in the background, raising events related to the task, and dying when finished. A most common example would be updating a progress bar from a background thread. UI elements can only be updated from the UI thread so BackgroundWorkers that raise events on the UI thread are desireable for this reason.
Having a BackgroundWorker do something that needs persistence, like operations over a database connection, seems like it would cause trouble purely because of their transient nature.