1

n 層アーキテクチャでは、オブジェクト リレーショナル マッピング (OR/M) コードを配置するのに最適な場所は、データ アクセス層です。たとえば、データベースのクエリと更新を NHibernate などのツールに委任できます。

それでも、NHibernate へのすべての参照をデータ アクセス レイヤー内に保持し、その下または上のレイヤーから依存関係を抽象化しておきたいと思います。そうすれば、別の OR/M ツール (Entity Framework など) または何らかのアプローチ (プレーンなバニラ ストアド プロシージャ呼び出し、モック オブジェクトなど) をスワップまたはプラグインすることができ、コンパイル時エラーやアプリケーション全体の大規模なオーバーホールを引き起こすことはありません。テスト容易性は追加のボーナスです。

OR/M を疎結合にして 1 つのレイヤーに含めるラッパー (つまり、インターフェイスまたは基本クラス) またはアプローチを提案してもらえますか? または、役立つリソースを教えてください。

ありがとう。

4

2 に答える 2

2

リポジトリパターンを探しているようです。さらにデカップリングが必要な場合は、制御の反転コンテナを使用してデータの依存関係を注入できます。

于 2010-03-26T21:28:07.453 に答える
0

サービスファサードパターンは1つの名前です。ビジネスロジックとデータ層の間の単純な契約。

サービスクラスまたはBean（必要なものと呼びます）は、コントラクトを定義および実装し、下位のデータレイヤーを調整し、多くの場合、データオブジェクト全体のトランザクションロジックを処理します。

Springでは、インターフェースを定義してから実装します。1つの実装はOR/Mであり、別の実装は生のJDBCまたはADO.NETである可能性があります。一部のフレームワークでは、アスペクト指向プログラミングを使用すると、コードを記述せずに宣言型トランザクションロジックを挿入できます。それは多くの頭痛を救います。

注意点：Hibernateのような一部のOR / Mを処理する場合、プロキシクラスが使用されます。プロキシクラスが問題を引き起こす場合がいくつかあるため、これは物事を汚染します。私の意見では、それはサービス層から逃れるべきではない実装の詳細です。しかし、Hibernateではそうなります。.NETの実装についてはよくわかりません。

于 2010-03-26T21:34:57.467 に答える