1

私は、stackoverflow のような自分の Web サイトを始めましたが、少しの技術的負債を返済しようとしています。契約開発者として、私は多くの場所に行き、この結果を達成するためのさまざまな方法を見てきましたが、私が行っている方法は..

プレゼンテーション (ウェブ)

ビジネス層 (昔ながらのエンティティ クラスと BL 層)

データ層 (DA クラスから SQL Server への Stored Proc 経由)

私の質問は、主にビジネス層に関するものです。現在、Entity 名前空間と BusinessLogic 名前空間があります。

BL には DA とエンティティへの参照があります。エンティティには DA への参照があります (DA は BL またはエンティティを「認識していません」)

私は本当に、データをエンティティに変換するすべての作業が BL 内、つまりビジネス ロジック内で発生することを望んでいます。ただし、エンティティが必要に応じて BL にアクセスできるようにしたいので、エンティティの DL への参照を削除します。

そう...

BL と Entity オブジェクトを同じ名前空間内に配置して、それらが連携できるようにするのは「間違っている」のでしょうか?

基本的に、私は Employee のようなエンティティ オブジェクト (典型的な例ですよね?) を持ち、Employee に

public Hashtable[] SubordinateEmployees

この従業員にレポートする他の Employee オブジェクトの Hashtable を返すプロパティ。しかし、必要になるまでロードしたくありません。そのため、ほとんどの従業員はプロパティにアクセスすることはありませんが、アクセスされると、DA を呼び出す BL への呼び出しでセルフロードされます。

質問は理にかなっていますか?

もしそうなら、私の解決策はありますか?

よろしくお願いします!

4

2 に答える 2

2

あなたの例が表すような状況に対処する通常の方法は、ファサードを使用することです。従業員オブジェクトから部下の従業員を取得しようとする代わりに、ビジネス ロジックへの呼び出しを使用して取得します。

hashtable = BL.GetSubordinateEmployees(supervisor);

そうすれば、部下への単一のアクセス ポイントが得られ、データ レイヤーにアクセスしてエンティティを作成するものは 1 つ (BL) だけになります。

于 2009-03-03T19:12:50.583 に答える