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

Question

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

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

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

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

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

Answer 1

在公开Web API时，最好将其视为备用UI。碰巧它是一个非常丑陋的用户界面（可能是JSON或XML）。普通用户并不能使用它，因为他们必须手工构建请求等。

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

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

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

希望这会有所帮助。