0

ASP.NET MVC 3 の学習を始めたばかりで、アプリケーションのデータベースに接続する最良の方法を決定するのに非常に苦労しています。私のアプリケーションデータベースは定期的に強化されるため、新しいテーブル、列を追加/削除でき、一部の列のデータ型も変更される可能性があります。したがって、このシナリオでは、コードが管理しやすくなり、これらの変更がコードに影響を与えないように、どのアプローチが最適でしょうか (例: EF でテーブルを削除して再選択すると、新しいクラスが生成され、関連するコードが生成されます)クラスが影響を受けます)？Code First、Database First、Entity Framework、Enterprise Library Data Access Block、SQL 接続呼び出しストアド プロシージャなどのアプローチがあることを読みました。しかし、このシナリオでどちらが最適かはわかりません。また、データベースに接続するための ASP.NET MVC 3 の本当のフレーバーが欠けている可能性があります。

編集1

なぜ閉会を命じられたのかはわかりませんが、それでもこのフォーラム以外に選択肢はありません。私の質問Code First vs Data Firstの部分的な内容を述べている同様の質問を見つけました。その答えは、データベースの最初のアプローチに関して私の頭の中で混乱を引き起こしました。

4

3 に答える 3

2

最初に、MVC アプリケーションを開発しているという事実は、データ アクセス層の構築に使用するテクノロジの決定とは完全に切り離されています。

.NET のデータ アクセスには多くのオプションがあり、2 つのカテゴリに分類されます。頭に浮かんだものを、それぞれいくつかのポイントとともにリストします

直接データ アクセス

  1. ADO.NET DataReader (高速で手作業が多く、SQL コードを手動で記述する必要があります)
  2. ADO.NET データセット

オブジェクト リレーショナル マッパー (ORM)

  1. LINQ2SQL
  2. Entity Framework DB ファースト
  3. エンティティ フレームワーク コード ファースト
  4. NHibernate
  5. 多くの商用サードパーティ ツール
  6. ダッパー

SQL を手動でコーディングすると、確実にアクセスが高速になりますが、コストがかかり、すべてを自分で行う必要があります。

ORM はデータベースにある種の抽象化レイヤーを提供するので、オブジェクトだけを操作できます。その代償として、パフォーマンスがいくらか低下します (クエリの生成、SQL の結果からオブジェクトへのマッピング)。

Dapper は、読み取りパフォーマンスに重点を置いた ORM であるため、ここでは多少特殊ですが、SQL クエリを自分で作成する必要があり、書き込みサポートは限られています。

個人的には、DataSet、LINQ2SQL、EF Db First、EF Code First、Dapper の経験があります。新しいアプリを開始する必要があるとき、非常に高い負荷が予想されない場合は、EF Code First を使用します。これは特に、既存のデータベースがない場合に当てはまります。クラスを作成し、データベースを生成するだけです。さらに優れているのは、クラスを変更すると EF がデータベース構造を更新する自動移行です。生成されたコードに注意を払えば、データを失うことなくこれが可能です。

高いパフォーマンスが要求される場合は、SQL を完全に制御できる Dapper を選択します。オーバーヘッドはほとんどなく、快適なマッピング エンジンです。

さらに、このような質問がたくさんあります (お気に入りの ormを探してください):

于 2012-11-29T08:53:52.607 に答える
1

Jan は、EF が唯一の ORM ではないことをうまく指摘しています。しかし、あなたがEFタグで尋ねたので、彼はEFの視点です。

EF4.3 以降、EF はコードベースのコード ファーストの移行をサポートしています。つまり、モデルを変更すると、コードは最初に DB を変更して新しい列とテーブルを追加できます。このための新しい DB 初期化子があります。行の残りのデータを失うことなく、列を削除することさえできます。

同様に、最初に DB を使用して DB からモデルをインポート/更新することもできます。Import from existing DB を使用した最新の t4 テンプレートは、部分的な POCO クラスを作成します。したがって、生成された MODEL クラスを安全に拡張し、再インポートを続けても何も失うことはありません。

したがって、変更可能な DB/モデル シナリオでは、コード ファーストまたは DB ファーストのいずれかを使用できます。

私はグリーン フィールド サイトで両方の手法を使用しました。最初はDBの方が快適に感じました。その後、ef4.3 で新しい移行オプションを見つけたら、変換することにしました。Microsoft の強力なツールがあるため、変換は迅速でした。NUGET Entity Framework power Tools (2012 年 11 月現在ベータ 2) http://blogs.msdn.com/b/adonet/ 最初に DB からコードをリバース エンジニアリングするオプションがあります。したがって、DB ファーストからコード ファーストに変換できます。そして、CODE ベースの移行を使用します。

于 2012-11-30T10:35:33.150 に答える
1

私は同様のシナリオで開発を行っており、外出先でテーブルを作成、削除、または更新しています (あまり良いシナリオではありません)。Database Firstこのシナリオに最適であるため、現在このアプローチを使用しています。

Database First次の場合に使用する必要があります。

データベース構造の変更を行うと同時に、ユーザーがデータを挿入または更新します。そうしないとCode First、データベース構造を変更するたびにデータが削除されるというアプローチを選択すると、データを復元するためにいくつかのハックを実装できますが、アプリが稼働中の場合、多くの問題が発生する可能性があります。

構造の変化をどのようDatabase firstに扱うか:

  1. "Users" テーブル (データベース内) にいくつかの変更を加えます。
  2. Visual Studio に移動し、DBContext を使用して "User" クラスを更新します。

構造の変化をどのようCode firstに扱うか:

  1. 「ユーザー」クラスを（モデルで）変更します。
  2. データベースが自動的に更新され、Users テーブルに必要な変更が反映されます (保存されたデータが失われます)。
  3. 対処すれば、データを復元できます (ただし、データベースが使用中の場合は、良いことではありません)。

とにかく、この方法で作業することはお勧めしません。データベースが完全に適切に設計されている場合は、その上でコーディングを開始することをお勧めします。

編集：

Entity Framework 4.3 にいくつかの新しいクールな機能が追加されたため、私の答えはもはや正しくないようです: Code First Migrations、私の間違いを指摘してくれた @soadyp に感謝します。

于 2012-11-28T22:25:36.220 に答える