你能构建一个 RESTful 业务逻辑层吗？

Question

我已经为我的架构的数据访问层 (DAL) 构建了一个 RESTful 服务：

POST http://example.com/data/User
GET|PUT|DELETE http://example.com/data/User/{UserId}

但是，对于业务逻辑层 (BLL)，使用了第二个非 RESTful 服务：

POST http://example.com/accountapi/register
POST http://example.com/accountapi/login

此 BLL 服务不调用 DAL 服务，而是直接与数据库对话。

您将如何改进此架构？

1. BLL 服务是否应该调用 DAL 服务？
2. 我应该放弃 DAL 服务，只公开 BLL 服务吗？
3. 我是否应该以某种方式在我的 RESTful DAL 服务中注入业务逻辑？如果是，如何？

Answer 1

回答主要问题。不，不是。回答次要问题。以上都不是。

基于 REST 的架构不能很好地适应标准的 3 层模型。三层模型的简化视图如下所示：

表示层 业务 逻辑层 数据层

考虑一下将表示层分成两部分，

渲染层 用户界面 内容 BLL DAL

如果您考虑一个常规的 Web 应用程序，浏览器会获取 HTML、CSS 和 Javascript 内容并在浏览器中以可视方式呈现它们。 REST 约束适用于用户界面内容层。如果您考虑超媒体约束，这一点最为明显。 REST 界面意味着可以像用户界面一样进行导航。 REST 接口返回资源的重新表示。

REST 接口应返回独立于用户界面显示方式的用户界面内容。

REST 客户端 REST 接口 BLL DAL

在我看来，REST 客户端有两种形式，一种是非常薄的媒体类型渲染引擎（例如 Web 浏览器），另一种是屏幕抓取工具（蜘蛛、混搭）。我松散地使用“屏幕抓取工具”一词，因为如果您明智地选择媒体类型，客户端从您的用户界面内容中抓取数据应该是微不足道的。

任何将业务逻辑层公开为 REST 接口的尝试通常都会产生一些影响。开发人员最终会询问如何在 REST 中进行事务。由于需要公开语义丰富的表示，它们最终在客户端和 BLL 接口之间创建了大量的耦合。他们忘记了超媒体约束，因为大部分链接信息在业务逻辑层中不可用。他们开始抱怨 HTTP 和基于文本的内容类型的性能开销。

Answer 2

(1) 避免让您的（非 REST）Web 服务业务逻辑层向数据访问层发出进一步的（RESTful）HTTP 请求。这样做当然比直接调用方法效率低。但更重要的是，它需要您将 BLL Web 服务和 DAL Web 服务部署到单独的 Web 服务器实例（或单独的集群）上。否则，您可能会遇到 所有 HTTP 工作线程忙于尝试提供 BLL 响应的情况，并且每个都被阻塞等待空闲的 HTTP 工作线程为其提供 DAL 响应。这可能会导致停顿（如果您进行超时/重试处理）或彻底死锁（如果您不这样做）。

（2 和 3）如果您的 Web 服务客户端需要业务逻辑和数据访问，请将它们作为一组统一的服务提供。在内部，它们都依赖于相同的数据访问层方法调用：只是面向数据的 Web 服务实现只进行一次数据访问层调用，而面向业务逻辑的 Web 服务实现可能会进行许多 DAL 调用。不过，您肯定希望在 Web 服务层下方分别构建 BLL 和 DAL 层。

我喜欢将 Web 服务视为面向恰好是其他程序的“用户”的表示层的一部分。

Answer 3

1. 如果这是同一个应用程序，那么您应该让 BLL 层直接在代码中调用 DAL 层，而不是再次使用服务调用。这将在保持代码的基本目的独立（高内聚）的同时保持更高的性能。

2. 可能是这样。您的服务通常应该是执行业务功能的课程粒度组件。在数据库中保存用户不是业务功能，它是一个特定的实现。 Register 函数将该概念抽象为业务函数。然后，BLL 层可以强制执行密码强度、密码加密、用户名的唯一性等与数据访问没有直接关系的事情。

3. 可能不会。见#2。