存储库模式与否？需要ORM吗？ MVC Web api REST [关闭]

Question

我对构建 restful web api 还很陌生，但我已经做了很多学习，并且对基础知识有很深的了解。我使用 web api 2 的最新最佳实践为我的公司构建了一项服务。属性路由和路由前缀、依赖注入等。我认为我的服务非常可靠，但可能需要重构。

我的公司正在考虑从 MS SQL 迁移到 PostGreSql 或可能使用不同的数据库解决方案。另外，我应该提到我们不使用 EF 或任何其他 ORM。我们不使用 EF 的原因是因为我们的 DB 模式在不断变化，而且我们有许多彼此不同的环境（dev、qa、prod 等）。因此，我们开发了自己的框架来处理对数据库的查询。我们经常使用存储过程来检索数据。

因此，更改我的服务以适应不同的数据库，存储库模式似乎是解决方案。但是，当我开始研究它时，感觉就像我们添加了很多开销代码，而实际上，如果数据库更改确实发生，那么只需返回并重构服务可能需要编写的代码更少。对于我的每个控制器，我至少需要编写一个 IModelRepository 和 ModelRepository 类。

谁能提供这方面的指导？

编辑：

我不确定如何使这个问题不那么广泛。我对存储库模式知之甚少，无法在我的问题中更详细地介绍。我基本上只是想知道存储库模式是否是解决未来可能在 Web api MVC 服务中更改数据库解决方案的问题的解决方案，即使我没有使用类似 ORM 的实体框架？

我问是因为我在网上找到的每个示例似乎都使用 EF，这使得我很难与我当前的问题相关联。但是，最佳答案给出了一个很好的解释，我认为我的问题得到了回答。我只需要找到一个很好的资源来学习模式。谢谢。

Answer 1

存储库模式试图避免您的 域 与 数据映射层 的紧密耦合（或者只是将其称为 数据层)，这有时取决于选择的底层数据技术。

虽然您可能会觉得这在您的具体用例中没有用，但我会尝试用一个非常简单的论点来说服您：数据访问详细信息将在您的存储库中强制执行，这意味着您的数据策略将是独立在那里。换句话说：您的域将与数据访问方法无关，如果您将来需要更改它，您将不需要更改成千上万的代码行。

结论：即使在您的场景中，存储库模式也是有用的。让您的域代码仅用于解决域问题，而不是将所有内容混合在真正的意大利面条代码中！

控制反转故事...

当存储库模式遇到控制反转时，一切都会变得更加强大，因为您可以通过配置切换域转换为数据的方式，并且您可以强制执行更多松散耦合和和关注点分离。

打败这个 ;)

Answer 2

不使用 EF 似乎是个错误。 EF 将是在很大程度上抽象出数据库的存储库。您希望能够针对不同的数据库产品。英孚擅长这一点。

引入实体框架解决问题。