3

そのため、最近本番環境に導入したプロジェクトで、データ アクセスを再設計して遊んでいます。

リポジトリと作業単位のパターンについて読み始めたところ、興味をそそられました。これまでTDDを使用したことはありませんでしたが、試してみようと思いました。

私が取り組んでいることは重要ではないので、理解を深めるための趣味です。

何かが機能していますが、マークを完全に逃したかどうかを確認したいです。これが私が持っているものです...（簡単にするために、ソリューションの名前の代わりにSlnを使用します）

Sln.DataAccess
+ Entities
  + Person.cs (contains the model definition of a Person)
  + IIdentifiedObject.cs (just an interface demanding a (Guid)Id property)
+ Repositories
  + IRepository.cs[1]
+ IUnitOfWork.cs[2]

Sln.DataAccess.Memory
+ PersonRepository.cs[3]
+ Context.cs[4]
+ GenericRepository.cs[5]
+ UnitOfWork.cs[6]

Sln.DataAccess.Sql (I suppose this could be Sln.DataAccess.EF but anyway...)
+ PersonRepository.cs
+ Context.cs
+ GenericRepository.cs
+ UnitOfWork.cs

Sln.Test
+ Various unit tests.

SQL Context/Repository/etc... は、メモリ内リストではなく Entity Framework を介してデータベースにアクセスすることを除いて、基本的にすべて同じです。

私が尋ねている本当の質問は、Repository/UnitOfWork パターン全体のマークを逃したかどうか、または私が持っているものを改善できる場所を誰かが提供できる提案があるかどうかです。

ここにソースファイルがあります。

4

2 に答える 2

1

リポジトリを作成する標準的な方法はありません。何かを抽象化することを意図していますが、人によって異なるものになる可能性があります。一般的なクエリ メソッドを使用する人もいれば、レポ自体に特化したクエリしか使用しない人もいます。

最初にユースケースを考えて、それらのユースケースで機能するようにリポジトリを設計します。アドレス帳アプリケーションを設計し、リポジトリが必要な機能を便利な方法で提供できるかどうかを考えてください。

于 2012-04-25T18:46:31.683 に答える
0

わかりましたので、私が望んでいたことを達成しました。

私が作成した Git のこのプロジェクトを参照してください (開いている必要があります)。

Sln.DataAccess アセンブリには、データが実際に格納される方法への参照はまったくありません。その中にクラスはなく、オブジェクトにアクセスできる方法とそれらのオブジェクトの構造を定義するインターフェイスだけです。

永続化の実際の手段 (インメモリまたはデータベース) は、それぞれのアセンブリの外部から完全に隠されています。

https://github.com/bmckenzie/projects

修正したいことの 1 つは、Set<>()メモリ内の Context クラスのメソッドです。こちらをご覧ください: https://github.com/bmckenzie/projects/blob/development/Projects.DataAccess.Memory/Context.cs

誰か提案があれば、私はむしろそれを避けてif() {}、ある種の辞書を使用したいと思いますか?

于 2012-04-26T18:43:13.503 に答える