タグ付けされた質問 「asp.net-mvc-web-api」

3
同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか?
私はモバイルアプリケーションを持つMVCのプロジェクトに取り組んでいるので、モバイルアプリケーションで使用できるようにWeb APIを使用する必要があることは明らかです。 Webサイトの開発を開始したときにAPIを作成した後、私たちは混乱し、APIを使用するか、ビジネスオブジェクトに直接アクセスするかについて議論しました。そして、ビジネスオブジェクトを直接使用する代わりに、Web APIを使用する経験豊富な開発者の意見を聞いた後、私たちは終わりました。 このソリューション構造に関して混乱が生じています。 1)Web APIを使用し、HTTP要求(時間のかかる)を行って、同じソリューションにあるビジネスオブジェクトの代わりにデータを直接取得または配置する必要がある理由。 2)引数を取得した後、クライアントが別のクラウドサーバーでAPIとWebをホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合(論理的)その場合、同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか? 3)APIとWebを異なるホスティングでホストしている場合、WebはWebClientを使用し、各ナビゲーションでHTTP呼び出しを行います。正しいですか? 4)別のサーバーでAPIとWebホスティングの両方からビジネスオブジェクトを作成する場合、BLで何か変更を加えた場合は、両方のサーバーでビルドを更新する必要があります。 5)または、API用のプロジェクトを1つだけ作成し、ビューまたはhtmlページを追加してWebインターフェースを開発することで、ajaxから直接APIを呼び出すことができます。 私の知る限りでは、#5が最適なソリューションであるか、APIはサードパーティアクセス専用です。同じソリューションにDB、EF、データ層、ビジネス層がある場合、APIを使用してHTTP呼び出しを行ったり、ビジネスオブジェクトに直接アクセスしたりしないでください。(間違っている場合は修正してください)APIは、モバイルアプリケーションやデスクトップ、またはアプリケーションにアクセスしたいときに同じリポジトリとデータレイヤーを持つために必要です。 私のシナリオでは、モバイルアプリケーションもあるため、APIを作成する必要があります。プロジェクトAPI側では、ビジネスレイヤー(別のプロジェクト)と呼ばれ、ビジネスレイヤーはデータアクセスレイヤー(別のプロジェクト)と通信します。したがって、私の質問は、APIとWebを異なるサーバーにホストする場合、プロジェクトを作成してビジネスレイヤーの.dllを作成するときに、ビジネスレイヤーのメソッドを使用するよりも、HTTPリクエストであるAPIの呼び出しに時間がかかる場合があります APIコントローラーでは、ビジネスの出力をJSON形式に変換するだけです。 インターネットで検索しましたが、納得のいく答えが得られませんでした。私はブログ見つけたhttp://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspxを同じポイントを議論したが、再びそのブログで私の質問は、シナリオ#3を検討する必要がある理由です。 更新:異なるAPIプロジェクトとMVCプロジェクトを使用でき、jvascriptを使用してWebからAPIを呼び出すか、MVVMパターンを使用できます。

3
さまざまなAPIバージョンをサポートする方法
私はRest APIを書いていますが、さまざまなバージョンのサポートをどのように処理するのが最善か疑問に思っています。これにより、URIをV2またはV3として定義する方法を意味するのではなく、必要なコードを構成する方法を意味します。 同時に複数のバージョンをサポートします。V1&V2&V3 URIは同時に有効でなければなりません。一度にサポートされる量を制限するためにV4が来るとV1を廃止します。 可能な限りコードの重複を避ける 他のバージョンに影響を与えることなく、簡単な変更をバージョンに簡単に追加できます 取れるアプローチはほとんどないと思われます。 Gitを使用してバージョンを制御し、異なるバージョンのブランチを使用します(古いバージョンでは、基本的に新しい開発作業は行われません)。これは、最新バージョンのみがコードに含まれているため、コードの重複がないことを意味しますが、以前のバージョンは、廃止されるまで新しいバージョンのDBで動作する必要があります。 各バージョンが同じアプリケーションで処理され、完全に別個のコードパスを持つようにコードを複製しますが、これは多くの複製を意味します バージョン間で多くのコードを再利用しますが、1つのバージョンを変更すると以前のバージョンに影響を与える可能性が高くなるため、メンテナンスが難しくなります すべてのオプションには独自の問題があるように見えるため、この問題に対処するためのベストプラクティスはありますか?

