首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

在Akka HTTP中传递请求上下文以完成是一种反模式吗?

在Akka HTTP中传递请求上下文以完成是一种反模式。在Akka HTTP中,请求上下文是指包含请求的所有相关信息的数据结构,例如请求头、请求参数、身份验证信息等。传递请求上下文意味着将请求上下文作为参数传递给每个处理请求的函数或方法。

尽管传递请求上下文可以方便地访问请求的相关信息,但这种做法存在一些问题。首先,传递请求上下文会导致代码的冗余,因为每个函数或方法都需要接受请求上下文作为参数。这使得代码难以维护和扩展。

其次,传递请求上下文会增加代码的耦合性。如果请求上下文的结构发生变化,所有使用该上下文的函数或方法都需要进行相应的修改。这使得代码的维护和演进变得困难。

另外,传递请求上下文还会导致代码的可测试性下降。由于每个函数或方法都依赖于请求上下文,测试这些函数或方法时需要提供完整的请求上下文。这增加了测试的复杂性和依赖性。

相反,更好的做法是使用Akka HTTP提供的上下文管理机制,例如使用Akka HTTP的路由器和指令模式。这些机制可以自动将请求上下文传递给处理请求的函数或方法,而无需显式传递参数。这样可以减少代码的冗余和耦合性,并提高代码的可维护性和可测试性。

总结起来,传递请求上下文以完成在Akka HTTP中被认为是一种反模式,因为它会导致代码的冗余、耦合性增加和可测试性下降。相反,应该使用Akka HTTP提供的上下文管理机制来处理请求上下文。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 大数据技术之_19_Spark学习_06_Spark 源码解析小结

    1、spark 一开始使用 akka 作为网络通信框架,spark 2.X 版本以后完全抛弃 akka,而使用 netty 作为新的网络通信框架。 最主要原因:spark 对 akka 没有维护,需要 akka 更新,spark 的发展受到了 akka 的牵制,akka 版本之间无法通信,即 akka 兼容性问题。 2、RpcEnv:RPC 上下文环境,每个 Rpc 端点运行时依赖的上下文环境称之为 RpcEnv。类似于 SparkContext,默认由 NettyRpcEnv 实现,由 NettyRpcEnvFactory 创建 RpcEnv。 3、RpcEndpoint:RPC 端点,Spark 针对于每个节点(Client/Master/Worker)都称之一个 Rpc 端点且都实现 RpcEndpoint 接口,内部根据不同端点的需求,设计不同的消息和不同的业务处理,如果需要发送(询问)则调用 Dispatcher。代理是 RpcEndpointRef。 4、Dispatcher:消息分发器,针对于 RPC 端点需要发送消息或者从远程 RPC 接收到的消息,分发至对应的指令收件箱/发件箱。 5、Inbox:指令消息收件箱,一个本地端点对应一个收件箱,Dispatcher 在每次向 Inbox 存入消息时,都将对应 EndpointData 加入内部待 Receiver Queue 中。 6、OutBox:指令消息发件箱,一个远程端点对应一个发件箱,当消息放入 Outbox 后,紧接着将消息通过 TransportClient 发送出去。 7、TransportClient:Netty 通信客户端,主要负责将相对应的 OutBox 中的数据发送给远程 TransportServer。 8、TransportServer:Netty 通信服务端,主要用于接收远程 RpcEndpoint 发送过来的消息,并把消息传送给 Dispatcher。

    03
    领券