我在需要时使用依赖项注入来访问我的服务，但我现在想要创建一个并发任务，但这会由于依赖项注入对象及其生命周期而导致问题。
我读过这篇文章（标题：防止多线程）：Link http://mehdi.me/ambient-dbcontext-in-ef6/由此看来，我认为这是不可能的。
我的目标是让客户端发送一个开始作业的请求，该请求可能需要比客户端的连接超时更长的时间，因此我希望有一个端点来启动任务并返回任务是否已成功启动的状态。
问题是，因为数据库上下文和其他服务是在请求线程内的控制器上创建的，所以当您将该对象传递到新任务并结束旧任务时，这些对象会因为创建的事实而被处置在所述线程上。
我知道对于数据库上下文，您可以注入数据库工厂接口并创建一个新实例，但这对于非数据库对象没有帮助。 （我还读到创建自己的服务实例会破坏依赖注入的点）。
有没有办法可以在新线程/任务上创建注入依赖项的新实例，或者完全避免此问题？谢谢。
创建一个并发任务，但这会由于依赖项注入对象及其生命周期而导致问题。
每次您分离后台线程或可能在不同线程上并行运行的任务时，您在该操作期间需要做的第一件事就是从容器请求您希望使用的服务。这样容器就可以根据对象的生活方式来确定需要构建哪些对象。将依赖关系从一个线程转移到另一个并行运行的线程是一种罪过。
看看以下信息 https://simpleinjector.org/howto+multi-threading了解如何在多线程应用程序中使用 DI。这些信息是根据特定的 DI 容器编写的，但大多数信息通常适用于 DI。
在您的情况下，您希望将请求的数据转发到能够启动新线程、创建新范围、从该范围解析实际处理程序并调用它的类。你可以看到一些非常相似的东西这个答案 https://stackoverflow.com/a/45128469/264697.
或者完全避免这个问题？
您应该只在后台线程上分拆操作，以防您不关心它们是成功还是失败。然而，在大多数业务事务中，当操作失败时，您希望通知用户这一点，让他知道他必须重试，或者您希望代表他自动重试操作。如果您只是在后台线程上分离操作，则很难可靠地实现这一点。
更好的解决方案是使用持久的排队机制。这可以是数据库队列或消息队列。此类技术可确保操作不会丢失，并且通常具有内置的重试机制。查看在 RabbitMq、MSMQ 或 SQL Server 之上运行的 MassTransit 或 NServiceBus 实例。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
