问题：我正在为企业级 Web 应用程序构建（或尝试构建）前端。 现有结构由存储过程 （SQL 2008 DB） 驱动。存储的过程作为类实现，该类最终处理执行，结果作为对象返回。我是这个游戏的新手，欢迎解释如何最好地服务我的时间......我阅读存储库模式是最佳实践，但我阅读的所有示例都实现了实体框架或 Linq 等。我需要 ORM 吗？为什么或为什么不呢？我希望能够有一个最高性能的环境，以便用户可以使用这些结果集。提前致谢
好吧，我建议您决定您的用例。
nHibernate/ORM通常不利的一些事情是：
- 批处理作业。
- 报告
因此，如果您的工作主要涉及其中任何一个，那么您最好不要浪费时间，话虽如此，拥有多种策略并没有错...... 构建域模型非常适合简化复杂的业务规则，性能通常也非常好...... 报告和批处理作业可以单独构建，没有理由不同的策略不能共存...... 然而，我尽我所能让他们脱钩......
因此，如果你有一个大毛茸茸的业务逻辑层，并且你的存储过程中充斥着数据集/数据访问代码和业务逻辑，那么你可能会发现投资ORM是值得的，但认为这是一个重构步骤......IE 您正在改进现有代码并在扩展之前使其可测试......
无论如何，没有一个"最佳"答案，我在以前的公司所做的最聪明的事情就是以任何似乎对功能有意义的数据访问模式构建新功能（当然是测试驱动）。保持接口清洁和解耦... 这样做一段时间后，通常会很明显哪种策略/模式最适合整体应用程序......
祝你好运
你的问题有些不清楚。 存储过程是存储在数据库上的 SQL 查询，用于与数据交互。 但是，听起来您已经有一个现有的数据访问层 （DAL），它使用存储过程并将对象返回给您使用。 如果是这种情况，我不会丢弃整个数据访问层并将其替换为 EF 或任何其他 ORM。 除非现有的 DAL 由于设计或性能原因不适合您，否则没有理由重新发明轮子。