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