目前我正在使用自定义业务对象层（采用外观模式），其中从存储过程加载对象的属性以及为业务逻辑提供位置。这一直在努力将我们的代码基础转移到更分层和标准化的应用程序模型，但觉得这种方法更多是一个渐进的步骤，而不是一个永久的步骤。.Net ORM /业务对象框架性能
我目前正在研究转向更正式的框架，以便某些架构决策不必是我自己的。在过去，我曾与CSLA和Linq合作过SQL，虽然我喜欢CLSA的许多设计决策，但我发现它对我的口味有点臃肿，Linq to SQL可能没有我想要的性能。我对NHibernate的普及以及Linq对实体的推动感兴趣，但是性能是一个关键问题，因为有一些情况下需要一次提取大量记录（> 15k）（请不要辩论原因为此），并且对于采用正式的.Net对象框架看起来是最佳选择的表现很好奇？
注意：这将主要用于Winform和WPF应用程序。
重复：https://stackoverflow.com/questions/146087/best-performing-orm-for-net
http://ormbattle.net - 那里的性能测试看起来几乎正是你想看到的。
你必须看看物化测试（获取大量项目的性能正是它所显示的）;而且，你可以将ORM性能与ADO.NET上几乎理想的SQL性能进行比较。
太棒了！我甚至还在寻找更多的数据。谢谢！ – jwarzech 2009-12-15 14:51:55
随着你打算通过在PROC缓存中的第1级得到提振开箱任何ORM。特别是对于负载，如果它已经存在，它不会去Pluto（DB）。大多数ORM有机会注入L2输出缓存。关于这些的好处是他们只是插入ORM。为NHibernate签出NCache。
如果缓存使用率是_possible_，可能会有提升。但例如如果他从数据库中顺序读取数以千计的非常简单的对象，缓存将不会有多大帮助：ORM中的缓存显着提高了随机读取的性能（实际上，通过简单地减少ORM和RDBMS之间的差异），而不是顺序读取（因为根本没有讨厌）。 – 2009-12-04 00:06:40
O/R映射器的性能将很大程度上取决于应用程序的设计方式以及映射业务对象的方式。例如，您可以轻松地通过在循环中延迟加载子对象来取消性能，以便1000个对象的1个选择变为1001个选择（google n + 1 select）。
o/r映射器最大的性能提升之一是开发人员的生产力，这通常比应用程序性能更重要。对于大多数在最新硬件上运行的应用程序，最终用户通常可以接受应用程序性能无论有多少Mountain Dew被应用到这个问题上，开发者的表现仍然是一个瓶颈。 :-)
听起来好像你在问关于对象关系映射框架（简称ORM） - 你应该考虑改变你的问题的标题来指定，因为很多人可能不会认同'对象框架'的含义。 – 2009-10-30 14:47:43
我想你正在寻找一个对象关系映射器（ORM），而不是“.Net对象框架”。您可能需要相应地更改标题... – 2009-10-30 14:47:46
感谢您的建议，我将其更改为ORM /业务对象框架，因为我不反对类似于CSLA的东西，它不是一个ORM。 – jwarzech 2009-10-30 14:54:37