標準の3層アプリケーションでの作成などの代替案とベストプラクティスは何でしょうか。
UIの場合：
-フォームの読み込み時に1つのBLLオブジェクトを作成する必要がありますか、それともBLLメソッドを呼び出す必要があるたびにインスタンスを作成する必要がありますか？
BLLの場合：
-BLLコンストラクターで新しいDALオブジェクトを渡す必要がありますか、それともすべてのメソッドでdalを作成する必要がありますか？
DAL：
現在、私のDALは、従来、oledbを使用してAS400に接続するように開発されており、ado.netを使用して必要な操作を行っています。すべてのメソッドは、実行コマンドの完了後に接続を開いたり閉じたりします。
-これでいい？または私は何か他のものに従うべきですか？
私の要件には、UIを柔軟に使用できる可能性があり、UIの実装（Webページ、WinFormsなど）のほとんどすべてのケースに対応できます。
オプションの場合は、依存性注入を利用します。これにより、レイヤーをテスト可能で緩く結合した状態に保つことができます...良いことです。サービスを使用している場合は、これがビジネスロジックに適した場所である可能性があります。
その後、BLLはDLLをインスタンス化するか、さらにはDLLを挿入することができます。db接続を開いてすぐに閉じるのは良いことだと思いますが、接続プールを利用できるように、ドメインアカウントなどを使用していることを確認してください。
要件にはUIの柔軟性が含まれているため、MVPパターン（Model-View-Presenter）を検討することをお勧めします。これにより、WinForms、WebForms、またはその両方をフロントエンドとして使用できるようになります。このような状況では非常に柔軟であるため、これが深刻な要件である場合は、これを強くお勧めします。
これは、高レベルの質問に対する高レベルの回答であり、自由に使用できるオプションがたくさんあります。これはただ一人の人の考えです。詳細が必要な場合はお知らせください。
オブジェクトを作成して、スタンドアロンで使用したり、モックしたりできるようにします。「実際の」DBに依存せずにUIをテストできることは常に素晴らしいことです。BLLがDALのインターフェースを受け入れるようにして、実際のDBなしでモックしてテストできるようにします。
NinjectやAutoFacのような依存性注入について読む必要があります。これらは、各オブジェクトにパラメータを渡すのに役立ちます。
DALの1つの実装でのみ機能するBLLになってしまうと、それは良くありません。別のレイヤーに影響を与える場合、1つのレイヤーで変更を加えるのは非常に困難です。
アプリケーションの一部がDBに大量の要求を行う可能性があり、この応答をWebページにキャッシュしたくないがWebフォームにはキャッシュしたくないと感じている場合があります。データを取得するためのインスタンスが1つしかない場合、UIレイヤーを使用せずにキャッシュ機能を設計することは困難です。毎回新しいインスタンスを作成する場合、たとえば、元のインスタンスをキャッシュ機能だけでラップする1つのDALを作成できます。代わりにキャッシュDALを使用するようにWebアプリに簡単に指示できる場合。
使用するたびに新しいオブジェクトを作成します。