21

簡単な Web アプリを作成しようとしていますが、ASP.NET MVC 4 の新機能を使用する必要があるかどうか疑問に思っていますWeb API。

これを行う最良の方法は何ですか?

いくつかの調査を行ったところ、次の 2 つのオプションがあることがわかりました。

Option 1

Web Api をサービス レイヤーにし、コントローラーから呼び出してデータの読み取り/書き込みを行い、ビュー モデルと Razor を使用してビューをレンダリングします。

Option 2

Web Api をサービス レイヤーにして、Javascript を使用してビューから直接呼び出します。

Option 2ページ間のリダイレクトにのみ使用されるコントローラーを無視しているように感じるので、私はの大ファンではありません。また、Javascript よりもカミソリを使用することを好みます。

また、選択Option 1した場合、コントローラーで 1 つの Web API のインスタンスを作成する必要がありますか? これは私が何か間違ったことをしているように感じるからです。

最良の選択肢は何ですか? 私が考慮していない他のオプションはありますか？

また、参考になる本や本を教えていただけると助かります。

ありがとう。

4

2 に答える 2

19

通常、ビジネス ルール用に別のレイヤー (アプリケーションのサイズと複雑さに応じて、別のプロジェクト/アセンブリになる可能性があります) があります。このビジネス サービスを呼び出すことができます。

したがって、MVC コントローラーとAPI コントローラーの両方がこのレイヤーを使用します。アプリケーションをドライに保ちます。

個人的には、ビジネス レイヤーに複雑な操作のみを保持することを好みます。つまり、パーシスタンス レイヤーから何かを読み取ってビューに表示する必要がある場合は、MVC コントローラーで直接実行します。これは個人的な好みの問題ですが、私はCQRSの方法を好みます。

したがって、MVC コントローラーはこれらのビジネス サービスをインスタンス化します (または、IoC を使用している場合はコントローラーに注入されます)。読み取り操作の場合、永続化レイヤーに直接移動するか、別の読み取り戦略を使用するかを選択できます。

API コントローラーにも同じことが起こり、この「共通」サービス層を使用します。

MVC コントローラーで API コントローラーをインスタンス化する必要はありません。SPA などを開発している場合は、AJAX 経由で Web Api コントローラーを使用しても問題ありません。

アプリケーションを構築する方法は 1 つではありません。さまざまな方法があり、どの方法にも多かれ少なかれ問題が伴います。

アプリケーションにテストを導入することを検討している場合 (そうするべきです :)); 次に、各部分を簡単にテストできるように構造化する必要があります。

ちょうど私の2セント。

于 2013-04-14T13:10:13.807 に答える
5

Web API の要点は、ステートレスな RESTful サービスになることです。あなたがそれを正しく行っていれば、その例は決してありません。この質問は古いものであり、個人的にこれを学んだかもしれませんが、よくある質問への回答であるため、回答はそれほど多くありません.

Web API について話すとき、多くの場合、ルートを取得してビューに変換する基本的な MVC「コントローラー」ではなく、ApiController について話していることに注意してください。

したがって、プロジェクトには、いくつかの基本的なビュー ロジックを実行するが、ビジネス ロジックを実行しない「コントローラー」がいくつかある場合があります。これを、ビジネス ロジックおよび永続アクセスのラッパーであるサービス レイヤーと混同しないでください。

私と多くの人は、ApiControllers を MVC アプリケーションと混在させるべきではないと考えています。MVC は Web API とうまく組み合わせられないことに注意してください。フィリップ W が言うように:

Web API と MVC で使用される概念の多くは、一見似ていますが、実際には互換性がありません。たとえば、Web API 属性は System.Web.Http.Filters.Filter であり、MVC 属性は System.Web.Mvc.Filter であり、これらは交換可能ではありません。

最も柔軟な答え

そこで、api.YourWebsite.com という名前のサブドメインを作成し、そこに新しい Web API ApiController プロジェクトを構築します。その Web API プロジェクトは、ApiControllers と Dependency Injection を介してビジネス ロジックをインスタンス化して公開する以上のことを行うべきではありません。

代替案 1

サービス指向アーキテクチャは再利用性がすべてです。アプリケーションを DRY に保ちたい場合は、間違いなく SOA に移行する必要があります。とはいえ、すべての状況は異なります。この Web サイトの同じビジネス ロジックを他のアプリケーション (デスクトップ、Android、タブレット、ewPhones など) で使用することがない場合は、別の方法があります。

Busines Logic Layer を別のプロジェクトとして作成し、Web アプリから直接アクセスします。Javascript (Angular/Razor?) コントローラーが呼び出しを行うと、ViewModel や Codebehind などを呼び出すことができ、ビジネス ロジックをインスタンス化して直接アクセスできます。すべてがそこにあり、再利用されない場合、サービスは必要ありません。

代替案 2

Web API ApiControllers を同じプロジェクトに配置してください。ただし、MVC の「コントローラー」とは別のフォルダーに分けてください。それでも、Javascript コントローラーが呼び出しを行うときは、ステートレス リターンのために Web サイトへのルーティング呼び出しを行います。ステートレス ApiController を ViewModel やその他の MVC コードと混在させないでください。

これの欠点は、SOC の欠如です。これで、Service-Layer と UI-Layer が混在し、UI-Layer は Business Logic Layer (DLL) に強制的にアクセスするようになりました。オルタナティブ 1 がそれ​​を行った場合、何が問題なのですか?

問題は、Alternative 1 が小さなアプリケーションであり、成長の余地がなかったことです。他のもの (元の計画、またはここでは代替案 2) には、ビジネス ロジック (または永続性) が存在することすらまったく知らない UI が必要です。彼らは、バックエンドの世界に気づかずに、自分のやっかいなことに取り組まなければなりません。

于 2014-10-31T19:25:51.053 に答える