DB与前端之间独立API访问层架构

Question

我最近听说有一家公司在结构非常糟糕的 SQL Server 和它们的前端之间使用了一种令人惊讶的独立/独立 API（访问层）架构模式，这样就不会在任何地方使用任何实体框架以及与前端的数据库没有直接交互。

我以前从未在 .Net Core/Framework 环境中看到过这种情况，并且遇到了一种石膏类型的情况，他们试图抽象出糟糕的数据库结构并通过 API 向消费者隐藏它，而不是修复核心问题，就是糟糕的数据库。

这是否被认为是一种实际的架构模式或最佳实践（在这种情况下甚至可能？）还是只是一团糟？开发团队似乎对这种新的 API 模式持坚定态度...

Answer 1

从数据库中抽象出前端是标准做法。抽象层使渲染数据传输对象与数据库中的实体模型大不相同。这个绝缘层为试图访问数据的参与者提供了一套标准，并将业务逻辑封装在一个中心位置。这是一个明智的决定。随着数据库标准的提高，可以在不影响前端的情况下更新对数据库的 API 调用。因此，前端开发人员不必为示意图数据库更改而烦恼。实体框架不是 c# 项目与数据库通信的先决条件或共同条件。那里有许多 ORM 库，有些堆栈甚至没有利用其中一个。虽然 EF 功能强大，但如果数据库一团糟，最好推迟任何 ORM 的实现，直到数据和架构得到充分整理。