認証と一般的なユーザーの詳細のフェッチに共通の dll を使用する複数の Web サイトがあるシナリオがあります。
ここで、共通の dll を少し異なるログイン ロジックで更新する必要があります。つまり、この新しい dll をすべての Web サイトにプッシュし、それぞれのリリース プロセスを実行する必要があります。
ある種の Web サービスで一般的な認証方法をホストしてから、Web サイトがそれを内部的に呼び出す方がよいかどうか疑問に思っています。内部 Web サービスでしょうか。サーバー側のみのWebサイトからのajaxコールバック? それとも、コードの変更によってサイトが壊れないように dll メソッドを使用しますか?
この種のタスクに dll を使用しない場合、セキュリティ上の懸念はありますか?
そのためには、Web サービスを使用するのがよい方法のようです。メモリ使用量が少なくなり、Web サイトから独立して更新できます (必要な場合)。
おそらくWCFサービス（デュアルtcpを使用？）に行くことができます。
私の意見では、どちらのアプローチも機能しますが、覚えておくべき重要な違いがあります。
まず第一に、これはすべて、使用している言語にも依存します。なぜなら、最良の理論的答えが、すべての言語で必ずしも簡単に実装できるとは限らず、実際には使用できない場合があるからです。
したがって、これを念頭に置いて、私にとって最善の方法は、すべての Web サイトが同じ DB (またはデータ層) を使用すると仮定して、この「認証および一般的なユーザー詳細モジュール」に関するすべての要求を処理する内部 Web サービスを用意することです (そうしないと、それぞれに対して Web サービスを作成する必要があり、まったく別の話になります)。このアプローチにより、柔軟性と保守性が向上します。この Web サービスへの直接の ajax 要求を使用するか、Web サイト サーバーから呼び出しを行うことができ、それらは既にその情報を使用してブラウザーに応答します。(この 2 番目のオプションは時間がかかりますが、はるかに安全です。実際の内部 Web サービス (つまり、同じマシンでホストされている場合) の場合、ラグは目立ちません)。
同じビジネス ロジックを異なるサービスに適用する必要がある場合は、dll アプローチを使用する必要があります。実際には、同じ種類の認証ロジックを使用する 2 つの完全に分離された Web サイトがあります。同じデータ層を使用する Web サイトに対してこのアプローチを使用すると、ほとんどの場合、すべての Web サイトで dll を更新している間、新しい実装と連携する「非推奨の方法」が必要になることに注意してください。
よろしく、