3

MVC データ アクセスにストレート SQL を使用することに関する他の質問を見てきました。ほとんどの回答は質問に答えず、尋ねる

「なぜ ORM、EF、Linq などを使いたくないのですか?」

  1. 私のグループは、ユーザー GUI パラメーターの選択に基づいて操作される、高度に調整された複雑な Oracle クエリを多数必要とするデータ ウェアハウスからカスタム レポートを作成します。

  2. 私の最新のプロジェクトは、SQL レポート開発者向けの SQL プラグイン レポート ツールを開発することです。彼らは、疑似パラメーターを使用してレポート用に事前調整された SQL を作成し、GUI を介して入力 (および保存) します。次に、GUI は、最終的に疑似変数を置き換えるために、実行時に表示/要求する必要があるパラメーター定義 (名前と型) を要求します。

したがって、SQL ステートメントは次のようになります。

SELECT * FROM orders WHERE order date BETWEEN '<Date1>' AND '<Date2>'

レポート開発者は、GUI を介して と という名前の 2 つのパラメーターを追加Date1しDate2、日付フィールドとしてフラグを立てます。

Date1次に、エンド ユーザーはレポートを選択し、との入力を求められDate2、GUI が置換を行い、SQL を実行します。

ご覧のとおり、ストレート SQL を使用する以外に選択肢はありません (特に 2 番目の例では、2 番目の例でも強く型付けする必要があることを理解しています)。

だから私の質問は：

  1. EF/Linq をバイパスする必要があるのはいつですか (そして間違いなく理由があります)、MVC 4 のベストプラクティスは何ですか?
  2. また、出力列が事前にわかっている場合、どのように厳密に入力するのが最善でしょうか?
  3. そしてCRUD処理？
  4. この点に関して、EF/Linq ベース以外のコーディングの例を教えてもらえますか?
4

1 に答える 1

2

これは少し自由回答の質問だと思うので、ここに私の 2c を示します。(tl dr の場合は、最後のセクションに移動します)

  1. 私にとっては、「EF/Linq を渡す」ということではなく、適切なデータ永続化ライブラリを選択する必要があるということです。私は MVC で PetaPoco、Ado.Net、NHibernate/ActiveRecord、Linq2Sql、EF (私の主な選択) を使用しました。

    実際のベスト プラクティスは、コントローラーがまだプレゼンテーション レイヤーの一部であり、HttpContext 関連の操作 + ビジネス ロジック サービス クラスの呼び出し以外は処理しないことを認識することから得られます。

    クラスを次のように配置します:
    プレゼンテーション (MVC) -> ロジック サービス (単純なクラス) -> データ アクセス (「リポジトリ」でラップされたコンテキスト)。
    したがって、EFを使用するかどうかがasp.net MVCに影響を与えるかどうかは、まったく想像できません。

  2. 私にとって、データ アクセスは DTO でデータを返します。

    public List GetAllFoos()

    そのメソッド文字列が xml などから連結されるか、単純な Context.Foos.ToList() を実行するかは、アプリケーションの残りの部分とは無関係です。私が気にするのは、Data Access が列に一致する文字列を含む DataSet を返さないことだけです。それらはDALにとどまります。

  3. ポイント 1 と 2 を参照してください。私のリポジトリには CRUD メソッドがあります。それがどのように行われるかは、残りのアプリケーションには関係ありません。私のリポジトリ クラスへの最も基本的なインターフェイスの 1 つを取り上げます。

    public interface IFooRepository { void Save(Foo foo) Foo Get(int id) void Create(Foo foo) void Delete(int id) }

    1点まだ触れていませんが、DIも重要です。具体的な実装 "FooRepository" は、Web サービス、コンテキスト クラスなどの依存関係を要求することを選択できます。ただし、これらは、インターフェイスに依存する呼び出し元にはまったく関係ありません。

  4. 上記の 3 つのポイントの後にまだ例が必要な場合は、コメントをドロップしてください。Ado.net を使用して非常に簡単なものを作成します。

================================================== =========================
EFにするかEFにしないか。

私にとって、新しいスキーマで新しいプロジェクトを開始する場合、最初に EF コードを使用します。

新しいコードを古いデータベースに合わせる + 古いプロジェクトには、再利用できる ORM マッピングがない = PetaPoco.

================================================== =========================
プロジェクトのコンテキストでは:

「SQL レポート開発者向けの SQL プラグイン レポート ツール」。「その」SQLレポートサービス？なぜあなたが何かをする必要があるのか​​ わかりませんか？SSRSはすでにそれを行っていませんか？(SQL ステートメント/データ ソースの入力、パラメーターのフォームの生成など)。

そうでない場合は、設計上の決定に疑問を呈します。IMVHO、アプリケーションのユーザー (「レポート開発者」かどうかは気にしません) が SQL ステートメントを入力する必要があるのは、通常、「建築宇宙飛行士」に由来します。GUI を介して文字列として入力した場合、SQL ステートメントをどのようにデバッグしますか? テーブルと関係をどのように知ることができますか? SSMS を掘り下げて gui に戻るか、複雑な UI を構築します (別名、SSMS を再構築します)。

結局のところ、膨大な数の異なるユーザーの膨大な数のレポートが必要な場合は、料金を支払う必要があります。アプリケーションを公開して SQL ステートメントを受け入れるだけの「アーキテクチャの宇宙飛行士」が多すぎて、アプリケーションに何を入れるべきかを推測するのに時間を無駄にしているのを目にします。コスト削減は全くありません。

わかりました、それをしなければならないのなら、そうですね...頑張ってください。最善の策は、DataTable として返され、行/列/データをビューにダンプし、ネストされた foreach が行、列をループすることです。

于 2013-04-21T13:05:15.690 に答える