6

私と私のチームは新しいプロジェクトを開始する予定で、いくつかの新しい (またはそれほど新しくない) テクノロジを調査およびテストする段階にあります。

今日まで、DBDataReaders、遅延読み込み用のプロキシ、場合によっては DataTables を備えた従来の ADO を使用していました。

チームは 3 人の開発者と 1 人のデータベース デザイナーで構成されています。私たちのプロジェクトは、それぞれ少なくとも 130 のテーブルで構成されています。

私たちの新しいプロジェクトは成長する可能性があるので、確実に 100 テーブルを見込んでいます。

私は過去 2 日間、EF5 を読んでいくつかの簡単なテストを行ってきましたが、それを使用する必要があるかどうかはまだ判断できません。

  1. 私たちは通常、大きなプロジェクトを多くの「モジュール」プロジェクトに分割して、ソース管理の下でより速く、より適切に作業できるようにします。DB全体に1つの大きな「edmx」を使用するつもりですか?
  2. データベース デザイナーがいるので、CodeFirst はオプションではないのではないかと思います。では、データベース ファーストのアプローチで EF を使用する価値はありますか?
  3. データベースの最初のアプローチを使用する場合、EF は十分にスマートで、すべての関係を正しく検出し、追加の構成なしで使用できるようになりますか? (追加の構成とは、DataAnnotations を記述するか、DbContext を無視する必要があることを意味します)
  4. 個人的には、SQL を使用してデータベースを設計することに自信を持っています。私が持っている唯一の煩わしさは、クラスリストでエンティティが変更されたときに、すべての選択、削除、更新、挿入スクリプトを更新する必要があるときです。EFがこれを処理してくれますが、これを除けば、パフォーマンスが遅くなり、慣れていないため、最終的には生産が遅くなると信じ始めています..

それは価値があると思いますか？

*DataAnnotations と DbContext ovveride を除いて、プレーンな T4 テンプレートを使用してテーブル (スキーマ) を作成する人はいますか?

4

3 に答える 3

4
  1. 複数のモデルを作成することを強くお勧めします。それぞれにマップするテーブル、ビュー、およびストアド プロシージャを選択できます。
  2. データベースを最初に使用しても問題ありません。
  3. データベースの制約が設定されている場合、EF はそれを認識します。マイナーな変更を回避することはできませんが、全体として、EF は非常に優れた機能を果たします。
  4. EF を使用すると、クエリのパフォーマンスにわずかな影響があります。しかし、ほとんどの場合、それは問題になりません。許容できないパフォーマンス ヒットが発生する可能性があるいくつかのケースでは、必要に応じて独自の SQL を EF に挿入することで最適化できます。

EF の使い方にはすぐに慣れると思いますので、慣れていなくても長く問題になることはないと思います。

于 2013-05-22T19:12:13.727 に答える
-1

データベース構造が成熟している場合、EF は適切なソリューションです。

データベース構造が開発中である場合、または時間の経過とともに大幅に変更される場合、EF は最適ではない可能性があると断言できます。

構造的な変更 (およびデータベース レイヤーでのインターフェイスの変更の可能性) がある場合は、EF を更新する必要があります。開発済みのコード ベース内でデータベースの変更を管理する方法を検討する必要があります。

于 2013-05-22T18:12:32.403 に答える