1

多くのAjaxウィジェット（正確には剣道UI）を備えたアプリケーションを作成しています。標準のコントローラーなしでこれらすべてのAjax応答を取得するのは面倒になり始めているので、各エンティティを独自のコントローラーにすることを検討し始めました。時間をかけてこれを行うのであれば、近い将来にこれを行うことを計画していたので、WebAPIとしてそれらを実行したほうがよいと思いましたが、ねえ、それはすでに行われているでしょう...

だから私の質問は：MVCアプリケーション自体のWeb APIをAjaxウィジェットフィードとして使用するのは良い習慣ですか、それとも標準のコントローラーを使い続ける理由がありますか？

パフォーマンスについていくつかの議論を見てきましたが、これはこの状況には当てはまらないと思います。明らかにパフォーマンスに影響を与えるのは、「WebAPIを呼び出すコントローラー」の状況だったと思います。しかし、それはすでにクライアント側のAjax呼び出しであるため、標準のMVCコントローラーに入るのか、WebAPIコントローラーに入るのかは関係ありませんね。

編集

プロジェクトに関する追加情報：

  • データアクセスにEntityFrameworkを使用しています。
  • UnitOfWorkでリポジトリパターンが進行しています。
  • 適切なMVC構造を使用しています（リポジトリ内のDTO POCOに自動マッピングされ、コントローラーによってビューモデルにフィードされるEF POCO）
  • これは.NET4.0上のMVC4プロジェクトです
  • 多くのデータベース関係があります（特に、現在作業しているオブジェクトの場合）
4

2 に答える 2

0

「良い習慣」についてはわかりませんが、確かに「悪い習慣」ではありません。アプリでやっても別のアプリでも違いはわかりません。

于 2012-10-23T19:21:17.857 に答える
0

それは良いことだと思いますが、APIで行っていることが、他のアプリケーションやサービスに対して可能な限り一般的に保たれている場合にのみ、APIを再利用できます。

私が作成し、維持し続けている両方のアプリケーションは、アプリとほぼ同じスタックを使用します。

最近、アプリケーションの1つをリファクタリングして、ビュー内のKendoComboBoxesなどにバインドしているリストなどのすべての一般的なものにAPIを使用しました。状態、優先度、さまざまなエンティティやビューにわたる複雑さなど、同じリストの多くを再利用するかなり大きなアプリケーションなので、それらをAPIに含めるのは理にかなっています。

私は完全な豚を通り抜けるところまで行っていません。私はこのようなもので線を引きます：

public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
    {
        return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
    }

これは、剣道グリッドがデータを戻す方法に非常に固有です。このアプリに接続している他のデータはこの形式のデータを使用しないため、コントローラーに保持します。

要するに...私は同じMVCアプリ内の一般的なものと、Excelなどの他のアプリケーションやサービスでの使用を許可するものにAPIを使用しています。

于 2013-07-24T04:39:51.047 に答える