2

特定のロジックがデータ アクセス層とビジネス ロジック層のどちらに属するかについて、同僚と議論しました。

シナリオは、BLL が動作するデータを必要とすることです。そのデータは主にデータベースに存在します。そのデータを (System.Runtime.Caching を使用して) キャッシュして、後続の要求ですぐに利用できるようにします。アーキテクチャは、DAL と BLL が同じボックスと異なるアセンブリ (同じソリューション内のプロジェクト) に存在するようなものです。そのため、ワイヤーを介して DAL をヒットするなどの懸念はありません。

私の主張は、キャッシュをヒットするかデータベースをヒットするかの決定は、DAL の問題であるということです。ビジネス ロジック層は、データがどこから来るかを気にする必要はなく、必要なデータを取得することだけを考えるべきです。

彼の主張は、データアクセスレイヤーは「純粋」で「愚か」であるべきであり、キャッシュとデータベースのどちらをヒットするかを決定するロジックは、ビジネスロジックレイヤーにある必要があるというものです。

私の意見では、彼が言っていることは、関心の分離を弱体化させ、目標が物事を疎結合に保つことである場合に、レイヤーをより緊密に結合させることです。データの移動先を決定する特定のプログラム/UI 関数である場合、BLL がこれを制御したい場所がわかりますが、ここではそうではありません。これは、データベースがプライマリ データ ストアである非常に単純なキャッシュ シナリオです。

考え？

4

5 に答える 5

1

私はあなたに100％同意します。

キャッシュは DAL の一部であり、BLL には属しません。

例として hibernate を取り上げましょう。キャッシュ システムを使用してエンティティを格納します。Hibernate は責任を負い、キャッシュを制御する方法を知っています (ダーティ リード、データのフラッシュなど)。

このすべての低レベルのデータ ロジックで BLL を乱雑にしたくありません。

よろしく

于 2011-08-25T14:57:01.197 に答える
0

私の最初の反応はあなたの反応と同じで、データレイヤーに情報をキャッシュさせます。これは、データベースの変更をサブスクライブする戦略と統合したり、データを最新の状態に保つためにポーリングを実装したりすることもできます。

ただし、他のプロジェクトでデータレイヤーを再利用する場合、またはそうでない場合でも、キャッシュの決定を処理するために、既存のビジネスレイヤーとデータレイヤーの間に新しいビジネスレイヤーを実装することは悪い考えではありません。最終的に、キャッシングは単なるパフォーマンスの問題ではないため、並行性やその他の問題に関するビジネス上の決定が含まれます。

n層システムはまさにそれであり、物事を分離したいレベルの数に制限はありません。

于 2011-08-25T14:51:48.843 に答える
0

ビジネスロジックをデータから分離する全体の目的は、ビジネス要件やテクノロジーの変化に応じてそれらを交換できるようにすることです。それらを混合することによって、あなたはこの論理を打ち負かしているので、理論的なレベルではあなたは正しいです。しかし、現実の世界では、もう少し実用的である必要があると思います。アプリケーションの実際の平均余命はどれくらいですか、テクノロジーが変更される可能性はどのくらいですか、そして2つをきれいに分離するためにどれだけの余分な作業が必要ですか？

于 2011-08-25T14:49:32.147 に答える