8

私は非常に大規模な Web プロジェクトを始めたばかりで、本当にすべてを正しく行おうとしています。

これまでに使用したツールは

  • ASP.NET MVC 3
  • エンティティ フレームワーク 4.3
  • ニンジェクト3

すべて順調に進んでいますが、Entity Framework CodeFirst については、少し大ざっぱな点がいくつかあります。

たとえば、http://codefirstmembership.codeplex.com/を使用して、Code First セットアップの一部としてメンバーシップ情報をセットアップする必要がありました。これは、これのサードパーティを使用する必要があるため、少し厄介です。明らかに、私は「自分自身をロールバックする」のに十分な1337である必要がありますが、最初からあまり噛みつきたくありません. aspnet_regsql を実行するのは恐ろしく、データベースが更新されるたびに失われます。とにかく、上記のライブラリですべて動作するようになりました。それほど悪くはありません。しかし、足場は壊れているようです。

これらすべてを超えて、私がライブ環境で実行しているときに、このようなものがプロバマティックになるようです. dev db と live db の間で行う予定のスキーマの変更は、とにかくスクリプトを使用して手動で管理する必要があるため、その時点で最初にコードのポイントを失うことはありませんか?

私は昨年 Google App Engine を使用してきましたが、最初はコードが基本的に同じように機能することを望んでいましたか? つまり、変更を加えると、ライブ データが変更されます。アプリエンジンで深刻なリファクタリングを行っていないため、本番環境では基本的に何も害を及ぼさないと思います。したがって、AppEngine でテーブルの名前を変更することはできません。常に新しいテーブルを作成し、古いテーブルを残します。データを手動で移植する必要があります。

だから今考えています。なぜ最初にデータベースに行かないのですか? 私は linq2sql を 3 年間使用しており、最初に db を使用することに非常に慣れています。TBH ですが、私の db ソース管理戦略は少し....欠けています。だから私は、コードが最初にその状況を改善することを強制することを望んでいました.

このような状況についてご意見をお聞かせいただければ幸いです。また、これは Nhibinate を使用する場合とどのように比較されますか?

4

2 に答える 2

7

あなたが説明しているアップグレード シナリオは、EF-Migrations に追加されています。これのライブ リリースは既に利用可能であり、正式にサポートされているリリース バージョンとして間もなく利用可能になるはずです。

チェックアウト: https://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx?Redirected=true

チェックアウト: http://coding.abel.nu/tag/ef-migrations/

于 2012-04-07T18:56:18.390 に答える
3

これについての私の見解です...

良い選択をする必要はありません -

、カスタムイニシャライザ（および移行は手を携えて - 移行では、実際に手動で変更できSeedます。たとえば、そこにインデックスを追加するなど - 慎重に）を使用して、生のSQLを「注入」できます（ほとんどのニーズはそれ）。私の知る限り、カスタム バッチ ファイル フォーム イニシャライザを実行できます (ただし、試したことはありませんが、理由はわかりません)。移行は PS を介して行われるため、PS 側にも統合する余地があると思います。

それを使用してプロトタイプを作成し、起動することができます - C# 構造を所定の位置に配置して高速に同期させます - その後、後で形を整えます - または修正したら、コードから何もせず、すべてを Db 側に移動する「既存のイニシャライザを使用する」を使用します。あなたのDBA。

IMO、実際にCFをオフにしてDbから作業する必要がある前に、この意味で「非常に遠くまで」行くことができます。

大規模なデータベースや企業環境の場合、これは間違いなく適切なツールではありません。

本番環境では安全だと思いますが、何を安全と見なすかによって異なります...

また、EF/CF は最初から長い道のりを歩んできました。私は最初からそれを使用していましたが、最初は大きな問題がありました。最新バージョンはあらゆる面でかなりしっかりしているので、そこまで来ていると思います.

...マイナス面-コードファーストアプローチ（EFなど）を使用して、かなり複雑なシナリオをいくつか解決しました。ただし、EFで私を妨げたものはほとんどありません(あなたが言及したことに加えて)...

UDFサポート、ビュー（linqを使用-LINQを使用しないかのように、大きな「長所」の1つがなくなったように）-これはEF 5.0で登場するはずです（私は確認しませんでしたが、それは彼らが約束していることです）-としてより複雑なシナリオでは、SQL 側で最適化する必要があります (または、バックでカスタム クエリを実行してからマップ バックできるようにする、つまり、その側の柔軟性を高める必要があります)。それが実現すれば、それは有望なことです (完璧ではないと思いますが)。（プラス面として、実際にカスタムクエリを実行してからオブジェクトにマップできますが、そのような作業は機能し、すべてを行うことはできないため、ある意味で制限されています）

クエリでのパフォーマンスと、より要求の厳しいシナリオでのパフォーマンス - それが私の主な問題でした。これは、EF 5.0 で改善されることも約束されています。

そうは言っても
、私のお気に入りは、ソリューション、ORMのようなカスタムまたはオープンソースコードです。そこでは、より多くのものを制御できます。多くのプロバイダーのサポートなどがあることで、長期的には「公式」または MS の実装がより実行可能になります。

これが何かに役立つことを願っています

于 2012-04-15T18:29:52.277 に答える