タグ付けされた質問 「entity-framework」

私は次の技術環境でプロジェクトを開始しています：.Net 4.0、Entity Framework 4.0、WVM with MVVM Architecture 私はネット上で多くの例を見て、この環境に関する本をいくつか見ました。いくつかの例では、著者はこのアイデアを持っていました： Viemodelには、Modelクラスのインスタンス（Entity Framework Entity、Personなど）があります WPFビューコントロールをModelのプロパティにバインドします 一部の著者はそうしましたが： Viemodelは、モデルのすべてのプロパティを公開します。 モデルに直接ではなく、ViewModelのプロパティにWPFビューコントロールをバインドします。 それでは、viewmodelが独自のモデルを公開するのではなく、モデルからプロパティをバインドできるようにすることをお勧めしますか？またはどちらがより好ましいですか？

21 .net  entity-framework  mvvm 

現在、すぐに使用できるオブジェクトリレーショナルマッパーを使用するか、独自のロールを作成するかを選択できる状況にあります。 残念ながら、データ層とビジネス層が一緒にマッシュされたレガシーアプリケーション（ASP.NET + SQL Server）があります。システムは、データアクセスに関して特に複雑ではありません。相互に関連するテーブルの大規模グループ（35〜40）からデータを読み取り、メモリ内で操作し、サマリー形式で他のテーブルに保存します。現在、いくつかのリファクタリングの機会があり、データアクセスを分離して適切に構造化するために使用する候補技術を検討しています。 どんなテクノロジーを選択したとしても、 ドメインモデルに、持続性に無知なPOCOオブジェクトがある モックアップされた基礎となるデータソースに対してドメインモデルオブジェクトをユニットテストできるようにする抽象化レイヤーがあります パターンとフレームワークなどに関しては、明らかにこれに関するものがたくさんあります。 個人的には、EFをADO.NET Unit Testable Repository Generator / POCO Entity Generatorと組み合わせて使用​​することを推進しています。これはすべての要件を満たし、Repo / UnitOfWorkパターン内に簡単にバンドルでき、DB構造は適度に成熟（既にリファクタリング済み）であるため、モデルに毎日変更を加えることはありません。 ただし、グループの他のメンバーは、独自のDALを完全にゼロから設計/ローリングすることを提案しています。（カスタムDataMappers、DataContexts、リポジトリ、どこでもインターフェイス、具体的なオブジェクトを作成するための依存性注入過剰、カスタムLINQから基になるクエリ変換、カスタムキャッシングの実装、カスタムFetchPlanの実装...）狂気として私。 投げかけられた議論のいくつかは、「少なくとも、私たち自身のコードを制御できるようになる」または「以前のプロジェクトでL2S / EFを使用したことがあり、頭痛に過ぎなかった」です。（私は以前に実稼働環境で使用したことがありますが、問題はごくわずかであり、非常に管理しやすいものでした） だから、あなたの超経験豊富な開発者/アーキテクトには、この製品を完全な災害になると思われるものから遠ざけるのに役立つかもしれない知恵の言葉があります。EFの問題をかわすことで得られる利益は、車輪の再発明を試みることで、すぐに失われると思います。

20 design-patterns  database-development  entity-framework  nhibernate 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 8年前に閉鎖されました。 ...または、より複雑になっていますか？ 最近、MS Webアプリを「適切に」開発するには、多くのことを知る必要があるように思えます。よくわからない悪い昔、データベーステーブル、ASP.NET、ADO.NETがあり、比較的単純な概念を使用してWebアプリを構築しました。 最近では、「正しい」ことを「手助け」するためのフレームワークがたくさんあるように見えますが、これがすべてをより簡単に、より良くすることを確信していません。私はこの感情でかなり小さな少数派になるだろうと感じていますが、物事が少し狂っていると思う他の誰かがそこにいますか？

17 wcf  linq  mvc  entity-framework 

私はEntity Framework、特にEF 4.1を読んでおり、このリンクをフォローしています（http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx）およびCode Firstのガイドです。 私はそれをきれいに見つけましたが、コードファーストは、多くの計画なしですぐに飛び込むことができる迅速な開発のための単なるソリューションであると考えられていますか、それとも実際に大規模なアプリケーションに使用されることを意図していますか？

16 entity-framework  codefirst 

