algorithm - 为我的非 HTTP 业务逻辑实现中间件设计是个好主意吗？

Question

我们大多数人现在已经习惯了最近实现的 HTTP 中间件，从 node.js 生态系统开始。我们还有一些业务逻辑（在应用程序扩展的单独业务逻辑库中）可以非常分层。这更像是一个操作队列（代码中的服务），它响应给整个组件的外部消息，FILO样式。

伪代码会这样写：

inviteFriendsOperation = createFIFOQueue(message)
inviteFriendsOperation.add(PrepareFriendsList)
inviteFriendsOperation.add(RemoveFamily)
inviteFriendsOperation.add(SendMobilePush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendWebPush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendEmail { here, message.friendList only contains those who failed for mobile and web push})
updatedMessage = inviteFriendsOperation.run()

print updatedMessage.successfulMobilePushes
print updatedMessage.successfulWebPushes
print updatedMessage.successfulEmails
print updatedMessage.friendList

因此，我们将创建一个对象队列，这些对象执行message发送到队列的操作和更新。它以 的顺序开始运行add，到达SendEmail，然后返回到结束于 的第一个操作PrepareFriendsList。它最终返回更新message的作为整个操作的结果。

message将有一个强大的应用界面，因此误解将被最小化。

除了 HTTP 中间件，我还没有看到这种模式经常应用，当我研究时，我发现了系统架构模式的结果，而不是代码。

这是一个好方法吗？你能指点我一些例子/论文/文章吗？

标签： algorithmdesign-patternsmiddleware

Answer 1

'Middleware like'模式在您的情况下可能很有用。中间件这个词非常广泛。大多数时候，您会发现它在分布式应用程序的上下文中使用。在 Web 应用程序的上下文中，Web 框架使用该模式来管理响应和请求对象。

我不会更详细地描述中间件是什么，但这里有一些其他有用的设计模式。这些模式不仅像中间件，而且试图解决类似的问题。通常，解决用例的模式不止一种。

• 责任链
• 拦截过滤器模式

我已经看到，通常在代码级别，这些模式与中间件具有相似的功能。如果您能找到更多示例，也许可以检查它们。

我不确定您的用例和基础架构，但通常会出现的一个问题是步骤之间的错误处理。