1

通常の CRUD ベースの ASP.NET MVC アプリケーションで Web API を使用する利点はありますか? Web API を使用すると RESTful サービス レイヤーの利点が得られることは理解していますが、サービス レイヤー全体 (および基になるビジネスおよびデータ アクセス レイヤー) を置き換えて、サービスのみを使用してデータベースにアクセスすることは好みません。代わりに、クライアントが SPA やアプリのモバイル バージョンなどの他のアプリケーションをサポートしたい場合に備えて、必要に応じていくつかの機能をサービスとして公開する必要があると思います。

問題は、私の状況で、ほとんどの作業が複雑な html ビューを主に 1 つのアプリケーションに返す一方で、内部操作は主に CRUD になり、一部のビジネス ロジックが完全なサービス レイヤーを使用することに意味があるかどうかです。プロキシを作成する必要があるため、パフォーマンス上の懸念はありますか。この種のアーキテクチャは、スケールアップにおいてどのような利点をもたらしますか? 質問が多すぎます。ただ混乱した。必要性がわかりませんが、何か足りないのでしょうか？

SOA を持つという考えは良いように思えますが、パフォーマンスのマイナス面があるかどうか心配です。

4

2 に答える 2

3

サーバー側の Web サイトのコードで Web API を呼び出すよりも、Web サイトと Web API の間でビジネス ロジック ライブラリを共有する方がはるかに優れたオプションだと思います。

HTTP は、低遅延で独立して進化するコンポーネント向けに最適化されたプロトコルです。同じチームが Web サイトと Web API の両方を制御し、それらが同時に展開され、両方が同じデータ センターにある場合、HTTP を使用して相互に通信する価値はほとんどありません。

Web API を使用して Web サイトにデータを提供しようとする場合に直面するもう 1 つの問題は、データセンターで正常に動作するおしゃべりな Web API を構築する可能性が高いことですが、リモート クライアントがそれを使用しようとすると、パフォーマンスの問題が発生する可能性があります。 .

サード パーティによって消費される Web API を効率的かつ効果的にしたい場合は、Web サイトがアクセスする必要があるドメイン エンティティではなく、ユース ケースを公開するようにビルドする必要があります。

于 2013-10-18T12:19:09.117 に答える
1

WebAPI は、次の 2 つの場合に適しています。

  1. 他のアプリケーションが同じデータにアクセスする必要があり、ビジネス ロジック/データ アクセス ロジックを 1 回だけ記述したい場合。
  2. AJAX 呼び出しをアプリケーションのサーバー側に戻してデータを取得する、ブラウザー側の JavaScript を作成したいと考えています。

#2 については、通常の MVC および JsonResponse ハンドラーも使用できます。私のアプリケーションでは、両方を使用しています。データを返すだけで、モデル オブジェクトを直接シリアル化したい場合は、WebAPI コントローラーをセットアップします。しかし、Razor テンプレートを使用してモデルを実行する必要がある場合は、ビューを文字列にレンダリングできる拡張メソッドがコントローラーにあり、それを JSON オブジェクトで 1 つのプロパティとして返します。成功コード、エラー メッセージ、シリアル化された例外オブジェクトなど、返す必要があるメタデータ。

于 2013-10-17T19:29:14.447 に答える