我应该如何使用对性能敏感的数据访问？
因此，我有一个应用程序需要非常快速地访问大量的数据，我们正处于对数据库进行大量重新设计的阶段，这为重新编写数据访问提供了良好的操作性层如果nessersary！我应该如何使用对性能敏感的数据访问？
当前在我们的数据访问层中，我们使用手动创建的实体以及普通SQL来填充它们。这很快，但是这项技术真的变老了，我担心我们错过了一个更新的框架或数据访问方法，在整洁和可维护性方面可能会更好。
我们已经看到了实体框架，但经过一番研究，似乎它所提供的ORM的好处并不足以证明性能较低，而且我们的某些查询变得越来越复杂，我确信性能与英孚将成为更多的问题。
所以这是坚持我们目前的数据访问方法，还是有一些比手动创建和维护实体有点整洁的情况？
我想这是窃听我是刚刚打开我们的数据层的解决方案，看大量的实体，所有这些都需要保持正是在数据库中，这有时是一个大量的工作线的事情，但那么也许这就是我们为演出付出的代价？
任何想法，意见和建议，非常感谢！ :)
谢谢，
安迪。
** **更新
忘了提，我们真的需要能够使用Azure的（客户的需求），目前阻止我们使用存储过程来处理。 ** Update 2 **实际上，我们有一个用于DAL的接口层，这意味着我们可以创建一个Azure实现，它只是覆盖来自Local实现的不适合Azure的数据访问方法，所以我想我们可以使用存储过程针对性能敏感的本地数据库，并使用EF作为云。
我会使用一个ORM层（实体框架，NHibernate等）来管理各个实体。例如，我会使用ORM /实体图层来允许用户对实体进行编辑。这是因为将您的数据视为实体在概念上更简单，并且ORM使得编写这些东西非常容易，而无需编程任何SQL。
对于事物的批量报告方面，我绝对不会使用ORM层。我可能会专门为标准报告创建一个单独的类库，它可以自己创建SQL语句或调用sprocs。 ORM实际上并不适用于批量报告，您将永远无法通过手动编码SQL获得通过ORM查询的相同灵活性。
存储过程的性能。易于开发的ORM
当您运行不好时，您是否想要解决一些不透明生成的SQL问题？那会产生几次往返行程，人们会做？或者坚持使用错误的数据类型？
不排除普通的旧ADO.NET。它可能不如EF4那么髋关节，但它只是起作用。
使用ADO.NET你知道你的SQL查询将会是什么样的，因为你对他们100％的控制什么。 ADO.NET迫使开发人员去思考SQL，而不是回到ORM上去做魔术。
如果性能是高的名单上，我很不愿意承担任何ORM尤其是EF这是新的现场和高度复杂的依赖关系。 ORM的加速开发（稍微），但会使你的SQL查询性能很难预测，并且在大多数情况下比手动SQL /存储过程慢。
您也可以单元测试SQL /存储的特效独立于应用程序，因此隔离性能问题或者DB /查询相关或应用相关。
我猜你是使用ADO.NET在DAL了，所以我建议你投资的时间和精力在重构它，而不是把它扔出去。
如此有效地有两个DAL的？一个用于使用普通SQL的性能数据，另一个用于使用EF的其他bog标准内容？性能DAL可以重复使用由EF创建的实体吗？因此，两个DAL都会将相同的对象返回给BLL？ – Andy 2011-01-19 11:50:34
是的，我提出了并排系统，尽管在我的辩护中，他们使用专为他们的特定目的而设计的工具来完成不同的事情。我会主张不使用EF（和实体）进行报告，因为EF会根据您的报告编写来绑定您的手。有时低层次的东西感觉更简单，因为它更直接。 – David 2011-01-19 16:05:24
值得一提的是，通过SQL/sprocs进行报告不会返回实体（除非您为实体编程执行了大量繁琐的数据集）。但我认为这不重要。 （虽然它可能对你很重要。） – David 2011-01-19 16:10:17