私は完全なアマチュアで、フォルダーの変更を追跡するための小さなアプリを作成しています。グリッドビューにバインドされた1つのデータテーブルで監視するディレクトリに関する情報を保持すると思います。ユーザーがボタンをクリックすると、プログラムはFileSystemWatchersを作成してディレクトリを監視し、イベントメッセージを別のデータテーブルに送信します別のグリッドビューにバインドされています。OOP の広い世界のどこで、データテーブルを宣言、開始、および操作する必要がありますか? メインフォーム、メイン内、クラス内、または「あきらめて」Visual Studioを使用して、DataSetを自動的に作成し、2つのテーブルをそこに貼り付ける必要がありますか?
2 に答える
コースの馬。小さなユーティリティ アプリの場合は、VS の "Visual/RAD" スタイルのプログラミングを使用する方がよいでしょう。たとえば、ほとんどのチュートリアルが示すように、テーブルなどをフォームにドラッグ アンド ドロップします。
厳密に言えば、大規模なアプリの場合、データ アクセスを処理する別のアセンブリ (.dll) を作成し、そのアセンブリ内のクラスをメイン フォームから呼び出すのがより正しい方法です。この概念は多くの用語に当てはまりますが、事実上、懸念事項を分離する必要があります。つまり、UI で UI の対話を処理し、別のアセンブリ/プロジェクト/データベースの対話性を処理するものと、別の別のアセンブリ/プロジェクト/ビジネス ロジックを処理するものなどを用意します。
最後の数文は、人によって意味が異なる可能性があり、物事を行うための 100% 正しい方法はありません。
役立つかもしれないいくつかの記事:
KiwiBastard に同意します。VS ツールを使用して型指定された DataSet を生成すると、かなりのメリットが得られます。
ただし、それはクラスを生成するだけです。DataSet のインスタンスを管理する必要があります。UI とビジネス ロジックを別のクラスに分解していない非常に単純なアプリの場合は、フォームでそれを行います。どんなに複雑なアプリでも、それはビジネス ロジック クラスの一部です。
おそらく多くの問題を解決してくれるでしょう: データ バインディングは優れており、ADO も優れていますが、特定の種類の ADO コード (特に DataTable のイベント ハンドラー) はデータ バインディングでうまく機能しません。BindingSources を使用している場合 (そして実際に使用する必要があります)、DataSet のオブジェクトをプログラムで操作するとき (行を追加および削除するときなど) は常にバインドを一時停止することをお勧めします。バインディングの一時停止と再開のコストは非常に小さく、診断が非常に困難なクラス全体の問題を排除します。