0

私は、次の責任を持って、go で単純なコネクタ コンポーネントを構築しています。

  1. 外部サービスへの接続を開き、保持し、管理します (つまり、バックグラウンドで実行します)。
  2. 受信データを論理メッセージに解析し、これらのメッセージをビジネス ロジック コンポーネントに渡します。
  3. ビジネス ロジックから外部サービスに論理メッセージを送信します。

go のコネクタのインターフェイスをどのように設計するか決めかねています。

バリアント A) 受信メッセージのチャネル、送信メッセージの関数呼び出し

// Listen for inbound messages.
// Inbound messages are delivered to the provided channel.
func Listen(msg chan *Message) {...}

// Deliver msg to service
func Send(msg *Message) {...}

バリアント B) 受信メッセージと送信メッセージのチャネル

// Listen for inbound messages + send outbound messages.
// Inbound messages are delivered to the provided msgIn channel.
// To send a message, put a message into the msgOut channel. 
func ListenAndSend(msgIn chan *Message, msgOut chan *Message) {...}

バリアント B は、私にはよりクリーンで「よく似ている」ように見えますが、次の回答を探しています。

  • goでこれを行う「慣用的な」方法はありますか？
  • あるいは、どの場合にバリアント A または B を優先する必要がありますか?
  • この種の問題の他の注目すべき変種はありますか?
4

1 に答える 1

3

どちらのアプローチでも、1 つのリスナーしか使用できないため (リスナーの量を追跡しない限り、これはやや脆弱なアプローチです)、これが制限です。それはすべてプログラムの好みに依存しますが、おそらく受信メッセージと送信メソッドのコールバックを使用します。

func OnReceive(func(*Message) bool) // If callback returns false, unregister it.

func Send(*Message)

それ以外は、提案されたモデルは両方とも完全に有効です。2番目はより「直交」しているようです。send メソッドを使用する利点は、 「ベア」チャネルとは対照的に、ブロックされないようにできることです。

于 2013-08-28T16:02:16.090 に答える