所以我有一个应用程序需要非常快速地访问大量数据，我们正处于对数据库进行大规模重新设计的阶段，这为重写数据提供了一个很好的机会如果需要，访问层!
目前在我们的数据访问层中，我们使用手动创建的实体以及纯 SQL 来填充它们。这非常快，但这项技术确实已经过时了，我担心我们错过了更新的框架或数据访问方法，它们在整洁性和可维护性方面可能会更好。
我们已经看到了 Entity Framework ，但经过一些研究后发现它提供的 ORM 的好处似乎不足以证明较低的性能是合理的，并且由于我们的一些查询变得越来越复杂，我确信性能EF 将成为一个更大的问题。
所以这是坚持我们当前的数据访问方法的情况，还是有比手动创建和维护实体更简洁的方法？
我想困扰我的是打开我们的数据层解决方案并看到很多实体，所有这些都需要根据数据库完全维护，有时可能会很多的工作，但这也许就是我们为性能付出的代价？
非常感谢任何想法、意见和建议! :)
谢谢，
安迪。
** 更新**
忘记提及我们确实需要能够处理使用 Azure(客户端要求)，这目前阻止我们使用存储过程。 ** 更新 2 ** 实际上我们的 DAL 有一个接口(interface)层，这意味着我们可以创建一个 Azure 实现，它只是覆盖本地实现中不适合 Azure 的数据访问方法，所以我想我们可以只使用存储过程使用适用于云的 EF 对性能敏感的本地数据库。
最佳答案
我会使用 ORM 层( Entity Framework 、NHibernate 等)来管理各个实体。例如，我会使用 ORM/实体层来允许用户对实体进行编辑。这是因为将您的数据视为实体在概念上更简单，并且 ORM 使编写这些东西变得非常容易，而无需编写任何 SQL。
对于批量报告方面的事情，我绝对不会使用 ORM 层。我可能会专门为标准报表创建一个单独的类库，它自己创建 SQL 语句或调用 sprocs。 ORM 并非真正用于批量报告，您永远无法通过 ORM 获得与通过手动编码的 SQL 进行查询一样的灵 active 。
关于c# - 我应该使用什么来访问性能敏感的数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4734543/