我知道有关 .net ORM 的问题已经被问了数千次，但我想知道哪种 ORM 在多线程环境中易于使用。欢迎商业或免费。
目前，我正在使用 Devexpress 的 XPO，但我觉得在多线程应用程序中使用起来很尴尬。来自一个线程的对象不能被另一个线程共享，要在另一个线程中使用它，我必须使用密钥从 DB 中找到对象，这真的很烦人。即使您锁定了对象的状态，也无法将 DB 对象的状态持久化到 DB。例如，除了创建对象的线程之外，不能从另一个线程调用 Save() 方法。
顺便说一句，我刚刚开始使用 XPO，也许我用错了。
nHibernate已在许多应用程序中使用，其中一些是多线程的。
请参阅有关concurrency的文档，特别是部分10.2- 它清楚地表明这不是ISession线程安全的（因此您需要自己管理它）。
就您而言，您能否澄清什么会使 ORM “易于工作”？
每个 O/RM 在多线程应用程序中都能完美运行。我在 ASP.NET 应用程序（每个定义是多线程的）中使用了 LINQ to SQL 和实体框架。
如果您在多线程环境中使用 O/RM 时遇到问题，那么您可能使用错了。例如，大多数 O/RM 工具都有一种实现工作单元模式的类型（例如 LINQ to SQL DataContext、Entity FrameworkObjectContext和 XPO Session）。一个工作单元意味着由单个线程创建和控制。如果您以这种方式使用这样的对象，我在多线程环境中使用 O/RM 工具时从未遇到任何问题。
Entity Framework 中的 ObjectContext 既不是线程安全的，所以如果你想将它作为共享资源，你可能必须自己实现并锁定它。
您可以为每个线程创建一个新的对象上下文，但如果您有很多线程正在生成/终止，这很容易成为性能问题。
此外，每个线程都有一个 ObjectContext 可能会导致数据过时。如下所述：
最后但并非最不重要的当然是多用户并发问题。ObjectContext 永远缓存它的实体，直到它被释放。如果另一个用户在他自己的 ObjectContext 上更改了相同的实体，则第一个 ObjectContext 的所有者将永远不会发现该更改。这些陈旧数据问题可能非常难以调试，因为您实际上可以看到查询进入数据库并返回新数据，但 ObjectContext 会用缓存中已经存在的旧数据覆盖它。在我看来，这可能是避免使用长寿命 ObjectContext 实例的最重要原因；即使您认为您已经对其进行了编码以从数据库中获取最新数据，ObjectContext 也会确定它比您更聪明，并将旧实体交还给您。