データレイヤから適切な量の抽象化は何ですか？

Question

私は現在、アプリケーションの永続性フレームワークを工夫しています...抽象化のための2つのソリューションについて議論しています。

オプション1が最初に、そして簡単な（しかし、おそらくは複数のデータベースに結合された2層状のアプローチである。このアプローチでは、データ・マッパーは、データベースからデータを取得し、ビジネスエンティティを構築する。

ラフ図ワークフローの：

UserEntity <= UserMapper => Database 

オプション2秒、及びより柔軟な（しかし、可能なやり過ぎ）アプローチ3階層化アプローチです。このアプローチでは、我々は仕事だ第三の目的を持って、それは単にに話すことです。データベースを返し、aを返します。データマッパーにデータを送り、オブジェクトを作成します。

ラフ図：

UserEntity <= UserMapper <= UserDataRetriever => Database 

は明らかに最初のオプションの利点は、それが簡単で、作成することが迅速であるということです。 2番目のオプションの利点は、DataRetrieverのDB（および関連するクエリ）への接続を変更するだけで済むので、永続化メソッドを変更する方が簡単だということです。

このサイトのサイズが非常に高速になるので、アンチパターンの土地に入らずに、最も柔軟なオプションを選択したいと思います。

どちらが優れていますか？

Answer 1

は、私は次のように使用します。

リポジトリ自体は、vanilla ADO.NET、OR/Mマッパー、Webサービスなどを使用できます。

Answer 2

さて、オプション2ための図は少し複雑になります：

UserEntity <= UserMapper <= UserDataEntity <= UserDataRetriever => Database 

UserMapperが故にUserDataEntity、一つのタイプから別にマッピングしなければなりません。 UserDataRetrieverからUserEntityに直接マッピングすることは概念的には厄介です。あなたは番目のオプションについては、以下の図を暗示される可能性があります。[list of arrays]/UserDataEntity <= UserDataRetriever：

UserEntity <= UserMapper <= [list of arrays] <= UserDataRetriever => Database 

とにかく、オプション1はUserMapperは、それ自体での機能が含まれている方法で、ここで異なっています。

いずれのオプションもどちらも本質的に優れていません。これはエンティティの数と、永続性とドメインのレイヤー間のマッピングがどれほど簡単かによって異なります。

代わりオプション1.5を試してみたいことがあります：あなたの基本的なアプローチは、あなたが）とは別の、よく定義されたメソッドを持つデータを取得するためにUserMapperを設計同時に、オプション1であり、b）のデータをマップします。こうすれば、必要に応じて、リーンで始まり、これらのメソッドを別のクラスにリファクタリングする簡単な方法があります。リポジトリのマッピングを行うだろう

Entity <=> Repository pattern <=> DataSource 

（または内部マッピング層を使用）：