EntityFrameworkを使用するためのパターン?
-
22-07-2019 - |
質問
Entity Frameworkに使用する代替パターンは何ですか?
私が知っているのは:
-
"平野" EntityFramework-別名Unity of Work
using (Data.Model c = new Data.Model()) { var z = c.Users.Where(x=>x.Name=='John'); }
-
リポジトリパターン
//Model implements IRepository User user = Model.Instance.Get<User>(u => u.Name == "John");
- 他に何がありますか
- ?
解決
見ておくとよい本は、Martin Fowlerの&quot;エンタープライズアプリケーションアーキテクチャのパターン&quot; 。
そこで彼は、DTO、作業単位、リポジトリパターンなどのデータを取得/マッピングするためのいくつかのパターンを経験します。私はそれを見なければなりません。
他のヒント
UI / controller / ServicesでEntity Frameworkを直接使用しているという前提に基づいて質問に答えます。
UI / Controllers / ServicesでEFを含むORMを直接使用すると、将来多くの問題が発生することが証明されています。それに加えて、アプリケーションを単体テストすることは、不可能ではないにしても困難です。
2番目のアプローチ、つまり「モデルはリポジトリを実装します」私の意見でも間違っています、なぜならモデルとリポジトリは異なる責任を持ち、「単一の責任」に基づいているからです。 SOLID原則の一部であるため、2つの概念を一緒にマージしないでください。モデルでアクティブオブジェクトパターンを使用する場合でも(推奨しません)、使用するORMからモデルを分離する必要があります。
最良かつ最も推奨される解決策は、パターンが示唆するように、非常に基本的なメンバーを持つIRepositoryまたはIRepositoryのようなインターフェースを持つことです。次のようなもの:
Interface IRepository<T> where T:class
{
void Insert(T entity);
void Update(T entity);
void Delete(T entity);
// if you don't want to return IQueryable
T FindById(object id);
IEnumerable FindXXXXX(params)
// if you prefer to return an IQueryable
IQueryable<T> Find(Expression<Func<T, bool>> predeicate);
}
一部のポピュラーbeleiveリポジトリはIQueryableを返さないことに注意してください。さらに、式とラムダの代わりにISpecificationの使用を検討できます。
ほとんどのエンティティにIRepositoyインターフェイスを実装する必要があります。このアプローチを使用すると、単体テストを記述するときにリポジトリをモックすることもできます。本番環境では、Unity、Ninject、Linfu、CatsleなどのIocプロバイダーを使用する必要があります。特定のIoCフレームワークへのカップリングを回避するために、Microsoftの共通サービスロケーターの実装を活用することもできます。
昔は、特定のビジネスドメインまたはサービス用に実装されたデータアクセスインターフェイスがありました。このアプローチの問題の1つは、ソースコードを追跡し、最終的には追跡すると、異なるデータアクセスサービスでコードが重複することになります。
作業単位の例にあるものと同様のコードを使用します。
さらに、オブジェクトをデータ転送オブジェクトにマップします。
このテーマに関する記事は多数ありますが、良い記事が必要な場合はリストが大幅に削減されます。 MSDN Magazineのこの記事 n層アプリケーションに特化したものですが、かなり優れています。しかし、あなたが構築しているものを言わないので、多分それは助けになるでしょう。
LINQ 2 SQLが代わりになる可能性があります。こちらが記事 UnityおよびLinq to SQL DataContextsによる依存性注入です。
UNITY- http://unity.codeplex.com/