Erlang gen_server vsステートレスモジュール

Question

最近、ジョーの本を完成させて、とても楽しんでいます。 それ以来、erlangを使用してソフトリアルタイムアプリケーションのコーディングを開始しました。gen_serverの使用について少し混乱していると言わざるを得ません。

単純なステートレスモジュールの代わりにgen_serverを使用する場合 ステートレスモジュールを次のように定義します。 -内部で（gen_serverなど）保持するのではなく、その状態をパラメーターとして（ETS / DETSに似た）取るモジュール

請求書マネージャーのタイプモジュールの場合、初期化してから状態を返す必要があります。その後、この状態を渡します SomeState = InvoiceManager：Init（）、 SomeState = InvoiceManager：AddInvoice（SomeState、AnInvoiceFoo）。

請求書管理者の状態の複数のインスタンスが必要だと仮定します（私のアプリケーションが複数の会社をそれぞれ独自の請求書で管理している場合など）。上記のステートレスモジュールですか？

2つの間の線はどこですか？

（上記の請求書管理の例はそれだけで、私の質問を説明する例です）

Answer 1

それは、ニーズとアプリケーション設計に強く依存します。プロセス間で状態を共有する必要がある場合、プロセスを使用してこの状態を維持する必要があります。 gen_server 、 gen_fsm 、またはその他の gen _ * があなたの友達です。アプリケーションが同時実行されていない場合、またはこの設計が他の利点をもたらさない場合、この設計を回避できます。たとえば、アプリケーションをプロセスに分割すると、設計が簡単になります。他の場合では、単一プロセス設計を選択し、「ステートレス」を使用することができます。パフォーマンスなどのモジュール。 ＆quot;ステートレス＆quot;モジュールは、非常に単純なステートレス（純粋な機能）タスクに最適です。 gen_server は、多くの場合、自然に「プロセス」と思われる思考に最適です。プロセス間で何かを共有したい場合に使用する必要があります（プロセスの使用は、スケーラビリティまたは同時実行性によって制約される可能性があります）。

Answer 2

ステートレスモジュールと呼ばれるものとgen_serverを区別できるとは思いません。どちらの場合も、少なくとも1つの引数で状態を運ぶ再帰的な受信ループがあります。このメインループは要求を処理し、要求に応じて機能し、必要に応じて結果を要求者に送り返します。メインループは、メインAPI /プロトコルの一部ではない可能性のある多くの管理要求も同様に処理します。

違いは、gen_serverがメイン受信ループを抽象化し、ユーザーが実際のユーザーコードのみを書くことを許可することです。また、多くの管理OTP機能も処理します。主な違いは、ユーザーコードが別のモジュールにあることです。つまり、パススルー状態をより簡単に見ることができます。実際に1つの大きな受信ループでコードを記述し、他の関数を呼び出して作業を行わない限り、実際の違いはありません。

どちらの方法が良いかは、必要なものに大きく依存します。 gen_serverを使用すると、コードが簡素化され、「無料」機能が追加されます。しかし、より制限的です。自分で転がすとより多くのパワーが得られますが、物事をねじ込む可能性も増えます。それもおそらく少し高速です。何が必要ですか？

Answer 3

両方のモデルを使用しているので、提供されているgen_serverを使用すると、構造を簡単に保つことができます。これがツールのOTPスタックに含まれている理由だと思います：gen_serverは、繰り返しボイラープレートを邪魔にならないようにする良い方法です。

Answer 4

複数のプロセスにわたって状態を共有している場合は、おそらくgen_serverを使用する必要があります。状態が1つのプロセスに対してローカルである場合は、ステートレスモジュールで問題ありません。

Answer 5

請求書（またはそれらが表すもの）は永続的である必要があるため、とにかくETS / Mnesiaテーブルになります。その場合は、請求書テーブルにアクセスするためのAPIを配置するステートレスモジュールを作成する必要があります。