基于REST的MVC站点和/或WCF

本文关键字：WCF 站点 REST MVC 基于 | 更新日期: 2023-09-27 18:22:04

我知道实际上有很多问题与此类似，但我找不到一个能准确回答我问题的问题。

我正在构建一个将

  • 明显地向用户显示数据：）
  • 有一个供经过身份验证的用户使用的公共API
  • 稍后移植到移动设备

所以，我被设计卡住了。我打算在网站上使用asp.net MVC，但我不确定之后如何构建我的架构。

我应该：

  • 使网站RESTful并充当API
    • 在我的初步审查中，GET返回完整视图，而不仅仅是数据，这在我看来似乎扼杀了公共API的想法
    • 此外，我真的应该在控制器中执行业务逻辑吗？为了能够扩展，在另一台服务器上有一个单独的业务逻辑层不是更好吗？或者我会考虑把我的MVC站点推到另一台主机上，这样就能解决同样的问题吗？我正在尝试创建一个SOLID设计，因此将其抽象为一个单独的服务似乎也更好（我可以直接调用另一个类，但随后我又回到了可伸缩性的问题上…）
  • 使网站不是RESTful的，并创建网站将使用的RESTful WCF服务
  • 使网站和WCF服务都是restful的，然而这似乎是多余的

我是REST的新手，所以这个问题可能是我的误解。希望我能很好地解释这一点，但如果没有，如果你需要澄清什么，请告诉我。

基于REST的MVC站点和/或WCF

我会在其上创建一个单独的业务逻辑层和一个（restful）WCF层。这将使您的BLL与客户端解耦。您甚至可以让不同的客户端使用相同的API（并不是说您应该或将要使用，但它为您提供了灵活性）。理想情况下，服务层不应返回域实体，而应返回数据传输对象（可以使用Automapper映射），尽管这取决于项目的范围和规格。

将其放在另一台服务器上会使其成为不同的层，层<>层

简单明了从复杂性的角度来看，将网站和API分离是最简单的。它也有点清洁IMO。

然而，如果你决定走这条路，这里有一些技巧可以让同时处理这两个问题的过程变得更容易。（我目前正在做一个个人项目）

  1. 让你的控制器逻辑非常简单。根据你想让它变得坚固的事实判断，你可能已经在做了
  2. 将返回到视图的模型与实际模型分开。我喜欢创建特定于视图的模型，并有一种将模型转换为视图特定模型的方法
  3. 确保您对所有内容都进行了版本化。在相当长的一段时间内，您可能希望允许并支持旧的API请求。。。。尤其是在电话里
  4. 实际上，充分使用REST，而不仅仅是HTTP的另一个名称。大多数实现都忽略了这样一个事实，即在任何类型的响应中，状态都应该与其一起传输（缺少ST）。允许在页面和API响应中自行发现操作。例如，如果允许对资源进行分页，请始终在api或网页中指定。这上面有一个完整的维基百科页面。这极大地帮助了去耦，使您有时可以用最新版本自动更新客户端

现在你的控制器动作可能看起来像这个伪代码

MyAction(param) {
    // Do something with param
    model = foo.baz(param)
    // return result
    if(isAPIRequest) {
       return WhateverResult(model)
    }
    return View(model.AsViewSpecificModel())
}

我一直在玩的一件事是制作我自己类型的ActionResult来处理返回逻辑，这样它就不会在整个项目中重复。

我会为您的网站使用REST服务，因为它不会增加任何显著的开销（假设它们在同一台服务器上），并且会大大简化您的代码库。您可以"吃自己的狗粮"，而不是拥有两个API：一个私有（作为DLL引用）和一个公共。你唯一需要注意的是，确保你不会为了满足自己的需求而改变公共的API，而是在需要时拥有一个单独的私有API。

您可以在MVC站点内使用RestSharp或EasyHttp进行REST调用。

ServiceStack可能会使API任务变得更容易，您可以使用现有的域对象，只需编写一组获取/更新/删除/创建对象的服务，而无需为MVC中的所有内容编写2个操作。

相关文章：