10

コードファーストマイグレーションについて読んだことがありますが、これはエンタープライズにはあまり適していないようです。

データベースのすべての変更を行うDBAがあり、これらの変更をクラスに入れて、アプリケーションでデータベースの移行を実行する必要はありません。

クラスと流暢なAPIを変更してから、DBAにデータベースに変更を加えさせる場合、EFモデルに同期するにはどうすればよいでしょうか。これは通常、エンタープライズサイズのアプリケーションでどのように行われますか？

4

6 に答える 6

5

私は EF コード ファースト スタイル (EDMX ではなく) を使用していますが、EF にデータベースを生成させたことがないため、技術的にはデータベース ファーストのアプローチを使用しています。代わりに、データベースをモデル化するクラスを作成します。これは、あなたの場合に必要なことのように聞こえます。

DBAの変更に関しては..ドメインエンティティクラスを更新する必要があるかどうかは、DBAが変更しているものによって異なります。たとえば、彼がvarchar(100)tovarchar(200)などの長さを増やしている場合、その変更によって実際にコードが壊れることはありません (ただし、これに合わせてコードを更新することをお勧めします)。ただし、一部の列を削除または名前変更している場合は、ドメイン エンティティ クラスを更新する必要があります。これは、基になるモデルが同期していないという例外が明らかに発生するためです。

于 2013-03-15T01:37:06.657 に答える
1

通常、そのような場合、人々はデータベース ファーストのアプローチを使用します。

誰かがすでにデータベースを設計していて、数回クリックするだけでモデルを生成または更新できる場合、エンティティ コードを手動で記述することは意味がありません。もちろん、あなたのチームがそれが主なアプローチであった他の ORM に慣れていて、Entity Framework にはまだあまり慣れていない場合、またはチームが非常に小さく、誰も SQL スクリプトを記述できない場合、Code First は便利ですが、熟練した DBA の皆さん、なぜ Code First が必要なのですか?

于 2013-03-15T10:44:05.370 に答える
0

これについていくつかの考えを追加するために-これらの2つの投稿を見てください（私は少し前に作成しました）： https://stackoverflow.com/a/10164815/417747
https://stackoverflow.com/a/10255051/417747

要するに、私の経験から：

  • このようなソリューションを実際のエンタープライズ サイズのデータ​​ベースで簡単に「維持」することはできません。遅かれ早かれ「2つの世界」は衝突するだろう、物事を同期させることは苦痛かもしれない
  • しかし、だからといってあきらめてはいけません。ジャンプスタートに適しています。慎重に計画し、同期することで、しばらくの間これを機能させることができます。
  • スクリプトをダンプしたり、移行コードを微調整したり、「シード」を調整したりして、いくつかの変更をなくすことができます (それでもいくつかの制限は苦痛であり、DBA ができることを「模倣」することはないと思います)。
  • CFが行き過ぎたら（DBAが引き継ぐとすぐに）CFからの「生成」をスキップできます-そして（スクリプトを使用し、投稿で部分的に説明されています）Db-sが一致することを確認します（実際のコードと「コード」 ' 青写真 1)。それはまだ、ほとんどのテーブルなどのセットアップが完了していて、いくつか調整する必要があることを意味します。
  • これは「経験則」です。多くの場合、CF は妥当ではありません。そのため、プロトタイプ作成に使用してください。
  • あなたが説明しているシナリオでは、優れた「データベースジェネレーター」がおそらくより良い解決策です（ただし、いくつかの欠点もあります）が、両方の世界の優れた「コンボ」はまだ見たことがありません

これが少し役立つことを願っています。

于 2013-03-15T02:06:57.687 に答える