我正在研究一个新项目，并考虑使用超出OpenAccess或LLBLGen Pro或Subsonic的ORM . 这个项目可能会有很大的数量并且同时发生，因此我们的性能要求非常高 .
请比较并推荐给我 . 谢谢
吉姆 .
吉姆
为了在回答此问题时获得最佳结果，您需要进行自己的比较，因为您的特定要求和数据访问方案可能会影响任何此类性能测试的结果 .
也就是说，我们将LLBLGen用于高吞吐量Web应用程序，性能非常出色 . 我们发现最大的问题在于应用程序设计本身 . 使用SQL Server Profiler，我们可以看到（在开发期间）应用程序的哪些部分在数据库上创建了大量的命中 . 我们发现的最大损失是加载网格然后执行另一个数据库操作OnDataBinding / DataBound事件 . 这会为SQL Server数据库创建大量流量，大量读取和大量磁盘交换 . 通过在构建数据/连接/等组时做出良好的设计选择，确保我们获得第一个查询中的所有数据，我们得到了很好的服务 . 在构建应用程序时 - 或者一旦我们发现性能很慢就重构它 .
LLBLGen的开销至少是非常小的 . 即使在创建大量对象时它也很快 . 当我们进行产生其他查询的查询（例如上面的例子）并且我们的数据库读取通过屋顶时，会产生更大，更大的性能影响 .
您可能希望评估您认为哪一个更适合您的技能和 生产环境 力 .
1 回答
吉姆
为了在回答此问题时获得最佳结果，您需要进行自己的比较，因为您的特定要求和数据访问方案可能会影响任何此类性能测试的结果 .
也就是说，我们将LLBLGen用于高吞吐量Web应用程序，性能非常出色 . 我们发现最大的问题在于应用程序设计本身 . 使用SQL Server Profiler，我们可以看到（在开发期间）应用程序的哪些部分在数据库上创建了大量的命中 . 我们发现的最大损失是加载网格然后执行另一个数据库操作OnDataBinding / DataBound事件 . 这会为SQL Server数据库创建大量流量，大量读取和大量磁盘交换 . 通过在构建数据/连接/等组时做出良好的设计选择，确保我们获得第一个查询中的所有数据，我们得到了很好的服务 . 在构建应用程序时 - 或者一旦我们发现性能很慢就重构它 .
LLBLGen的开销至少是非常小的 . 即使在创建大量对象时它也很快 . 当我们进行产生其他查询的查询（例如上面的例子）并且我们的数据库读取通过屋顶时，会产生更大，更大的性能影响 .
您可能希望评估您认为哪一个更适合您的技能和 生产环境 力 .