グローバルは悪ですよね?少なくとも私が読んだものはすべてそう言っています。なぜなら、何かがいつでもグローバルの状態を変更する可能性があるからです。
ただし、クラスパラメーターに関しては少し厄介なDBオブジェクトがあります。以下のプロパティは、MS Access または SQL で自動的に機能するラッパー クラスのインスタンスです。そのため、EF やその他の ORM ではないのです。
Public Property db As New DBI.DBI(DBI.DBI.modeenum.access, String.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0} ;Persist Security Info=True;Jet OLEDB:Database Password=""lkjhgfds8928""", GetRpcd("c:\cms")))
コード自体には例外処理用の PostSharp があるため、条件付きで oledb エラーをログに記録し、Null の場合は DB を再初期化することで処理できると考えています。
これまでの解決策は、db をパラメータとして必要なすべてのクラスに継続的に渡すことでした。ほとんどのデータ クラスには、変更された inotifyproperty を個別に実装する構造から構築された共有の監視可能なコレクションがあります。これらの 1 つは、非同期的にビルドされます。コレクション プロパティは、非公開の Async buildCollection サブルーチンを起動する前に空かどうかをチェックします。
私はそれを学ぶ必要があるので、依存性注入を(まだ)使用していないことを考えると。グローバルプロパティはそんなに悪いですか?データが取り込まれたり保存されたりするすべての場所で Db が必要です。まったく必要のない唯一の場所は、View とそのコード ビハインドです。
これは顧客向けのプロジェクトではありませんが、堅固である必要があります。
どんなアドバイスもありがたく受け取った!!