设计协议消息的经验法则

时间:2018-04-11 08:00:12

标签: protocol-buffers grpc

我有一个非常简单的音乐播放器,我想把它变成音乐服务器。 我计划使用gRPC在客户端和服务器之间进行通信。 但是,我不确定如何设计协议消息来处理播放。

我设想了两种类型的设计:

  • 每种查询类型的消息。此方法明确定义了所有可能的操作,但似乎创建了大量冗余代码。

    message Play{
        bool flag = 1; // False means Pause
    }
    message Stop{
       bool flag = 1;
    }
    
  • 一条唯一消息,其中包含一个包含该操作的密钥。这种方法似乎更灵活,但也更容易出错。我可以使用枚举对象来限制可能的操作。

    message Playback{
        enum Action {
            PLAY = 0;
            STOP = 1;
        }
        Action action = 1;
    }
    

基本上,我想我在这里问的是我是应该根据消息的类型还是通过内容来定义一个动作。

这里适用经验法则或设计模式吗?

1 个答案:

答案 0 :(得分:1)

我建议在这里使用oneof构造:

syntax = "proto3";

message Play {
}

message Stop {
}

message Command {
    oneof command {
         Play play = 1;
         Stop stop = 2;
         ...
    }
}

当没有您需要传递的参数时,空消息很好,这也为将来扩展消息提供了一种简单的方法,例如将Play更改为:

message Play {
    string filename = 1;
}

允许在请求中包含可选的文件名,同时保留与旧版本的兼容性。