基于 REST 的 MVC 站点和/或 WCF

Question

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

我正在构建一个 Web 应用程序，它将

• 明显地向用户显示数据:)
• 拥有供经过身份验证的用户使用的公共 API
• 以后移植到移动设备上

所以，我坚持设计。我将在网站上使用 asp.net MVC，但是我不确定之后如何构建我的架构。

我应该：

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

我对 REST 还很陌生，所以问题可能是我的误解。希望我能很好地解释这一点，但如果没有，如果您需要任何澄清，请告诉我。

Answer 1

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

把它放在另一台服务器上使它成为不同的层，层 层。

Answer 2

简单明了.... 从复杂性的角度来看，将网站和您的 API 分开是最简单的方法。它也有点更干净 IMO。

但是，如果您决定走这条路，您可以采取以下一些技巧，以使同时处理这两种方法的过程更容易一些。 （我目前正在做一个我正在做的个人项目）

1. 保持你的控制器逻辑相当简单。从您想要使其成为 SOLID 的事实来看，您可能已经在这样做了。
2. 将返回到视图的模型与实际模型分开。我喜欢创建特定于视图的模型，并有办法将模型转换为特定于视图的模型。
3. 确保对所有内容进行版本控制。您可能希望在相当长的一段时间内允许和支持旧的 API 请求......尤其是在手机上。
4. 实际上充分利用 REST 而不仅仅是 HTTP 的另一个名称。大多数实现都忽略了这样一个事实，即在任何类型的响应中，状态都应该随它一起转移（缺少 ST）。允许在页面和 API 响应中自行发现操作。例如，如果您允许在资源中分页，请始终在 api 或网页中指定。有an entire wikipedia page on this。这极大地有助于解耦，让您有时可以使用最新版本自动更新客户端。

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

MyAction(param) {
    // Do something with param
    model = foo.baz(param)

    // return result
    if(isAPIRequest) {
       return WhateverResult(model)
    }
    return View(model.AsViewSpecificModel())
}

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

Answer 3

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

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

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