存储库模式与否?需要ORM吗?MVC Web api REST.
本文关键字:MVC Web REST api ORM 需要 模式 存储 | 更新日期: 2023-09-27 17:56:24
我对构建 Restful Web API 很陌生,但我一直在做很多研究,并且对基础知识有很强的理解。 我使用 Web api 2 的最新最佳实践为我的公司构建了一项服务。 属性路由和路由前缀、依赖关系注入等。 我认为我的服务非常可靠,但可能需要重构。
我的公司正在考虑从MS SQL转向PostGreSql或可能的其他数据库解决方案。 另外,我应该提到我们不使用 EF 或任何其他 ORM。 我们不使用 EF 的原因是因为我们的数据库架构在不断变化,并且我们有许多通常彼此不同的环境(dev、qa、prod 等)。 因此,我们开发了自己的框架来处理对数据库的查询。 我们经常使用存储过程来检索数据。
因此,更改我的服务以适应不同的数据库,似乎存储库模式将是解决方案。 但是,当我开始研究它时,感觉就像我们添加了很多开销代码,而实际上,如果数据库更改实际发生,编写的代码可能会更少,只需返回并重构服务。 对于我的每个控制器,我至少需要编写一个IModelRepository和ModelRepository类。
任何人都可以对此提供任何指导吗?
编辑:
我真的不确定如何使这个问题不那么广泛。 我对存储库模式的了解不够,无法在我的问题中更详细地介绍。 我基本上只是想知道存储库模式是否是将来可能在 Web api MVC 服务中更改数据库解决方案的问题的解决方案,即使我没有使用类似 ORM 的实体框架?
我问是因为我在网上找到的每个示例似乎都使用 EF,这使得很难与我当前的问题联系起来。 但是,顶部答案给出了一个非常好的解释,我认为我的问题得到了回答。 我只需要找到一个好的资源来学习模式。 谢谢。
存储库模式试图避免您的域与数据映射层(或只是称之为数据层)紧密耦合,这偶尔依赖于所选的基础数据技术。
虽然你可能觉得这在你的具体用例中是无用的,但我会尝试用一个非常简单的论点来说服你:数据访问细节将在你的仓库中强制执行,这意味着你的数据策略将在那里自包含。换句话说:您的域将与数据访问方法无关,并且如果您将来需要更改它,则无需更改成千上万的代码行。
结论:即使在您的场景中,存储库模式也很有用。让您的域名代码只解决域名问题,而不是将所有内容混合在一个真正的意大利面条代码中!
控制反转故事...
当存储库模式遇到控制反转时,一切都会变得更加强大,因为您可以通过配置切换域转换为数据的方式,并且您可以强制执行更松散的耦合和关注点分离。
击败这个;)
不使用 EF 似乎是错误的。EF 将是在很大程度上抽象数据库的存储库。您希望能够面向不同的数据库产品。EF擅长于此。
引入实体框架来解决问题。