主页 / 问题 / 912895
Accepted
Monk
Asked:2020-11-29 01:51:03 +0000 UTC2020-11-29 01:51:03 +0000 UTC

如何使代码上下文敏感，但不显式传递上下文？

  • 772

现在是什么：

public static Page GetPage(Uri url)

你需要什么：

限制某些“上下文”内的请求数量。

  1. 这可以是 url 参数中的主机（这是最简单的选项，您可以只写下当前主机和限制）
  2. 可能有一个“站点”在不同的云提供商实例上托管不同的东西，您无法通过主机将它们区分开来。
  3. 可能有一个程序集请求一个方法（即一个程序集，例如，使用此方法一次不能接收超过 3 个不同的页面）
  4. 可能有一个方法（该方法不应该，例如并行发出大量请求），虽然它可能包含在以前的版本中，但我还没有仔细考虑过。

总的来说，一方面我希望当我做一个条件的时候godObject.Download()，他在里面做一些他自己的检查，加上下载，再加上一些其他的东西，这样里面就不会出现一堆并行请求，另一方面，这样当我这样做simpleClass.DownloadAllLinks()时，他可以并行处理一组链接，如果它们位于不同的资源上。

这大致被视为一个属性Request，它几乎总是存在于 Web 服务器中，因为 请求处理是整个生命周期。无论如何，我也有某种应用程序周期，例如，用户按下按钮（但不幸的是，它不会成为下载页面的上下文）。但我仍然无法将它们放在某种合乎逻辑的方案中。

我不想将方法重新制作为非静态的，因为它已经在许多地方使用，并且不容易显式地到达那里，例如“上下文”的实例。

c#

2 个回答

  1. Best Answer

    很久以前我就想到了主要想法，总的来说，这条消息证实了它的可行性

    不幸的是，netcore 还没有CallContext，但是enSO建议了一个输出，在测试时，它的行为相似并且没有发现任何问题。

    结果，代码如下所示：

    using (ThrottleService.SetThrottler(new Throttler(15)))
{
  godObject.Download();
}

    ThrottleService它只是把它放在CallContext一个 trotter 的实例中，GetPage在它里面简单地引用CallContext并检查它是如何受到限制的。

    它与创建的子任务配合得很好，它在节流阀内部很愚蠢SemaphoreSlim。

    从您可以做的其他事情中 - 您可以将猪蹄相互嵌套，以便表单的构造（以不同的方法创建）起作用：

    using (ThrottleService.SetThrottler(new Throttler(15)))
using (ThrottleService.SetThrottler(new Throttler(10)))

    从应用程序逻辑的角度来看，此解决方案运行良好 - 如果您知道您的代码可以生成许多请求，请指出某种限制。

    这里还有一个减号 - 如果您在特定位置指定了限制，那么在堆栈的更高层您只能进一步限制条件，您将不再能够仅转移您的限制。您可以考虑一下并发明一个拐杖，但总的来说，AK更有可能就在这里，您应该考虑重构。现在，为了加快问题的解决速度，我宁愿结合代码 - 我将添加解决方案CallContext并添加显式传输节流器的能力，以应对已经在手边的情况。

    • 2

  2. 我在“下载网站”或“向 SMEV 提出请求”的框架内遇到了类似的任务，总的来说，我不明白问题的本质。没有什么可以阻止您在您的方法中放置任何逻辑“每秒对某个域不超过三个请求，对另一个域不超过五个”，并排队由于限制而无法处理的请求。

    毕竟，你自己真的明白你已经走上了一条弯路，你的对象变得越来越神对象——你明白重做方法签名已经花费了很多血——但还没有准备好回到正确的道路。好吧，继续 - 价格只会上涨。

    对我来说，你只需要决定一个正常的重构。我看到很多人带着这个想法去看牙医很长时间，然后他们想知道为什么他们不早点去。这里有类似的东西。对你来说还不算太晚 - 在你的脑海中重构，那么以后对你来说会更容易，特别是当你添加单独的线程/处理程序时，每个线程/处理程序都有自己的代理、自己的队列和策略。

    我认为它是一个成熟的对象，可以接受队列中的链接并可以使用队列策略。好吧，它会在与 UI 分开的线程中的某个地方自行工作。

    • 1

相关问题