我很擅长构建宁静的网络api，但我一直在做很多学习，并且对基础知识有很深的理解。我使用web api 2的最新最佳实践为我的公司构建了一个服务。属性路由和路由前缀，依赖注入等等。我认为我的服务非常可靠，但可能需要重构。
我的公司正在考虑从MS SQL转移到PostGreSql或可能是一个不同的数据库解决方案。另外，我应该提到我们不使用EF或任何其他ORM。我们不使用EF的原因是因为我们的数据库架构在不断变化，我们有许多环境，这些环境通常彼此不同（dev，qa，prod等）。所以我们开发了自己的框架来处理对数据库的查询。我们经常使用存储过程来检索数据。
因此，更改我的服务以适应不同的数据库，似乎存储库模式将是解决方案。然而，当我开始研究它时，感觉就像我们正在添加大量的开销代码，实际上，如果DB更改实际发生，可能只需更少的代码就可以返回并重构服务。对于我的每个控制器，我至少需要编写一个IModelRepository和ModelRepository类。
任何人都可以就此提供任何指导吗？
编辑：
我不确定如何使这个问题不那么广泛。在我的问题中，我对存储库模式的了解不够详细。我基本上，只是想知道存储库模式是否是未来在web api MVC服务中可能更改数据库解决方案的问题的解决方案，即使我没有使用类似ORM的实体框架？
我问，因为我在网上找到的每个例子似乎都使用EF，因此很难与我当前的问题联系起来。然而，最佳答案给出了一个非常好的解释，我认为我的问题得到了回答。我只需要找到一个很好的资源来学习模式。感谢。
答案 0 :(得分：2)
存储库模式尝试使用数据映射层来避免域的紧密耦合（或者只是将其称为数据层< / em>），偶尔依赖于选择的基础数据技术。
虽然您可能觉得在您的具体用例中没用，但我会尝试用一个非常简单的参数说服您：数据访问详细信息将在您的存储库中强制执行，这意味着您的数据策略将是在那里自给自足。换句话说：您的域将保持与数据访问方法无关，如果您将来需要更改它，则无需更改成千上万的代码行。
结论：即使在您的场景中，存储库模式也很有用。保留您的域代码以解决域问题，而不是将所有内容混合在一个真正的spaguetti代码中！
当存储库模式遇到控制反转时，一切都变得更加强大，因为您可以通过配置切换域转换为数据的方式，并强制执行更多松散耦合和和关注点分离。
打败这个;）
答案 1 :(得分：1)
不使用EF似乎是错误的。 EF将是在很大程度上抽象出数据库的存储库。您希望能够定位不同的数据库产品。 EF擅长这一点。
引入实体框架来解决问题。