Web APIの呼び出しと、基になるDLLへの参照の追加
これは、アーキテクチャの問題の詳細であり、私はアプローチのすべての可能な長所と短所を知りたいです。
私の組織では、ASP.NETアプリケーションが「A」、Web APIプロジェクトが「W」、基礎となるDLLが「D」と言っており、物理的に異なるサーバー上にある「E」を呼び出します。
ほとんどの場合（SPA内）、AからWへのajax呼び出しを行って、Dにある基本的な機能にアクセスします。
AとWは両方とも、異なるアプリケーションとして同じWebサーバーに配置およびホストされ、WはDを参照しているため、DはWと共に配置されます。
機能の1つでは、一部のサーバー側の処理をASPXページのコードビハインドで行う必要があります。
私は、httpクライアントを使用してAからWに呼び出しを続け、アプリケーションAとdll Dの間の疎結合を維持することをチームに提案していますが、多く（私は私のチームの他の全員）が参照を追加することを支持していますDからAに変更されたため、DはAとともに配置されます。
私の提案は、AのDへの直接参照を追加することで得られる実装の容易さを提供するのにあまりよくありませんか？説明が不十分な場合はお知らせください。
Web APIを使用すると、具体的な実装ではなく、インターフェイスにプログラミングできます。
（たとえば）請求書を生成する必要がありますか？ Web APIメソッドを呼び出して、その請求書を生成するだけです。今後、請求処理の方法を変更する必要が生じた場合は、インターフェースの背後にあるコードを変更するだけで済みます（または、完全に異なる請求方法にまとめて交換することもできます）。
フロントエンドをDLLに密結合すると、必要のない依存関係が発生します。これは、アプリケーションとDLL =更新する必要があります。WebAPIを使用すると、フロントエンドアプリケーションをリファクタリングすることなく、アプリケーションのビジネスロジックを変更できます。
カップリングに関してはほとんど違いがないようです。 WebAPIに対して直接コーディングしている場合、そのインターフェースに依存しています。 DLLに対して直接コーディングする場合、itsインターフェースに依存しています。
区別を無意味にしてください。アプリケーションは、最終的にWebサービス、ローカルサービス、またはローカルライブラリを利用しているかどうかを知る必要も、気にする必要もありません-あるいは、基盤となる機能が構築されている言語やテクノロジーですらあります。お好みのタイプの ラッパー を選択し、reallyアプリケーションをbothAPIおよびDLL。両方のラッパーを構築（または拡張）し、パフォーマンス、保守性などについて両方をテストできます。
分散オブジェクト設計の私の第一法則：オブジェクトを配布しないでください
必要なビジネスロジックがDLL内にある場合に、Webサービスのオーバーヘッドと不安定さを招くのはなぜですか。 DLLを参照し、すべてのメソッド呼び出しをローカル、迅速かつ安定した状態に保ちます。
.NET以外の言語でWebサイトを作成している場合は、Webサービスを使用することをお勧めしますが、これは当てはまりません。
DLLコードベースにアクセスできなかった場合でも、内部のNugetパッケージサーバーを立ち上げ、Nugetを使用してその依存関係を管理できます。
Webサービスに必要な追加のビジネスロジックがある場合は、それを使用します。そうでない場合は、DLLを使用します。