私は現在、次のアーキテクチャに基づいて構築されているプロジェクトに取り組んでいます。
1）最初の解決策
2）2番目の解決策
カスタマーWebポータルとWebAPIは同じサーバー上にあります。WebAPIはデータベースに直接アクセスしていますが、カスタマーWebポータルはWebAPIを介してデータベースにアクセスしています。このアーキテクチャを選択する理由は、Webポータルとスマートフォンアプリが同じWebサービスの85％を呼び出しているため、開発時間を短縮するためです。ただし、これがどれほど優れたパフォーマンスアーキテクチャであるかについては非常に心配しています。カスタマーWebポータルはデータベースに直接アクセスする必要があり、より効率的な方法だと思います。
これについて何か考えはありますか？
アーキテクチャは常にトリッキーであり、開発の速度、保守性、パフォーマンス、スケーラビリティなどのさまざまな要素間の妥協点です。したがって、すべての長所と短所を比較検討する必要があります。
1。確かに、パフォーマンスにいくらかのオーバーヘッドが発生します。しかし、いくらですか？追加のラッパー（WebAPI）を介して呼び出しを渡すと、呼び出しごとに約2〜3ミリ秒の追加コストがかかり、合計で約200MBの追加RAMが必要になるとします。それは本当の問題ではないと思いますが、あなたはすべての詳細をよく知っており、それはあなた次第です。
2。そのソリューションは、キャッシュを使用することでいくつかの利点を得ることができます。要求をWebAPIにキャッシュするようにIISを構成すると、WebAPIクライアントとポータルの両方でパフォーマンスが向上します。
1。理論的には、注意が必要な2つのエントリポイントをDBに導入します。WebAPIクライアントとポータルで使用する必要のあるロジックを追加する必要があり、そのロジックがWeb固有（たとえば、ユーザーセッションに関連するもの）である場合はどうなりますか？DALに追加しないでください。代わりに、WebAPIとポータルの両方で使用される別のライブラリを使用して別のレイヤーを追加する必要があります。また、唯一のアクセスポイントがWebAPIである場合は、WebAPIだけを変更して結果を得ることができます。
それらはほんの一部の賛否両論です。しかし、プロジェクトが大きくない場合、非常に高い負荷がかかることを計画していない場合、私が検討する唯一の要因は開発のコストです。WebAPIを単一のエントリポイントとして使用する方が速い場合は、それを使用してください。