14
您是否应该将后端编写为API？
今天，我对我们的MVC应用程序进行了热烈的讨论。我们有一个用MVC（ASP.NET）编写的网站，它通常遵循在视图中执行某些操作的模式->击中控制器->控制器构建模型（调用获取数据的Manager，在该模型中构建模型控制器方法本身）->模型去查看->冲洗并重复。 他说我们的代码太紧密了。例如，如果我们还需要桌面应用程序，则将无法使用现有代码。 他说的解决方案和最佳实践是构建一个API，然后在您的API之上构建您的网站，然后构建一个桌面应用程序，移动应用程序等非常简单。 由于种种原因，这对我来说似乎是个坏主意。 无论如何，我似乎无法通过谷歌搜索找到任何讨论这种做法的东西。是否有人对优缺点有任何了解，为什么要这样做，为什么不应该这样做或需要进一步阅读？ 我认为这是一个坏主意的一些原因： 太抽象了，无法通过API运行后端。您正在尝试使其过于灵活，这将使其变得难以处理。 MVC中内置的所有内容似乎都无用，例如角色和身份验证。例如，[授权]属性和安全性；您将不得不自己动手。 您的所有API调用都需要附加安全信息，并且您将必须开发令牌系统等等。 您将必须为程序将要执行的每个功能编写完整的API调用。您几乎要实现的每种方法都需要使用API。每个用户的Get / Update / Delete，以及每个其他操作的变体，例如更新用户名，将用户添加到组等，等等，每个将是一个不同的API调用。 当涉及到API时，您会丢失各种工具，例如接口和抽象类。WCF之类的东西对接口的支持非常微弱。 您有一个创建用户或执行某些任务的方法。如果要创建50个用户，则只需调用50次即可。当您决定将此方法用作API时，本地Web服务器可以命名管道连接到它，也没有问题-您的桌面客户端也可以访问它，但是突然间，您的批量用户创建将涉及在Internet上锤击该API 50次，不好 因此，您必须创建一个批量方法，但实际上您只是在为桌面客户端创建它。这样，您最终不得不a）根据与其集成的API修改API，而不能直接与其进行集成，b）做更多的工作来创建一个额外的功能。 YAGNI。除非您专门计划编写两个功能相同的应用程序，例如一个Web和一个Windows应用程序，否则这将是大量的额外开发工作。 当您无法端对端进行调试时，调试会困难得多。 许多独立的操作将需要大量的来回操作，例如，某些代码可能会吸引当前用户，检查该用户是否具有管理员角色，获取该用户所属的公司，获取其他成员的列表，并将其全部发送出去一封电邮。这将需要大量的API调用，或者为您想要的特定任务编写定制方法，而该定制方法的唯一好处是速度快，但缺点是不灵活。 可能还有其他一些原因，这些都不在我脑海中。 在我看来，除非您真的需要两个相同的应用程序，否则确实不值得。我也从未见过这样构建的ASP.NET应用程序，您必须编写两个单独的应用程序（API和您的代码），并同时对它们进行版本控制（如果您的用户页面有一个新字段，则d必须同时更新API和您使用的代码，以确保不会产生不良影响，或进行大量额外的工作以保持其健壮性）。 编辑：一些不错的回应，现在真的开始对这一切意味着什么有了一个好主意。因此，为了扩展我的问题，您将如何构建一个MVC应用程序以遵循此API结构？ 例如，您有一个显示有关用户信息的网站。在MVC下，您可以： 视图-（CS）HTML页面，其中显示一个UserViewModel控制器-调用GetUser（）并创建一个UserViewModel，并将其传递给具有GetUser方法的视图管理器类（与您的API相似）。 控制器执行GetUser（），但您也需要桌面应用程序。这意味着您的GetUser需要通过某种API公开。您可能需要TCP连接，或者是WCF，或者可能是Remoting。您还需要一个将是RESTful的移动应用程序，因为持久性连接不稳定。 那么，您是否会为每个API编写一个API，一个具有方法GetUser（）的WCF Web服务，而代码恰好return new UserManager().GetUser()呢？和做同样事情的MVC 4 Web API方法呢？在继续直接在您的MVC控制器方法中调用GetUser时？ 还是您会选择适用于所有三个应用程序的解决方案（Web api REST服务）并在其上构建所有内容，因此所有三个应用程序都进行API调用（对本地计算机的mvc调用）。 这仅仅是理论上的完美场景吗？我可以看到以这种方式进行开发的开销很大，尤其是如果您必须以一种允许您以RESTful方式进行操作的方式进行开发时。我认为其中一些已包含在答复中。 编辑2：在阅读更多内容之后，我在下面提出了一条评论，我认为这可能会解释它。我认为这个问题有点棘手。如果您将后端编写为API，让我感到困惑，我认为应该有一个单一的Web服务，所有东西（MVC应用程序，桌面应用程序，移动应用程序）都可以调用来完成工作。 我得出的结论是，您真正应该做的是确保业务逻辑层正确分离。查看我的代码，我已经这样做了-控制器将调用GetUser()管理器，然后从中创建一个视图模型以使用View进行渲染。因此，实际上，业务逻辑层是一个API。但是，如果要从桌面应用程序调用它，则需要编写WCF服务之类的内容以方便调用它。即使仅调用GetUser()一个包含代码的WCF方法return MyBusinessLayer.GetUser()就足够了。因此，API是业务逻辑，而WCF / Web api等只是让外部应用程序调用它的一小部分代码。 因此存在一些开销，因为您必须根据需要将业务逻辑层包装在不同的API中，并且必须为希望其他应用程序执行的每个操作编写API方法，此外，您还需要找出一种进行身份验证的方法，但在大多数情况下是相同的。将您的业务逻辑放在一个单独的项目（类库）中，您可能不会有任何问题！ 希望这种解释是正确的。感谢它产生的所有讨论/评论。
322
mvc
asp.net-mvc
api-design