nugetパッケージを作成する場合とWeb APIを作成する場合
開発者は内部アプリケーションを作成しているため、多くの場合、コードを共有する必要があります。これにはさまざまな方法がありますが、通常は、共有サーバー上でnugetパッケージを作成するか、内部でWeb APIをホストすることになります。 2つを決定する決定的な方法はありませんが、現在両方が混在しています。どちらを行うかについての提案/ガイダンスはありますか？
もう少し具体的に... FormatXXX（）、CalculateXXX（）、SendXXX（）などの一般的な使用方法がいくつかあるとしましょう。多くのアプリがその恩恵を受けることができます。これは内部Web APIか、nugetパッケージか？
私たちは.Netショップであり、VS 2017、TFS（gitを使用）を使用しています。主にWebアプリ、Web API、WCFサービス、コマンドラインアプリを構築しています。私たちは常にサードパーティのAPIとやり取りします。
純粋な関数の場合、アプリと同じCPUでコードを実行する必要があります。 nugetパッケージは、そのコードをプロジェクトに取り込む良い方法です。
関数に、グローバルにしたい副作用がある場合。つまり、この関数を実行するたびに、監査ログを生成する必要があります。または、この関数は一度に1つのインスタンスのみを実行し、1日あたりの呼び出しが1000に達したときに停止する必要があります。または、より一般的には、この関数は共通のデータベースにアクセスし、人々がそれを削除しないようにする必要があります。次に、関数の使用方法を制御し、自分でホストする必要があります。コンシューマーが呼び出すためのAPIのみを公開します。
ホストされたAPIの欠点は、サーバーをホストする必要があることです。おそらくフェイルオーバークラスター内にあるため、コストがかかります。さらに、ネットワーク経由での通話の送信が遅くなります。
共有コードソリューションに関する注意：
内部プロジェクトでは、NuGetパッケージの代わりに共有コードを使用することが推奨されています。
これは解決策ですが、nugetの欠点は、コードを使用する各アプリケーションが独自のバージョンのパッケージをビルドすることです。したがって、nugetまたは他のパッケージマネージャーから取得できるバージョン管理、署名、複数のプラットフォームビルドなどの利点を失うことになります。
私はあなたの内部の「顧客」を外部の顧客と同じように扱い、内部と外部のすべてのパッケージをnugetからプルさせることをお勧めします。
プロジェクト、ライブラリ、またはフレームワークを組織外のソフトウェア開発者に公開する必要がある場合は、NuGetを使用してください。*
Web APIが提供する利点が必要な場合は、Web APIを使用してください。通常、これは、何らかのサーバー機能と通信する必要のある複数のソフトウェアフロントエンドがあることを意味します。
それ以外の場合はすべて、共有プロジェクトをソース管理に入れ、開発者が独自のソリューションにプロジェクトを含めることができるようにします。
*堅牢な継続的インテグレーションプログラムをお持ちの場合は、NuGetパッケージを作成して内部で使用することができます。私たちはしばらくの間、これを明らかに混合した結果で行いました。物事を適切に構築することは、常に問題でした。私の意見では、NuGetで正しく実行するにはCIが必要です。
さらに読む
Gitサブモジュール
実行や一部の集中型リソース（データベース、メールサーバーなど）を完全に制御する必要がある場合は、サービスを優先します。リソースが共有されていない場合、超低レイテンシが必要な場合、または稼働時間を約束する/サポートを提供する能力が限られている場合は、ソースを共有することをお勧めします。
いずれにせよ、私は個人的にnot NuGetパッケージを使用して内部でコードを共有します。私は自分のレポを共有して、DLL===== wiki（または共有ドライブなど）をトスします-私のコードを継続的に再コンパイルしたくない消費者のために。