所以我有一个需要非常快速访问大量数据的应用程序，我们正处于对数据库进行大规模重新设计的阶段，这为重写数据提供了良好的机会访问层，如果nessersary！
目前，在我们的数据访问层中，我们使用手动创建的实体和纯SQL来填充它们。这是非常快的，但这项技术真的变老了，我担心我们错过了一个更新的框架或数据访问方法，它在整洁性和可维护性方面可能更好。
我们已经看过实体框架，但经过一些研究后，似乎它所提供的ORM的好处不足以证明性能较低，而且由于我们的一些查询变得越来越复杂，我确信它的性能与EF将成为一个问题。
所以这是一个坚持我们目前的数据访问方法的情况，还是比手动创建和维护实体更简洁？
我想那些困扰我的事情只是打开我们的数据层解决方案并看到许多实体，所有这些实体都需要与数据库保持完全，这有时可能很多工作，但那可能这是我们为绩效付出的代价？
非常感谢任何想法，意见和建议！ ：）
谢谢，
安迪。
**更新**
忘了提到我们确实需要能够处理使用Azure（客户端要求），这当前阻止我们使用存储过程。 **更新2 **实际上我们有一个DAL的接口层，这意味着我们可以创建一个Azure实现，它只是覆盖Local实现中不适合Azure的数据访问方法，所以我想我们可以只使用存储过程对于具有EF for the cloud的性能敏感的本地数据库。
答案 0 :(得分：1)
我会使用ORM层（实体框架，NHibernate等）来管理各个实体。例如，我将使用ORM /实体层来允许用户对实体进行编辑。这是因为将数据视为实体在概念上更简单，并且ORM使得编写这些东西变得非常容易，而无需编写任何SQL。
对于批量报告方面，我绝对不会使用ORM层。我可能会专门为标准报告创建一个单独的类库，它自己创建SQL语句或调用sprocs。 ORM并不是真正用于批量报告的，并且您永远不会像通过手工编写的SQL那样通过ORM获得相同的灵活性。
答案 1 :(得分：0)
存储的性能程序。 ORMs易于开发
在运行错误时，您是否想要对一些不透明的生成SQL进行故障排除？这会产生几次往返的旅行吗？或者坚持使用错误的数据类型？
答案 2 :(得分：0)
您可以尝试使用mybatis（以前称为ibatis）。它允许您将sql语句映射到域对象。这样，您可以完全控制正在执行的SQL，并同时获得干净定义的域模型。
答案 3 :(得分：0)
不排除普通的旧ADO.NET。它可能不如EF4那么时髦，但它只是有效。
使用ADO.NET，您可以了解SQL查询的外观，因为您可以100％控制它们。 ADO.NET迫使开发人员考虑SQL，而不是回到ORM来做魔术。
如果你的名单上的表现很高，我不愿意依赖任何ORM，尤其是EF，这是现场的新功能，非常复杂。 ORM加快了开发速度（一点点）但会使你的SQL查询性能难以预测，并且在大多数情况下比手动滚动的SQL /存储过程慢。
您还可以独立于应用程序对SQL /存储过程进行单元测试，从而将性能问题隔离为与数据库/查询相关或与应用程序相关。
我猜你已经在你的DAL中使用了ADO.NET，所以我建议花时间和精力来重构它而不是把它扔掉。