带有 Web API 的 ASP.Net 应用程序中的架构问题

Question

我们有一个 ASP.Net 应用程序的 3 层架构，它使用 SQL 后端构建并在生产环境中运行了 2 年。

现在我们计划通过 Web-API 公开数据来开始开发该应用程序的第 2 版。因此，我们正忙于为该架构实现创建 POC。

问题是，我们有一个包含 3 个项目（ASP.NET+BAL+DAL）的现有解决方案。因此，我计划用 Web-API 替换 DAL，因为它本身包含与后端数据库交互的模型。 我为 Web-API 创建了一个单独的解决方案。在我的 POC 中，Web-API 在单独的端口(ex:localhost:122) 中运行，而我的 ASP.NET 应用程序在默认端口(ex:localhost:80) 中运行。在我的 ASP.NET 应用程序中，当我调用 Web-API 控制器时，它没有返回结果。但是在检查像 "http://localhost:122/api/Products" 这样的 Web-API 时，我得到了响应。

在看到来自谷歌的示例架构时，人们在主要（ASP.NET+BAL+ServiceLayer）解决方案中引入“服务层”并继续调用该服务层将在内部调用原始（withich 与 DB 连接）Web-API .这是唯一的方法吗？

如果我的假设是错误的，请纠正我。

Answer 1

在公开 Web API 时，最好将其视为替代 UI。碰巧它是一个非常丑陋的 UI（可能是 JSON 或 XML）。而且对于普通用户来说不是很实用，因为他们必须手动构建请求等。

3 层架构是为多个前端保留 BAL 和 DAL。 Web API 是一个备用前端。因此，最好在新进程（Web API）中引用 BAL 和 DAL，然后将其公开。

我不确定这是否与“服务层”相同。这个词对不同的人有很多不同的含义。

所以，我不会用 Web API 替换 DAL（因为它有模型等）。相反，使用 Web API 模型（或视图模型）来定义备用前端结构并从现有 BAL 服务和实体映射到这些结构。

希望这会有所帮助。