不同层中的 Web API 2答案

【问题标题】：Web API 2 in distinct layer不同层中的 Web API 2
【发布时间】：2014-12-02 01:45:46
【问题描述】：

我正处于 Web 应用的规划阶段，希望得到一些建议。

我在不同的层中绘制了 DAL 和 Web MVC 5，我知道这个项目需要与其他系统进行一些集成。

我的问题是：

应该在 DAL 和 Web MVC 5 之间创建一个 Web API 2 层吗？

这里的主要目的是集中数据访问格式并尽量减少未来的维护。

【问题讨论】：

【解决方案1】：

Web API 和 Web MVC 层都是逻辑表示层的一部分，通常它们彼此相邻且不会混合。这只是我想到的方法的一些缺点：

性能 - Web MVC 项目中的冗余 HTTP 往返。
关注点分离 - 大多数情况下，API 提供的功能与同一项目/应用程序的 UI 有很大不同。您可能希望将 API 限制为一些具有严格约定的方法。如果您希望 Web API 成为 Web MVC 和 DAL 之间的一层，您还必须公开 UI 所需的所有功能。此外，您可能希望拥有不同的授权和身份验证机制。 API 异常处理和输入验证通常也不同。
维护 - 每次您需要对 UI 进行必要的更改时，您必须确保它不会影响您的 API 客户端。此外，API 版本控制也是一个非常重要的主题，将它与大多数 UI 更改混合会使这个过程变得更加困难。

您可以在此处阅读合同版本控制 - Versioning Strategies

如果我是你，我会让 Web API 和 Web MVC 层尽可能地薄，因为它们应该是完美的世界。然后添加一个业务层并在 Web API 和 Web MVC 中使用它。业务层应该封装您想要集中化并减少维护的所有常见逻辑。所以应该是

DAL -> 业务层 -> Web API

和

DAL -> 业务层 -> Web MVC

希望对你有帮助！

【讨论】：

我很难定义什么是我的业务层。我需要一个虚拟的例子:(
我只使用存储过程来操作我的数据和 LINQ to Entities 来选择。
当然。考虑您的应用程序是一个网上商店，当用户下订单时，您应该进行一些查询以确保产品仍然可用，然后将订单保存到 db 并向用户发送带有订单 ID 的电子邮件。所以这三个动作应该放到一个业务层服务中。您可能拥有带有 CreateOrder 方法的 OrderService。然后在此方法中调用 DAL 进行验证查询并保存订单实体。然后应该调用 smpt 服务器来发送电子邮件。这三个动作是业务逻辑，在创建订单时应该始终一起使用
很清楚。我的模型（也是 ViewModel）可以在业务层吗？
不，视图模型应该仅在表示层中，在您的情况下是 Web API 或 Web MVC，并且您应该在 Web API 或 MVC 控制器中的业务实体和视图模型之间进行映射.因此，您可能有 Order 业务实体从您的 CreateOrder 方法返回。然后你有一个视图模型 OrderViewModel。请注意，对于 API 和 UI，您可能有不同的视图模型。然后在 API/MVC 控制器中，您在 Order 和 OrdeViewModel 之间进行映射，并将视图模型传递给视图或作为 Web API 结果。就我个人而言，我更喜欢 Automapper 来做映射的事情。