1

データアクセスコードをビジネスオブジェクトから切り離すことは新しいことではありませんが、私は常に何かを達成するための「最良の方法」を探しています。

私は次のクラスを持っています：

オレンジ-これは私のビジネスオブジェクトです。

OrangeList-これはオレンジのリストです。

ユーザーは、OrangeList.Fetch（someCriteria）を呼び出して、データストアからOrangeオブジェクトをフェッチします。したがって、OrangeListにはデータアクセス層への参照が必要です。つまり、プロパティはIDataProviderMyDataProviderです。

これは私にとってはうまくいきますが、問題は、単一のOrangeを単独でフェッチできないことです。常にOrangeListを経由する必要があります。

そのいずれか、またはOrangeとOrangeListの両方は、DataProviderを保持するいくつかの共通オブジェクトから派生する必要があります。

これは問題ですか、それとも私のアプローチはそもそもマークから外れていますか？

ヒント/ポインタはありがたいです、ありがとう。

編集：以下の議論に照らして、私はリポジトリパターンをチェックアウトしました。

ただし、私のプロジェクトでは、リポジトリをDALからさらに分離することをお勧めします。

SO ....リポジトリは、私がオレンジを取得し、オレンジを保存する方法ですが、それでも方法がわかりません。私はそれをIDataProviderに委任します。これは、図にリストされているものの数である可能性があります。

明確にするために-オレンジはそれ自体をフェッチ/更新する方法を知りませんよね？それは純粋なビジネスオブジェクトです-そしてそれがポイントですか？

代替テキストhttp://img22.imageshack.us/img22/2460/repositorya.jpg

ご参考までに、私の「LegacyDataProvider」は、ファイルベースのデータベース（FoxPro、eek）にアクセスするOLDシステムをサポートすることですが、これでこれをまとめて、新しいコードから腕の長さに保つことができます。

.NETアセンブリの構築に関しては、循環参照を防ぐために、Repository.DLL [OrangeRepo]、DataProviderInterface.DLL [IDataProvider]、およびBusinessObjects.dll[Orange]があるように見えます。すべて良いですか？

その時、私はリポジトリのアイデアを思いついたのですか？

4

3 に答える 3

2

リポジトリパターンを提案します

于 2009-04-10T22:40:27.490 に答える
1

私は、データアクセス層のインターフェイスオブジェクトも構成するマスターAPIオブジェクト（OrangeCart？）からこれらすべてのものを構成します（そして実行します）。OrangesとOrangeListsは、それらがOrangeCartに属していることを認識しており、DAL操作のためにOrangeCartと通信します。

于 2009-04-10T22:44:15.127 に答える
0

OrangeList（someCriteria）ではなく、Oranges.Criteria1List、Oranges.Criteria2Listがあります。シングルトンの場合、Oranges.GetItem（orangeId）があります。

それを自分のやり方で行うと、BusinessObjectは、概念的な用語ではなく、論理的なデータ設計の用語で考える必要があります。

（リポジトリの実装は私に同じ不快感を引き起こします-それらが使用されるのは、テーブルの上に薄い抽象化のシックコードレイヤーを配置することだけです。データなどのデータベース実装の詳細について知る必要があるBLは好きではありませんタイプとサイズ。これらの種類の依存関係を切り離すと便利なことがよくあります。）

于 2009-04-10T23:18:01.473 に答える