2
CQRSは過剰設計ではありませんか?
古き良き時代のリポジトリを今でも覚えています。しかし、リポジトリは時間とともにいものになりました。その後、CQRSが主流になりました。彼らは素晴らしく、新鮮な空気の息吹でした。しかし、最近、コントローラーのアクションメソッド(特にアクション自体が何らかのコマンド/クエリハンドラーであるWeb Api)でロジックを正しく維持しないように何度も自問しています。 以前は、そのための明確な答えがありました。すべてのそれらのモックできないシングルトンと全体的ないASP.NETインフラストラクチャでControllerをテストするのは難しいので、テストのためにそれをしました。しかし、時代は変わっており、ASP.NETインフラストラクチャクラスは、今日では(特にASP.NET Coreで)はるかに単体テストに適しています。 典型的なWebApi呼び出しは次のとおりです。コマンドが追加され、SignalRクライアントに通知されます。 public void AddClient(string clientName) { using (var dataContext = new DataContext()) { var client = new Client() { Name = clientName }; dataContext.Clients.Add(client); dataContext.SaveChanges(); GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client); } } 簡単に単体テスト/モックできます。さらに、OWINのおかげで、ローカルWebApiおよびSignalRサーバーをセットアップし、統合テストを実行できます(ちなみにかなり高速です)。 最近、面倒なコマンド/クエリハンドラを作成するモチベーションが低下し、Web Apiアクションにコードを保持する傾向がありました。ロジックが繰り返されるか、それが本当に複雑で、それを分離したい場合にのみ、例外を作成します。しかし、ここで正しいことをしているかどうかはわかりません。 典型的な最新のASP.NETアプリケーションでロジックを管理するための最も合理的なアプローチは何ですか?コードをコマンドおよびクエリハンドラーに移動するのが妥当なのはいつですか?より良いパターンはありますか? 更新。DDD-liteアプローチに関するこの記事を見つけました。したがって、コードの複雑な部分をコマンド/クエリハンドラに移動するという私のアプローチは、CQRS-liteと呼ばれるようです。

5
Web APIを使用した純粋なフロントエンドJavaScriptとajaxを使用したMVCビュー
これは、最近のWebアプリケーションの分割方法に関する人々の考えについての議論でした。 私は、すべてのビューとコントローラーを備えたMVCアプリケーションの作成に慣れています。通常、完全なビューを作成し、すぐにデータを入力したくない特定の領域がなければ、DOMページ読み込みイベントを使用してサーバーを呼び出して他の領域を読み込む場合を除き、フルページリクエストでこれをブラウザに返します。 AJAXを使用します。 また、ページの部分的な更新については、MVCアクションメソッドを呼び出して、HTMLフラグメントを返します。このメソッドを使用して、ページの一部にデータを入力できます。これは、最初のページの読み込みを遅くしたくないエリアや、AJAX呼び出しに適したエリアに適しています。1つの例は、テーブルページングです。次のページに進みたい場合は、ページ全体の更新を使用するのではなく、AJAX呼び出しがその情報を取得した方がよいでしょう。ただし、AJAX呼び出しはHTMLフラグメントを返します。 私の質問は。私は純粋なフロントエンドの背景ではなく、.netの背景から来ているので、この古風なものに対する私の考えはありますか? 私が一緒に仕事をしているインテリジェントなフロントエンド開発者は、MVCビューで多かれ少なかれ何もしないことを好み、むしろフロントエンドですべてを行います。すぐにWeb API呼び出しがページに入力されます。そのため、HTMLを返すMVCアクションメソッドを呼び出すのではなく、標準オブジェクトを返し、javascriptを使用してページのすべての要素を作成することを好みます。 フロントエンドの開発者の方法は、クライアント側の検証を含む、MVCモデルの検証で通常得られるメリットがなくなることを意味します。また、強く型付けされたhtmlテンプレートなどを使用してビューを作成することで得られる利点がすべてなくなることも意味します。 これは、フロントエンドとバックエンドの検証で同じ検証を記述する必要があることを意味すると考えています。JavaScriptには、DOMのすべての異なる部分を作成するための多くのメソッドも必要です。たとえば、テーブルに新しい行を追加する場合、通常、MVC部分ビューを使用して行を作成し、これをAJAX呼び出しの一部として返します。これはテーブルに挿入されます。純粋なフロントエンドの方法を使用すると、javascriptはAPI呼び出しから行のオブジェクト(たとえば製品)を取得し、そのオブジェクトから行を作成します。テーブル行の個々の部分を作成します。 問題のWebサイトには、管理、フォーム、製品検索など、さまざまな分野があります。私が考えていないWebサイトは、単一ページのアプリケーション方法で設計する必要はありません。 これについての皆の考えは何ですか? フロントエンドの開発者とバックエンドの開発者の意見を聞きたいです。

1
モバイル用のWCFまたはWebAPIを使用する利点はありますか?
Mono TouchとMono for Androidを使用した最初のモバイル開発を行っています。私が設計しているASP.NET MVC 4サイトと通信してほしい。私は過去にWCFとWebAPIを使用したことがありますが、このコンテキストで他のものを使用するよりも定量化できる利点があるかどうか疑問に思っていますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.