新しいWebアプリケーションをAzure Web App Service（以前のAzure Webサイト）にプッシュする予定です。展開スロットを利用して、運用環境にプッシュする前に展開をテストできるようにします。DBスキーマの変更が必要ない限り、これで十分です。しかし、スキーマの変更がある場合、同じdbバージョンで動作する2つのソフトウェアバージョンを持つことはできません。EF Migrationsを使用しているため、ステージングスロットへのプッシュにより、即座にDBが最新バージョンに更新されます。 だから私の質問は、データベースの移行が必要なときに展開スロットを使用するかどうかです。 大規模なSaaSプロバイダーではどのように行われますか。彼らは新しいバージョンで即座にDB移行を実行していますか？それは確かにいくつかのダウンタイムを引き起こすでしょう。 この問題のかなり複雑な解決策しか考えられませんが、簡単なものはありますか？

15 entity-framework  deployment  migration  azure  continuous-delivery 

最近、仕事で同僚の何人かと議論しました。彼らは、.DLLに暗号化された文字列接続がある方が良いと言ったからです。そして、web.configで暗号化された文字列接続を暗号化しないのはなぜだと言いましたか？エンティティフレームワークは、たとえば、アプリケーションのWeb構成で接続の名前を検索するため、同じであり、より優れています。セキュリティポイントから、何がベストか、何がベストプラクティスかを知りたいですか？

14 web-development  c#  asp.net  security  entity-framework 

データモデル/データベースのプレゼンテーションレイヤーとエンティティフレームワークにJSONを使用したMVCを活用するWebサイトの作成を実験しています。私の問題は、ModelオブジェクトをJSONにシリアル化することに関係しています。 私は自分のデータベースを作成するためにコードファーストの方法を使用しています。コードファーストの方法を実行するとき、1対多の関係（親/子）では、子が親への参照を持つ必要があります。（サンプルコードはタイプミスかもしれませんが、写真を取得します） class parent { public List<child> Children{get;set;} public int Id{get;set;} } class child { public int ParentId{get;set;} [ForeignKey("ParentId")] public parent MyParent{get;set;} public string name{get;set;} } JsonResultを介して「親」オブジェクトを返す場合、「子」にはクラス親のプロパティがあるため、循環参照エラーがスローされます。 ScriptIgnore属性を試しましたが、子オブジェクトを見ることができません。ある時点で、親子ビューに情報を表示する必要があります。 循環参照を持たない親と子の両方の基本クラスを作成しようとしました。残念ながら、baseParentとbaseChildを送信しようとすると、これらは派生クラスとしてJSONパーサーによって読み取られます（この概念が私を逃れていると確信しています）。 Base.baseParent basep = (Base.baseParent)parent; return Json(basep, JsonRequestBehavior.AllowGet); 私が思いついた1つの解決策は、「ビュー」モデルを作成することです。親クラスへの参照を含まないシンプルなバージョンのデータベースモデルを作成します。これらのビューモデルにはそれぞれ、データベースバージョンを返すメソッドと、データベースモデルをパラメーターとして取得するコンストラクターがあります（viewmodel.name = databasemodel.name）。この方法は機能しますが、強制されているようです。 注：ここで投稿しているのは、これがより議論に値すると思うからです。別のデザインパターンを活用してこの問題を克服することも、モデルで別の属性を使用するのと同じくらい簡単にすることもできます。私の検索では、この問題を克服する良い方法を見ていません。 私の最終目標は、サーバーと通信してデータを表示するためにJSONを大幅に活用する素晴らしいMVCアプリケーションを持つことです。レイヤー全体で一貫したモデルを維持しながら（または、私が思いつく限り）。

13 asp.net-mvc  entity-framework  orm  json 

