存储库和实体框架答案

【问题标题】：Repositories and Entity Framework存储库和实体框架
【发布时间】：2015-08-08 07:30:09
【问题描述】：

我正在为我的应用程序构建一个 web api，现在我正在寻找设计我的数据访问层的方法。

最后，应用程序应该能够支持非常大量的客户端和非常大量的查询。

我听说过实体框架，但我对它有两个担忧：

很多人告诉我，实体框架在性能方面并不是最好的，而性能是我不能忽视的。
我才刚刚开始构建应用程序，我仍在寻找开发人员加入我，如果我现在从实体框架开始，我可能想要/需要更改 orm/库（因为以上或任何其他原因）甚至未来的数据库技术。

存储库是抽象数据访问层并使其对业务层不可见的好方法，因此如果有一天我想更改 DAL/数据库技术，我不必接触业务，只需更改存储库。

不过，我已经阅读了很多关于如何将实体框架与存储库模式结合起来是一种不好的做法。

我真的很困惑......我有几个问题。

我应该使用实体框架吗？表演对我来说很重要。
我应该将它与存储库模式结合起来吗？如果没有，我想改变数据库技术/orm怎么办？

我已经练习过将存储库模式与本机 sql 客户端（运行本机 sql 查询）一起使用，但我没有使用 orm 的任何练习，至少在 .net 中没有

大型应用程序使用原生 sql 查询并用存储库包装它们真的是一件坏事吗？

以尽可能最好的方式开始编写我的应用程序（应用所有最佳实践）对我来说非常重要，这样我以后不会有太多的困难。

谢谢，阿里克

【问题讨论】：

标签： asp.net database entity-framework asp.net-web-api repository-pattern

【解决方案1】：

Ad.1) 是的，Entity Framework 非常慢 - 但是 - 当开箱即用时，如果开发人员对 Entity Framework 有深入知识，它在幕后做了什么，如何优化查询 - 它可以与您自己实现的数据访问一样快。

Ad.2) 如果您想更改 ORM 或数据库技术 - 这与您是否使用 EF 无关，而是您将为软件设计的架构问题。

Ad.1) 参见之前的 Add.1，如果性能真的很重要，我个人会使用低级 SqlDataReader，尽管我很伤心，但可以以高性能的方式使用 EF。

Ad.2) 我认为将存储库模式与 EF 结合起来并没有什么不好，在小型应用程序中这可能是一种开销，因为 EF 基本上是存储库模式的实现，所以你会得到一个“双存储库模式”，但它允许您抽象出与 EF 的耦合

Ad.3) 我不认为这是一个坏方法 - 但这显然取决于应用程序。

【讨论】：

我在互联网上看到很多代码示例，其中实体框架的使用与业务层紧密耦合，我真的不希望它那样，现在的一件事是对我来说，比性能更重要的是可维护性和灵活性。我不熟悉实体框架，我认为在最低级别熟悉它会消耗太多时间，所以我想我将开始使用本机 sql 查询或一些微操作（如 dapper）来实现存储库模式.感谢您的有用回复。
是的，这些代码示例就是它们的本质 - 代码示例。最多可用于小型应用程序。我会完全按照您的建议进行。
EF 与任何其他 ORM 一样快。使用低级方法会浪费大量的开发时间。磁盘和 CPU 便宜
@TFD 不过，这是否意味着抽象数据层是个坏主意？我可以制作将使用实体框架的存储库实现，同时允许我随时更改数据库技术，而无需触及我的业务层。那么使用存储库抽象 DAL 的缺点是什么？

【解决方案2】：

如果您遇到一些性能问题，我认为使用存储库模式是一个好主意和一种出路。

关于 Dapper，问题是为什么 Dapper 比 EF 和 NHibernate 性能更高。没有延迟加载，没有 DML，简单的映射器等等。如果您想要 DML（我愿意）并且有时需要延迟加载，您可以采用混合方法。存储库模式 + EF + Dapper。

我的方法实际上是存储库模式 + EF + 很少的查询（大量更新和删除以及很少的选择 - EF 也为简单的查询编写了大量的 SQL 语句 - ）。要映射选择，您可以包括 Dapper（我没有），手动进行（手动映射或使用 EF 中的功能 - 但有一些限制 - 或编写一些通用的东西）。通常我手动映射它，但我也写了一个基于 EF 映射的映射器
Entity framework Code First - configure mapping for SqlQuery
我用了几次，实际上我不再使用它了。

【讨论】：