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