[過去ﾛｸﾞ] ふらっと C#,C♯,C＃（初心者用） Part141 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
349(1): 2020/03/04(水)18:19 ID:yiNVycVp(1/4) AAS
>>325
>通信を行うプログラムと業務用にオペレータからの操作とその他を担うプログラムにわけて作ろうと思っています。
プロセスとかプログラムを分けて作りたい理由って何なの？
書いてる内容だけだとライブラリ化すれば十分なように思えるけど
374(2): 2020/03/04(水)22:20 ID:yiNVycVp(2/4) AAS
>>350
機能が違うからプロセス分けるってのはC#では一般的ではないね
ネットワークI/Oを担当する部分と、業務ロジック/UIを担当する部分で機能は違っても
両方存在しないとユースケースが完結できないのであれば一般的には一つのプログラムにする
通信機能を複数のプログラムで共有したい場合だったり
それぞれのプログラムの起動/停止タイミングの違ったり
耐障害性を考慮したプロセス監視要件が違うケースみたいに
プログラムを分ける必要のある要件があれば別
プロセス分ける必要がなければC#の場合はマルチプロセスに比べて
マルチスレッドのほうが道具も揃ってるしシンプルに作れる
377(1): 2020/03/04(水)22:39 ID:yiNVycVp(3/4) AAS
プロセス間通信は.NET FrameworkならWCFを使うのが一般的だった
(他は.NET RemotingやIpcChannelとか)
ただ.NET Coreだと上の3つはサポートされてないから
標準でとなるとNamed PipeかSocket、あとはHTTPサーバーを立てるくらい
どれ使ってもWCFと違って型付きでデータをやり取りできないので
マーシャル/アンマーシャルは外部ライブラリ使ったりして追加実装する必要がある
ローカル限定ならまずはNamed Pipeから考える
通信用プロセスと業務用プロセスが別のマシンで稼働する可能性があったり
それぞれ別の理由でスケールしていく可能性があるなら
少し大げさだけどRabbitMQみたいなメッセージングも選択肢として検討するかな
380: 2020/03/04(水)23:06 ID:yiNVycVp(4/4) AAS
>>379
gRPCも選択肢としては考えるけど
ローカル限定のプロセス間通信なら大げさすぎる気がするし
リモートも考慮するなら業務プロセスが死んだ時の対応とかで
メッセージングにしといたほうが信頼性が高い
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.639s*