我喜欢控制反转(IOC)模式，并经常使用它。像往常一样，我对线程和它们在.NET的OO生态圈中的位置有问题。

我在考虑线程化并使用.NET中的"内置"threadpool类，我意识到它的操作与您的代码在一个完全不同的级别上，并且它超出了IOC模式对于IOC容器(如Unity)的范围。

我不太清楚在国际奥委会的领域里有什么样的线索，但是如果可以被当作一个类来对待，那么它可能是一个被纳入你的国际奥委会框架的候选人。如果是这种情况，您如何处理线程池的使用。

这个评估是正确的吗？

首先，我实际上从未直接使用ThreadPool，而是有一个接口IThreadPoolService，我通过一个ioc容器解析它。这对于单元测试逻辑非常有帮助，在单元测试逻辑中，线程方面会使事情变得更困难，但不会给测试方面增加任何内容。我可以使用非线程测试版本模拟服务。

我不认为使用ThreadPool违反了IOC，因为ThreadPool本身并不控制任务，它只负责调用入口点。它也不是"创造性的"，它是IOC容器的核心部分。

使用ioc容器解析IThreadPoolService提供了添加间接层的通常好处，例如，您可以更改实现并添加其他行为，例如日志记录，当然可以通过iocdi支持这些行为。

线程和IOC没有太多共同点。无论是否涉及穿线，都可能发生松耦合。尝试为线程类提供接口是可能的，但是您不抽象掉其他.NET框架类，是吗？

采用将以某种形式公开数据的服务。如果服务决定通过线程提供异步行为，那么使用者必须考虑到这一点。打电话给国际奥委会仍然是国际奥委会的职责范围。

当服务作为接口公开时，它可以根据需要进行更改，同时仍然提供所需的行为，在这种情况下，这将是异步行为。这将允许您在接口中定义一个方法，并在数据准备就绪后定义一个回调/事件，同时仍然使用Unity和其他IOC框架。