次のように、BLL (ビジネス ロジック レイヤー) のないASP.Net 2.0アプリケーションを使用することは "許容" されますか?
ビジネス ロジックがプレゼンテーションのコード ビハインドで完全に検証可能であっても、BLL は常に望ましいですか? BLL を使用しないことの潜在的な欠点は何ですか?
結果を理解する限り、それは許容されます。BLL を使用する主な理由は、アプリケーション全体でそのロジックを別の場所で再利用するためです。
プレゼンテーション コードにすべての検証ロジックがあると、アプリケーション内の他の場所での再利用が本当に難しくなります。
他のすべてと同様に、それは環境であり、システムの使用に依存します. 自問する必要がある質問は次のとおりです。
本当に怠惰に帰着します。UI からシステムを作り直すのにどのくらいの時間を費やしたいですか? ビジネス層がないということは、多くのページで UI のルールが重複する可能性があるためです。
これが概念実証、短いデモ、またはクラス プロジェクトである場合は、もう一度。簡単な方法をとってください。
許容できる？あなたが誰に尋ねるか、そしてあなたの要件が何であるかによって異なります。このアプリは、あなたと他の数人が使用する社内で 1 回限りのものですか? たぶん、これで十分です。それが、何年にもわたって成長し、維持される本番環境対応のエンタープライズ アプリケーションであることを意図している場合は、おそらく、維持可能なアプリを構築するためにより多くの労力を前もって投資することをお勧めします。
関心の分離は、保守可能なアプリを構築するための重要な設計手法です。プレゼンテーション、ビジネス、およびデータ アクセス ロジックをすべて組み合わせると、非常に壊れやすく、変更が困難なアプリケーション アーキテクチャになる可能性があります。
場合によります。ビジネス ロジックがクリック イベントとページの読み込みに含まれている場合は、受け入れられません。
ビジネス ロジックは DAL 内のどこかにあるようです (たとえば、ストアド プロシージャなど)。一貫性がある限り問題ありません。クライアントが常にSQL Server を使用することが非常に確実である限り、このアプローチは問題ではありません。
私は、ストアド プロシージャにすべてのビジネス ロジックを持っている同僚を知っています。彼のビューはほとんどシン クライアントからデータベース バックエンドです。彼は販売する製品で大きな成功を収めています。しかし、それは彼がそれに非常に一貫しているからです。
アプリケーションが一般的なものである場合、ビジネスロジックレイヤーは他の完全なアプリケーションでも使用できます。同様に、私は通常、CMS 関連の BLL クラスを他のアプリケーションで使用します。