現在、データアクセス戦略としてEntity Framework 5（.net 4）を使用しているn層ソリューションを設計していますが、依存性注入を組み込んでテスト可能/柔軟にする方法を検討しています。 私の現在のソリューションレイアウトは次のとおりです（私のソリューションはAlcatrazと呼ばれます）。 Alcatraz.WebUI：asp.net webformプロジェクト、フロントエンドユーザーインターフェイスは、プロジェクトAlcatraz.BusinessおよびAlcatraz.Data.Modelsを参照します。 Alcatraz.Business：クラスライブラリプロジェクト。ビジネスロジックを含み、プロジェクトAlcatraz.Data.Access、Alcatraz.Data.Modelsを参照します。 Alcatraz.Data.Access：クラスライブラリプロジェクトは、AlcatrazModel.edmxとAlcatrazEntitiesDbContextを収容し、プロジェクトAlcatraz.Data.Modelsを参照します。 Alcatraz.Data.Models：クラスライブラリプロジェクト。AlcatrazモデルのPOCOを含み、参照はありません。 このソリューションがどのように機能するかについての私のビジョンは、web-uiがビジネスライブラリ内のリポジトリをインスタンス化することです。このリポジトリは（コンストラクタを介して）接続文字列（AlcatrazEntitiesインスタンスではなく）の依存関係を持ちます。web-uiはデータベース接続文字列を知っていますが、それがエンティティフレームワーク接続文字列であることはわかりません。 ビジネスプロジェクトで： public class InmateRepository : IInmateRepository { private string _connectionString; public InmateRepository(string connectionString) { if (connectionString == null) { throw new ArgumentNullException("connectionString"); } EntityConnectionStringBuilder connectionBuilder = new EntityConnectionStringBuilder(); connectionBuilder.Metadata = "res://*/AlcatrazModel.csdl|res://*/AlcatrazModel.ssdl|res://*/AlcatrazModel.msl"; connectionBuilder.Provider = "System.Data.SqlClient"; connectionBuilder.ProviderConnectionString = connectionString; _connectionString = …

12 c#  .net  dependency-injection  entity-framework  n-tier 

Entity Frameworkを少し使用しようとしていますが、レイヤーの分離に関する質問がありました。 私は通常UI-> BLL-> DALアプローチを使用しますが、ここでEFを使用する方法を知りたいです。 私のDALは通常、次のようなものです GetPerson(id) { // some sql return new Person(...) } BLL： GetPerson(id) { Return personDL.GetPerson(id) } UI： Person p = personBL.GetPerson(id) 私の質問は、EFが私のモデルとDALを作成するので、EFを自分のDAL内にラップするのは良い考えですか、それとも時間の無駄ですか？ EFをラップする必要がない場合でも、Model.esmxを独自のクラスライブラリ内に配置しますか、それともBLL内に配置してそこで作業するだけでいいでしょうか？ EFを自分のDAL内にラップする理由は実際にはわかりませんが、他の人が何をしているのか知りたいです。 したがって、上記の代わりに、DALを除外して、次のようにします。 BLL： GetPerson(id) { using (TestEntities context = new TestEntities()) { var result = from p in context.Persons.Where(p => p.Id = …

12 c#  entity-framework  layers 

私は最近、エンティティフレームワークのような強力なORMでリポジトリパターンを使用することに対して多くの議論を読みました。リポジトリパターンは作業単位機能とともにリポジトリに似た機能を組み込んでいるからです。 単体テストのような状況でパターンを使用することに対するもう1つの論点は、より汎用的な実装がIQueryableを活用するため、リポジトリパターンは漏れやすい抽象化であるということです。 リポジトリパターンの使用に反対する議論は私には理にかなっていますが、提案された抽象化の代替方法はしばしば混乱を招き、問題と同じくらいやり過ぎです。 Jimmy Bogardsのソリューションは、抽象概念を吹き飛ばすことと、彼自身のアーキテクチャを導入することの組み合わせのようです。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ リポジトリが不必要になっている別の例....しかし、私のアーキテクチャを使用してください！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 別の... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 私は、それ自体が設計されていない「過度に複雑な」リポジトリパターンアプローチの明確な代替物や代替物を見つけていません。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

ビジネスロジックでは、次のようなメソッドが定義されている場合があります。 User.ResetCourse(Course courseToReset) 問題は、ユーザーとコースの両方がEntity Frameworkプロキシオブジェクトであるということです。つまり、ユーザーまたはコースのいずれかのナビゲーションプロパティにヒットすると、それらのオブジェクトはIQuery可能ではないため、通常どおりに繰り返されるため、データベースに大きなヒットを引き起こす可能性があります。 これを解決するために、署名を次のように変更しました。 User.ResetCourse(MyDBContext db, Course courseToReset) つまり、データベースに直接クエリを実行して必要な変更を効率的に行うことができますが、データベースコンテキストをビジネスオブジェクトに渡すことは非常に間違っているようです。 その後、ユーザーにサービスレイヤーを移行しました。つまり、次のようなものがあります。 CourseService.ResetForUser(Course courseToReset, User forUser) このサービスには、作成時に挿入されたDBContextへの参照がありますが、現在のビジネスオブジェクトは、動作のない単なるデータバッグです（つまり、Anemic Domain Model）。 どうすればこれを回避できますか？

11 c#  entity-framework  domain-model  business-logic 

私が持っているProjectName.Coreすべての私のビジネスロジックと私のエンティティとその行動を含むライブラリを。現在、Entity Frameworkやその他のDALとはまったく関係がありません。これらのことを分離しておくのが好きだからです。Entity Framework構成（Fluent APIを使用）はProjectName.Infrastructureプロジェクトに常駐するため、エンティティをEFにプッシュできます。基本的には、オニオンのようなアーキテクチャの方向に向かっています。 ただし、ASP.NET Identityフレームワークをミックスに追加する場合、ApplicationUserエンティティをIdentityUserクラスから継承する必要がありますが、ApplicationUserクラスには他のエンティティとの関係があります。継承するIdentityUser際に、エンティティプロジェクトにエンティティフレームワークへの参照を導入しています。これは、そうしたくない1つの場所です。（Entity FrameworkベースのIDシステムを使用しているため）ApplicationUserエンティティプロジェクトからプロジェクトにクラスをプルするとInfrastructure、循環参照が発生するため、どちらにすることもできません。 これを回避する方法はありますか？ASP.NET Identityを使用しないことに加えて、2つの層の間のきれいな分離を保つことができますか？

11 asp.net-mvc  entity-framework  identity 

Linq2Sqlを使用したプロジェクトから出てくると、次の（より大きな）ものがEntity Frameworkの腕に私を押し込むかもしれないと思います。私はこのテーマについてある程度調べましたが、見つけられなかったのは、SQL Server Data ToolsとEntity Frameworkをどのように使用する/使用する/使用するかについての一貫した話です。 それらは完全に別々に構想されていたのですか？ それらは何らかの形で完全に直交しているのですか？ 両方が必要だと思う理由： SSDTは、「コンパイル済み」（チェック済み）で、バージョン管理が容易なSQLおよびスキーマを持つのに最適です しかし、SSDTの「移行/更新」の話は説得力がありません（私にとって）。「すべてを更新する」はスキーマでは問題なく動作しますが、データで動作する方法はありません（AFAIK）。 一方で、同様の問題が発生するかどうかを知るためにEFの移行を試みたことはありませんが、Up / Downビットは非常に便利に見えます。

11 entity-framework 

そうだった 長年にわたって、ソフトウェアソリューションを次のように整理してきました。 データにアクセスするビジネスを抽象化するデータアクセス層（DAL） ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー（BLL） ユーティリティ（Util）は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。 もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。 今のやり方 過去4年ほどの間、私はMicrosoftのEntity Framework（私は主に.NET開発者です）を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私のDALが使っていた仕事：データベースに対してCRUDを実行するビジネスを抽象化します。 したがって、通常、次のようなメソッドのコレクションを持つDALになります。 public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 次に、BLLでは、このメソッドは次のように使用されます。 public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } BLLには通常、さらに数行のロジックが適用されるため、これはもちろん簡単な例ですが、そのような限られた範囲でDALを維持するのは少し過剰に思えます。 DALを放棄して、単にBLLメソッドを次のように記述する方が良いと思いませんか。 public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns 

新しいMVC4 Webサイトを作成するための仕様が与えられました。最初はプロジェクトが大きくなりすぎないでしょうが、ビジネスが新しいアイデアを得るにつれて成長するのではないかと思います。 .NET 4.5 ASP.NET MVC4およびEFを使用して、移行を伴うコードファーストまたはデータベースを処理するためのSql Server Data Tools（SSDT）を選択する必要があります。 SSDTを使用すると、ソリューションの一部としてプロジェクト内のデータベースを制御し、dacpacファイルを使用して、開発から本番に至るまでのすべての変更を処理できます。MVC3のコードファーストの私の経験では、データベースオプションが限られているため、開発以外では使用しませんでした。モデルの変更時に常にDbをドロップするか、Dbの変更を手動で処理することになります。しかし、MVC4 Migrationsはそうではなく、更新をDbにプッシュできるようになりました。 したがって、私の質問は、開発における時間/労力の節約に基づいて使用するのに最も効率的ですが、スケーラブルで生産の変更を処理できるものです。コードファーストとモデルからデータベースを生成する機能が好きでしたが、移行の導入により本番環境で実行可能になりましたか？

11 c#  entity-framework  asp.net-mvc-4  codefirst