我知道有关 .net ORM 的问题已被问过数千次，但我想知道哪种 ORM 在多线程环境中易于使用。商业或免费都受到欢迎。
目前，我正在使用 Devexpress 的 XPO，但我觉得在多线程应用程序中使用它很尴尬。一个线程中的对象不能由另一个线程共享，要在另一个线程中使用它，我必须使用密钥从数据库中查找对象，这真的很烦人。即使您锁定了对象的状态，也无法将数据库对象的状态持久保存到数据库中。例如，除了创建对象的线程之外，不能从其他线程调用 Save() 方法。
顺便说一句，我刚刚开始使用 XPO，也许我用错了。
I know questions about .net ORM have been asked thousands of times, but i want to know which ORM is easy to work with in a multithreaded environment. Commercial or Free are both welcomed.
Currently, I am using XPO from Devexpress, but i feel it awkward to use in a multithread app. The object from one thread can't be shared by another thread, to use it in another thread i have to find the object from DB using the key, it's really annoying. You can't persist the DB object's state to DB, even if you lock the state of the object. e.g. the Save() method can't be called from another thread other than the one create the object.
BTW, i am just getting started with XPO, maybe I am using it wrong.
发布评论
评论（3）
nHibernate 已在许多应用程序中使用，其中一些是多线程的。
请参阅有关并发的文档，特别是
10.2- 它清楚地表明ISession是不是线程安全的（因此您需要自己管理）。您能否澄清一下，就您而言，什么会使 ORM“易于工作”？
nHibernate has been used in many applications, some of which are multi-threaded.
See the documentation on concurrency, specifically section
10.2- it clearly says thatISessionis not thread safe (so you need to manage this yourself).Can you please clarify what would make an ORM "easy to work", as far as you are concerned?
每个 O/RM 在多线程应用程序中都能完美工作。我在 ASP.NET 应用程序（根据定义是多线程的）中使用了 LINQ to SQL 和实体框架。
如果您在多线程环境中使用 O/RM 时遇到问题，那么您可能使用了错误的方法。例如，大多数 O/RM 工具都有一种实现工作单元模式的类型（例如 LINQ to SQL 的 DataContext、Entity Framework 的 ObjectContext 和 XPO 的 Session） ）。工作单元是由单个线程创建和控制的。如果您以这种方式使用这样的对象，那么我在多线程环境中使用 O/RM 工具就不会遇到任何问题。
Every O/RM works perfectly in a multi-threaded application. I've used LINQ to SQL and Entity Framework in ASP.NET applications (which are multi-threaded per definition).
If you're having trouble using your O/RM in a multi-threaded environment, you are probably using it wrong. For instance, most O/RM tools have a type that implements the Unit of Work pattern (such as LINQ to SQL's
DataContext, Entity Framework'sObjectContext, and XPO'sSession). A unit of work is meant to be created by and controlled by a single thread. If you use such an object this way, I have never had any trouble using an O/RM tool in a multi-threaded environment.实体框架中的 ObjectContext 都不是线程安全的，因此如果您希望将其作为共享资源，您可能必须通过锁定它来实现自己的对象上下文。
您可以为每个线程创建一个新的对象上下文，但如果有大量线程产生/死亡，这很容易成为性能问题。
此外，每个线程都有一个 ObjectContext 可能会导致数据过时。如下所述：
ASP.NET 会话对象中的实体框架对象上下文？
The ObjectContext in Entity Framework is neither thread-safe, so you'll probably have to implement your own with locking to it if you want to have it as a shared resource.
You could create a new object context for every thread, but if you have a lot of threads spawning/dying, this could easily become a performance issue.
Also, having a ObjectContext for each thread could result in data staleness. As stated below:
Entity Framework Object Context in ASP.NET Session object?