コマンドラインツール（wget、curl）をラップすることは「良い」習慣ですか？
.NET、特にC＃WPFとASP.Netのバックグラウンドがありますが、今度はさらに多くのgolangとCを使用します。例として、次の状況を考えてみます。
私がプログラムすべきソフトウェアは基本的にデータをアップロードし、GUIを使用してそのアップロードプロセスを提示する必要があります。本番環境で使用される各言語には、通常、（ネットワーク）ストリームI/Oを提供する（外部）クラス/ライブラリがありますが、抽象的な「ネットワークフレームワーク」をプログラムするのはさらに多くの作業が必要です（TCP/IPを使用する必要があることが多いため-ソケットやその他の低レベルのものは、複雑さの大きな原因です[あなたの会社がそのような機能をまだ提供していない場合]）、curlを使用するよりも私のプログラムのニーズに合わせて調整しました。私のプログラムのアップロード機能は、この目的のために十分にテストされ、広く使用され、受け入れられているツールであるcurlをラップすることしかできませんでした。これには、多くのオプションがあります。この「制御の喪失」が大きな欠点であることは知っていますが、curlは、プログラムとこのツールの間の通信インターフェイスとして使用できるデータ出力も提供します。そのような機能を提供する許容可能なライブラリがない場合、プロの製品にカールを使用するのは「合法」ですか？
私の見解：
- 車輪の再発明は悪いことです。それをしないでください。私たちは皆これを知っています。
- コマンドラインツールをラップすることは、常に少し見苦しいことです。有用な統合の欠如、フロー制御の欠如、あらゆる種類の引用地獄について心配する必要があります。
ただし、この場合、完璧な解決策があります。 libcurl を使用するだけです。とにかくcurlの根本を構成しているものであり、コマンドラインツールをラップすることのすべての厄介さを回避することができます。
コマンドラインアプリのラッピングは良くも悪くもありません。それは単なるテクニックです。
代替アプローチを検討すると、「良い」と「悪い」が関係します。 より適切ライブラリが利用可能なときにコマンドライン実行可能ファイルをラップする場合など、「良い」可能性は低くなります。一方、コマンドライン実行可能ファイルをラップすることは、それがあなたがしていることのために利用可能な唯一のツールである場合、まったく問題はありません。
あなたの特定のケースでは、cURLをラップする以外に利用できるオプションが他にあまりないのであれば、私は非常に驚きます。
この機能をソフトウェアに組み込むかどうかという問題だと思います。それがどのように揺れ動いても、機能が必要な場合は、どこかに "カール"が生じることになります。ただし、どちらの方法でも複雑さがあることに注意してください。
「curl」がソフトウェア内にある場合：
次に、自分でコーディングする必要があります。それは面倒ですが、libcurlは、libsが進む限りかなり堅実であり、コードがビルドされている限り、ユーザーが安心して使用できます。
「カール」がソフトウェアの外部にある場合：
そうすれば、コーディング側の方が簡単ですが、非常に現実的な意味で、低レベルのプログラミング作業をシステム管理作業に変換しました。
- ソフトウェアがシステムのカールを検出できることを確認する必要があります。 （異なる環境への展開は複雑になります）
- curlがインストールされていないシステムのユーザーに対処します。 （これがどれほど重要かはターゲットプラットフォームによって異なりますが、まだインストールされていない場合は、インストール方法を人々に知らせる必要があります。）
- （おそらく）curl（または同等のもの）をソフトウェアが見つけられるようにする一般的な構成システムを作成する必要があります。これにより、curlが既に存在するが、指定した方法が失敗した場合にソフトウェアを動作させることができます。適切な設定ファイルの設定がここで役立ちます...
システム管理とさまざまな環境への堅牢な展開は（まっすぐなコーディングのように）複雑になる可能性があるため、私には両方に長所と短所があるように思われます。
あなたの毒を選んでください。