0

私は MVC フレームワークと ASP.NET WEB API に非常に慣れていません。

私はかなり長い間、データをストアド プロシージャのみとして n 層アーキテクチャで ASP.NET AJAX を使用して Web アプリケーションを構築してきました。

製品の 1 つをアップグレードして、HTML5 ASP.NET WEB API を使用して開発しようとしています。DAL とストアド プロシージャをそのまま維持し、DAL の上に ASP.NET WEB API または WCF Data Services を使用してサービス レイヤーを追加したいと考えています。 HTML5 プレゼンテーション レイヤーは、データのサービス レイヤーにヒットします。

これが、データベースのストアド プロシージャと DAL をそのまま維持したいシナリオであるかどうかを提案できますか?

EF5 でのストアド プロシージャのサポートには、複数テーブルのデータセットを使用する一部のストアド プロシージャをサポートするための成熟度がさらに必要であることに気付いたので、これには回避策があることを知っています。私は EF 6 Alpha 仕様を見て、その機能に興奮しています。

データ アクセス層の上にある ASP.NET WEB API サービス層のチュートリアルまたはサンプルへのリンクはありますか? または、いくつかの提案をするか、正しい方向に向けてください

現在の問題の解決策をどのように実装したいかについて大まかな推測をしなければならない場合。私は言うでしょう。

現在の DAL は、データセット内の DataTable のデータセットとラッパーを提供して、IQueryable に変換し、それらを ServiceLayer で使用して、EF の回避策全体をスキップします。

前もって感謝します

4

1 に答える 1

4

実際には、これが可能です。サービス ロジックを Web API に配置することもできますが、私はそうしません。API を可能な限り軽量かつシンプルに保つために、抽象化のレイヤーをもう 1 つ追加したいと思います。あなたのシナリオによれば、次のようなものがあります：

  1. ストアド プロシージャを使用したバックエンド DB サーバー
  2. ナンバー 1 のバックエンド DB を操作するためのデータ アクセス レイヤー コンポーネント。

ここで、2 の上に API を構築したいと考えています。私の提案は、計算などの追加のロジック、必要に応じて追加の検証、メッセージング サービスなどを配置するサービス レイヤー (別名ビジネス ロジック レイヤー) を追加することです。

そして、サービス層の上に Web API を追加します。したがって、最終的にレイヤリングは次のようになります。

  1. ストアド プロシージャを使用したバックエンド DB サーバー
  2. ナンバー 1 のバックエンド DB を操作するためのデータ アクセス レイヤー コンポーネント。
  3. サービス層 (ビジネスロジック)
  4. ASP.NET Web API
  5. HTML5 クライアント

この背後にある考え方は、将来、製品に機能を追加する必要が生じたときに、サービス層でそれを行うということです。Web API に複雑さを加えないでください。メンテナンス、テスト、および将来の拡張について考えてください。

于 2013-03-05T10:57:11.000 に答える