14
バックエンドをAPIとして作成する必要がありますか？
今日、MVCアプリケーションについて熱く議論しました。MVC（ASP.NET）で記述されたWebサイトがあり、通常はビューで何かを実行するパターンに従います->コントローラーを押す->コントローラーがモデルを構築します（データを取得するマネージャーを呼び出し、モデルを構築しますコントローラのメソッド自体）->モデルが表示されます->すすぎと繰り返し。 彼は、私たちのコードが密結合しすぎていると言った。たとえば、デスクトップアプリケーションも必要な場合、既存のコードを使用することはできません。 彼が言った解決策とベストプラクティスは、APIを構築し、APIの上にWebサイトを構築し、デスクトップアプリケーション、モバイルアプリなどを構築することは非常に簡単です。 これは、さまざまな理由で私にとって悪い考えのようです。 とにかく、このプラクティスを議論するかもしれないグーグルで何も見つけられないようです。誰もが長所、短所、なぜそうすべきか、なぜそうすべきではないか、さらに読むべきかについての情報を持っていますか？ 悪い考えだと思ういくつかの理由： バックエンドをAPIから実行するにはあまりにも抽象的です。あなたはそれをあまりにも柔軟にしようとしているので、それは管理不能な混乱になります。 MVCに組み込まれているものはすべて、役割や認証など、役に立たないようです。たとえば、[Authorize]属性とセキュリティ。独自にロールする必要があります。 すべてのAPI呼び出しにはセキュリティ情報が添付されている必要があり、トークンシステムなどを開発する必要があります。 プログラムが実行する機能ごとに、完全なAPI呼び出しを記述する必要があります。実装するほとんどすべてのメソッドは、APIから実行する必要があります。すべてのユーザーのGet / Update / Deleteに加えて、ユーザー名の更新、グループへのユーザーの追加など、他の各操作のバリアントがあり、それぞれが個別のAPIコールになります。 APIに関しては、インターフェイスや抽象クラスなどのあらゆる種類のツールが失われます。WCFのようなものには、インターフェイスに対する非常に乏しいサポートがあります。 ユーザーを作成するメソッド、または何らかのタスクを実行するメソッドがあります。50人のユーザーを作成する場合は、50回呼び出すだけです。このメソッドをAPIとして実行することを決定すると、ローカルWebサーバーは名前付きパイプに接続でき、問題はありません-デスクトップクライアントもヒットできますが、突然、ユーザーの一括作成にはインターネット上でAPIを50回ハンマーする必要があります。良くない。したがって、バルクメソッドを作成する必要がありますが、実際にはデスクトップクライアント用に作成するだけです。この方法では、a）統合するものに基づいてAPIを変更する必要があり、直接統合することはできません。b）余分な関数を作成するためにより多くの作業を行う必要があります。 ヤグニ。たとえば、1つのWebアプリケーションと1つのWindowsアプリケーションなど、まったく同じように機能する2つのアプリケーションを作成することを特に計画しているのでなければ、膨大な量の開発作業が必要になります。 エンドツーエンドでステップスルーできない場合、デバッグははるかに困難になります。 多くのやり取りを必要とする独立した操作がたくさんあります。たとえば、いくつかのコードは現在のユーザーを取得し、ユーザーが管理者ロールにあることを確認し、ユーザーが属する会社を取得し、他のメンバーのリストを取得し、それらをすべて送信しますEメール。そのためには、多くのAPI呼び出しが必要になるか、必要な特定のタスクに特注のメソッドを記述する必要があります。特注のメソッドの唯一の利点は速度ですが、欠点は柔軟性に欠けることです。 おそらく、これらの理由のいくつかが私の頭上にあります。 2つの同一のアプリケーションが本当に必要な場合を除き、私には好感が持てますが、それだけの価値はありません。このように構築されたASP.NETアプリケーションを見たことがありません。2つの個別のアプリケーション（APIとコード）を記述し、両方をバージョン管理する必要があります（ユーザーページに新しいフィールドが追加された場合、 dは、APIと消費コードを同時に更新して悪影響を与えないようにするか、堅牢性を維持するために多くの追加作業を行う必要があります）。 編集：いくつかの素晴らしい反応、本当にこれが今何を意味するのか良いアイデアを得るために始めています。それでは、私の質問を拡張するために、このAPI構造に従うようにMVCアプリをどのように構成しますか？ たとえば、ユーザーに関する情報を表示するWebサイトがあります。MVCには、次のものがあります。 ビュー-UserViewModelコントローラーを表示する（CS）HTMLページ-GetUser（）を呼び出し、GetUserメソッドを持つビューマネージャークラス（APIの一種）に渡すUserViewModelを作成します。 コントローラーはGetUser（）を実行しますが、デスクトップアプリも必要です。これは、GetUserが何らかのAPIを介して公開される必要があることを意味します。TCP接続、WCF、またはおそらくRemotingが必要になる場合があります。永続的な接続が不安定なため、RESTfulなモバイルアプリも必要です。 それでは、GetUser（）メソッドがあり、コードが実行するWCF Webサービスごとに、各APIを作成しますreturn new UserManager().GetUser()か？そして、同じことを行うMVC 4 Web APIメソッド？MVCコントローラーメソッドでGetUserを直接呼び出し続けていますか？ または、3つすべて（Web API RESTサービス）で機能するソリューションを選択し、その上にすべてを構築して、3つすべてのアプリがAPI呼び出し（ローカルコンピューターに対してmvc呼び出し）を行うようにします。 そして、これは単なる理論上の完璧なシナリオですか？特に、RESTfulな方法で操作を行えるように開発する必要がある場合、この方法で開発する際に大きなオーバーヘッドが発生することがあります。これのいくつかは返信で取り上げられていると思います。 編集2：より多くのものを読んだ後、私はそれを説明するかもしれないと思うコメントを下に入れました。この質問は、私が考えるちょっとしたトリックの質問です。APIとしてバックエンドを書くと、すべて（mvcアプリ、デスクトップアプリ、モバイルアプリ）が何かを行うために呼び出す単一のWebサービスがあるべきだと思って混乱しました。 私が思いついた結論は、ビジネスロジックレイヤーが正しく分離されていることを確認することです。コードを見て、すでにこれを行っています。コントローラーはGetUser()マネージャーを呼び出し、それからビューモデルを作成してビューでレンダリングします。実際、ビジネスロジック層は APIです。ただし、デスクトップアプリから呼び出したい場合は、WCFサービスのようなものを記述して、呼び出しを容易にする必要があります。GetUser()コードを含むWCFメソッドを呼び出すだけでもreturn MyBusinessLayer.GetUser()十分です。したがって、APIはビジネスロジックであり、WCF / Web APIなどは、外部アプリケーションに呼び出しを許可するためのほんの一握りのコードです。 そのため、必要なものに応じてビジネスロジックレイヤーをさまざまなAPIでラップする必要があり、他のアプリで実行したい操作ごとにAPIメソッドを記述する必要があるというオーバーヘッドがあります。認証を行う方法を整理しますが、ほとんどの部分で同じです。ビジネスロジックを別のプロジェクト（クラスライブラリ）に固定すれば、おそらく問題はありません！ この解釈が正しいことを願っています。それが生成したすべての議論/コメントをありがとう。
322
mvc
asp.net-mvc
api-design