0

私はちょうど今、MVC4 (何年も Webform を使っていた) を自分自身に教えていて、イライラしていますが、かなり良い MVC についてではありません。Entity Framework は...まあ

私はVS2010を使用しています。

問題

外部キーなどで正規化された実際のデータベースがあります。しかし、Entity Framework について私が見つけたすべての例は、テーブルに直接表示されますが、ドロップダウンなどの入力側で直接テーブルを引き出すことはめったにありません。すべてのフロントエンド呼び出しが Stored Proc にヒットしました (なんて古い学校でしょう!罵倒は削除されました)

私は、MVC のモデル アーキテクチャが気に入っています。ここでは、データ ソースからのデータの属性 (表示名、範囲、データ型) を定義します。などですので、これは絶対に持っておきたいですね。

Entity Framework と MVC は、このシナリオではうまく機能したくありません。edmx ファイルを作成し (SP のみ)、SP 用に関数をインポートしました。今のところすべて問題ありません。

edmx/デザイナーからコントローラーを作成できません - コントローラー名を入力し、EF を使用して読み取りを行う MVC コントローラーを選択し、FuntionName_Result であるモデル クラスを選択し、コンテキストとして ...エンティティ名を選択します。FAIL メタデータを取得できません

OK、それで、EF 5.x DbContext ジェネレーターを試して、ファイル名を更新して、ブーム モデルとコンテキストを手に入れました。これで、クールな MVC を実行できるようになりました。サイトを再構築できます....ああ、恐怖です-すべてが以前に定義されています。

別のフォルダーに edmx を生成しようとしたり、DBContext ジェネレーターの後に削除しようとしましたが、コントローラーを作成できません。

'blah' is not part of the specified 'Context' class, and the 'Context' class could not be modifed to add a 'DbSet' property to it. (For example, the 'Context' class might be in a compiled assembly.)

DBSet を手動で追加すると、メタデータを取得できなくなります。これは、DB に接続できないために発生していると想定しています。web.config で接続文字列を使用するように指示する場所がわかりません。- これが問題の場合

ここに、より明るい未来への私の MVC の希望が死んでいます。

私は何が欠けていますか?

私は EF と結婚していないので、(すべてのコードを最初から書かずに) データベースにアクセスするためのより良い方法があれば、聞きに来ます。

ありがとう

4

3 に答える 3

1

エンティティ フレームワークは、規約に大きく依存しています。慣れるまで少し時間がかかります。たとえば、接続文字列の場合...エンティティフレームワークがDBcontextクラスと同じ名前の接続文字列を見つけられない場合は、それを作成するだけです(デフォルトでは、プロジェクト名をデータベース名として使用すると思います)。このデータベースが存在しない場合は、SQL Express DB としてローカルに作成されます。これにより、報告しているような種類のエラーが発生します。

エンティティ フレームワークの接続文字列を定義する場合は、web.config で接続文字列を指定するだけです。再び規則....接続文字列はDBContextクラスと同じ名前にする必要があり、エンティティフレームワークはそれを見つけるだけです。

<connectionStrings>
      <add name="MyDbContextClassName" connectionString="..." />
</connectionStrings>

アーキテクチャの観点から言えば、IMHO ORM は、新しいアプリケーション開発に向けて挑戦する方法です。データベースへのデータの出し入れが非常に簡単になります。つまり、sprocs を介してすべてにアクセスし、DB に直接クエリを送信することに慣れている場合、これは大きなパラダイム シフトです。それをあきらめないでください。新しい技術を手に入れるのと同じように、最初はイライラしますが、最終的にはそれだけの価値があります.

過去に ORM にエンティティ フレームワークと nHibernate を使用したことがあります。エンティティ フレームワークについて私が気に入っている点は、コード ファースト マイグレーションを使用すると、面倒で面倒でエラーが発生しやすい列マッピングのほとんどが自動生成されることです (ここでも規則を使用します)。ちょっとしたマッピングをしなければならないこともありますが、そのようなケースは非常にまれです。列名がエンティティ フレームワークの規則と常に一致するとは限らないため、既にデータベースがある場合は、少し珍しいかもしれません。とにかく...これは私の本の大きなプラスであり、nHibernateよりもEFを断固として好む理由です。

于 2012-12-14T16:06:45.347 に答える
0

ストアド プロシージャを使用するデータベースが既にある場合は、EF 5.X DbContext Generator は必要ありません。データ アクセス用に、プロジェクト内にフォルダーを作成するか、ソリューション内に新しいプロジェクトを作成します。そのフォルダー/プロジェクトに edmx ファイルを追加し、ウィザードを使用して既存のデータベースに構成します。この段階で、ストアド プロシージャを取り込むことができます。

edmx ファイルを開くと、モデル エクスプローラー タブに移動して、インポートされた関数 (ストアド プロシージャ) とその戻り値の型を管理できます。

それができたら、コントローラーで、DbContext のインスタンスを使用するのではなく、EF エンティティのインスタンスを使用できます。したがって、edmx 'MyDbAccess' を呼び出した場合は、ストアド プロシージャにアクセスできる MyDbAccessEntities を使用できるはずです。

于 2013-05-08T16:49:21.850 に答える