后台工作者 C# winform
从后台工作者加载所有内容是一个坏主意吗？ 当前代码在 Form_load 上执行。我们正在从网络服务中提取大量数据。一些长时间运行的工作在后台工作人员中。
无论代码有多大或多小，从后台工作人员加载所有内容是一个坏主意吗？ 每个函数都在后台工作程序中运行？ 或者这会让这段代码变得混乱并且陷入噩梦。
谢谢。
is it a bad idea to load everything in from the background worker??
Current code is Executed on Form_load. we are pulling a lot of data from webservice. some long running works are in background worker.
would it be a bad idea to load everything from background worker no matter how small or big the code is??
every function to run in background worker?
or is this going to make this code messy and treading nightmare.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
代码的大小不是您应该用来确定是否在单独的线程上执行工作的指标。最坏情况下的执行时间是。
首先，真正需要在 Form_Load 上进行大量工作的 UI 设计并不多。如果可能的话，我通常会：
无论完成多少工作，您的用户都会希望/期望您的表单非常快速且响应迅速。在 Form_Load 期间执行可能长时间运行的操作总是会导致糟糕的用户体验。
BackgroundWorker 只是异步执行工作的一种机制，还有许多其他机制。您应该选择最适合每种情况的一种。
The size of the code is not a metric you should use to determine whether to perform work on a separate thread. Worst case length of execution is.
First, there aren't many UI designs where firing off a bunch of work on Form_Load is really desirable. If it's possible, I typically either:
Your users will want/expect your forms to be extremely fast and responsive regardless of how much work is being done. Executing potentially long-running operations during Form_Load is always going to result in a bad user experience.
BackgroundWorker is only one mechanism for performing work asynchronously, there are many others. You should choose the one that is most appropriate for each situation.
BackgroundWorker通常用于使 Winforms UI 更具响应性。您可以将它用于 Web 应用程序中的后台处理，但我不这样做；我在 Windows 服务中使用ThreadPool。BackgroundWorkeris normally used to make a Winforms UI more responsive. You can use it for background processing in a web application, but I don't; I use aThreadPoolin a Windows Service.将可能长时间运行的代码粘贴到后台工作程序中是很好的做法，以便您的应用程序保持响应能力，但没有必要将所有内容都作为后台工作程序。
如果您的代码调用 Web 服务（或任何可能超时的外部系统），或者执行可能需要超过几秒的操作，那么这将是放入后台工作程序的良好候选者，但是如果任何事情始终需要不到一秒钟左右的时间来执行，我可能不会打扰。
Its good to stick potentailly long-running code into a background worker so that your application remains responsive, but there is no need to put everything as a background worker.
If your code calls a web service (or any sort of external system that might time out), or does something that it likely to take longer than a few seconds, then that would be a good candidate for putting into a background worker, however if anything consistently takes less than a second or so to execute I proabably wouldn't bother.
后台工作人员将花费额外的时间来创建和销毁后台工作人员的线程。如果它是一小段代码（处理方面），那么使用主 UI 线程可能会更快。
如果可维护性是关键，也许使用后台工作人员进行处理可能是解决方案。自动处理细节的自定义框架可能会使代码更易于维护。
这取决于几个因素：
A Background Worker will take extra time to create and destroy the thread for the background worker. If it is a small piece of code (processing-wise) it may be faster to use the main UI thread.
If maintainability is the key, perhaps using Background workers for processing may be the solution. A custom framework of sorts that automatically dealt with the detail may make the code even more maintainable.
It depends on several factors:
这是否是一个好主意很大程度上取决于您问题的具体情况。您是否必须在一次调用中提取所有数据，还是可以以独立的块的形式提取数据？
如果它是一个长时间运行的大型 Web 服务调用，那么将其放在线程上不会为您做任何事情。最好的情况是几个独立的、长时间运行的块，它们返回的时间大约相同。
另外，在 Webforms 中（因为您提到了 Page_Load）IIRC，您将与 ASP.NET 共享线程池，并且您可能会导致您的应用程序在并发请求/用户的某个阈值下整体响应速度降低。
Whether it is a good idea or not depends very much on the specifics of your problem. Do you have to pull all the data in one call or can you do it in independent chunks?
If it is one big long running web service call, then putting it on a thread won't do anything for you. Your best case would be several independent, long running chunks that take approximately the same amount of time to return.
Also, in webforms (since you mention Page_Load) IIRC you will be sharing the thread pool with asp.net, and you may cause your app to become less responsive overall at some threshold of concurrent requests/users.
就我个人而言，我不会将代码放入工作线程中，除非代码包含的特定进程会干扰 UI 响应能力。我没有理由认为将所有内容都放在工作线程上。一般来说，只有当您等待 Web 服务等外部资源时，您才会遇到响应能力问题（除非您在 Form_Load 上计算素数:-)。
如果您还没有探索过异步 Web 服务调用，我建议您看一下。异步调用将为您处理线程 - 总是一件好事。
Personally, I wouldn't put code into a worker thread unless the code comprised a specific process was interfering with UI responsiveness. There's no reason I can think put everything on a worker thread. Generally you only have responsiveness issues when you're waiting for an external resource like a web service (unless you are calculating prime numbers on Form_Load :-).
If you haven't explored asynchronous web service calls, I would recommend taking a look. The asynchronous calls will handle your threading for you - always a good thing.
从您对“Page_Load”的引用来看，您似乎正在 ASP.NET Web 表单中实现此功能。如果是这种情况，并且您尝试异步调用 Web 服务，那么您应该使用该服务的 Begin 和 End 调用函数。如果您需要同时调用多个 Web 服务而不是一次同义地调用一个 Web 服务，那么这种方法尤其有效。
享受！
It sounds like, from your reference to "Page_Load", that you are implementing this in a ASP.NET web form. If that is the case and you are trying invoke a web service asynchronously then you should use the Begin and End invoke functions of the service. This works especially well if you need to call multiple web service at the same time instead of calling them one at a time synonymously.
Enjoy!