私にはかなりばかげているようです。何が得られないのですか？
4 に答える
5
アプリがビジネス レイヤーを呼び出して値のリストを選択する、このようなケースに遭遇しました。次に、ビジネス層は Dal を呼び出してデータ アクセスを行います。これらのケースの多くでは、パススルーを行うビジネス レイヤー メソッドの明白な理由はありませんが、将来的にビジネス ロジックやデータの処理などを追加する余地が残されています。また、アプリの分離を維持するのにも役立つため、テストがはるかに簡単になります。
したがって、1 行を維持すると言いますが、挿入、更新などがまだ 1 行または 2 行である場合は、検証とビジネス レベルのデータ処理をどこで行っているかを再考する必要があります。
于 2008-11-07T18:40:25.703 に答える
4
BLL が検証を実行したり、ビジネス ロジックを実装したりせず、常に 2 つのライナーのままである場合、それは非常にばかげています。ただし、これを行うと、おそらくビジネス ロジック レイヤーを使用するポイントを見逃しており、UI で検証を行っているか、UI または DAL にビジネス ロジックを追加していた可能性があります。検証を必要とせず、ビジネス ロジックを持たないアプリケーションはほとんどありません。
于 2008-11-07T18:19:22.937 に答える
2
Rob と Bullines は、これを行う必要性がより深い問題を示しているという点で多くの場合正しいですが、データ アクセス レイヤーに直接進むことが完全に理にかなっている正当な例もあります。データ アクセス レイヤーをラップするための無知なメソッド (またはさらに悪いことに、オブジェクト モデル全体) を作成することは、プログラマーが実行できる最も役に立たない作業の 1 つです。正当な理由がある場合は、ビジネス ロジック層を経由しないことに満足できます。
于 2008-11-07T18:38:28.657 に答える
1
ビジネス ロジックは BLL にある必要があります。BLL で "2 つのライナー関数" を使用することになった場合、そのビジネス ロジックを誤って DAL または UI に入れましたか?
于 2008-11-07T18:18:58.133 に答える