我正在 MVC 中开发一个具有移动应用程序的项目,所以很清楚我们必须使用 Web API,以便它可以在移动应用程序中使用。
在我们开始开发网站的时候创建了 API 之后,我们很困惑,并且讨论过是使用 API 还是直接访问 Business 对象。我们最终得到了更有经验的开发人员的意见,以使用 Web API 而不是直接使用业务对象。
我对此解决方案结构感到困惑。
1)为什么我们应该使用Web API并发出HTTP请求(这很耗时)来获取或放置数据而不是直接在同一解决方案中的业务对象。
2)在争论之后,他们说如果客户想要在不同的云服务器上托管 API 和 Web 并仅在 API 上应用缩放,或者他可能想要有不同的 url 来访问 API 和 Web(这是合乎逻辑的)。那么在这种情况下,我们应该在同一解决方案中从 MVC 应用程序调用 Web API 吗?
3)如果我们在不同的主机上托管 API 和 Web,这意味着我们的 Web 将使用 WebClient 并在每个导航上都有 HTTP 调用。这样对吗?
4) 如果我们将在不同服务器上同时创建 API 和 Web 托管业务对象,那么如果 BL 发生变化,则需要在两台服务器上更新构建。
5)或者我们应该只为API创建一个项目,并且可以添加视图或html页面来开发Web界面,这样我们就可以直接从ajax调用API。
据我所知,#5 是最好的解决方案,或者 API 仅适用于第 3 方访问。如果我们在同一个解决方案中有 DB、EF、数据层和业务层,那么我们不应该使用 API 进行 HTTP 调用并直接访问业务对象。(如果我错了,请纠正我)当移动应用程序或桌面或任何人想要访问应用程序时需要 API,这样我们就可以拥有相同的存储库和数据层。
在我的场景中,我必须创建 API,因为我们也有移动应用程序,在项目 API 方面,我们称为业务层(单独的项目),业务层与数据访问层(单独的项目)进行通信。所以我的问题是,如果我们将 API 和 Web 托管到不同的服务器上,那么调用作为 HTTP 请求的 API 可能需要更长的时间,而不是在我们创建项目时使用来自业务层的方法,并且我们拥有业务层的 .dll。在 API 控制器中,我们只是将我们的业务输出转换为 json 格式。
我在网上搜索过,但没有得到令人信服的答案。我发现了一个博客http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx讨论了同一点但又一次在那个博客中,我的问题是为什么我们需要考虑场景 #3?