平均的な N 層アーキテクチャ アプリケーションでのビジネス ロジック層の使用について、いくつか簡単な質問があります。
私は最終学年の大学プロジェクトを開発しており、Web フォーム プレゼンテーション レイヤー、ビジネス ロジック レイヤー、データ アクセス レイヤー、およびデータ レイヤーを使用しています。
1) ユーザー入力の検証を実行するのに最適な場所はどこですか? クライアント側の jQuery 検証やサーバー側の検証用の ASP.NET 検証コントロールなどでプレゼンテーション レイヤーを使用することは理にかなっていますが、多くの記事では、BLL で検証を実行するのが最善であると述べています。
2) 現在、私の BLL はかなり薄く、クラスの 90% は単に DAL へのインターフェイスとして機能しますが、最終的にはさらに多くのクラスが存在することはわかっています。私の DAL には、GetAllProducts()、GetProductsByCategoryID(categoryID)、GetProductByProductID(productID)、GetProductsBySupplierID(supplierID) など、エンティティごとに複数の選択コマンドがあります。これには、低レベルのビジネス ロジックが含まれているように見えます。つまり、技術的には、BLL のコードを使用してフィルター処理できる GetAllProducts() 関数が必要です。
このためのベストプラクティスについてどう思いますか? BLL でフィルター処理を行う 1 つの select ステートメント、または必要なデータを取得するために必要な数の select ステートメントでしょうか? 常にすべての製品を選択すると、大規模なアプリではリソースがかなり重くなると思いますが、少なくとも層の間にロジックの真の分離があります.
乾杯、スチュ。