親コントロールにアクセスして、そこに含まれるコントロールを自由に操作することは技術的に可能ですが、親コントロールの構造を変更すると、含まれているすべてのコードが壊れるため、コードの保守が非常に困難になります。ページ。これは非常に密結合の設計と見なされ、多くの場合脆弱です。
ややクリーンな設計は、[保存] ボタンが押されたときにページ クラスでイベントを発生させることです。次に、親フレームはイベントをシンクし、保存操作の後に更新する必要があることがわかっているものを更新できます。コンポーネントがより疎結合になるため、保守が容易になりますが、多くのデータベースの知識が GUI コンポーネントに組み込まれます。このような設計は、多くのメンテナンスや将来の拡張を予定していない比較的単純なアプリに適している場合があります。
私が好む設計パターン (多くの開発者がそうであるように) は、簡単にテストできる単純なプログラム インターフェイスを使用して、データベース処理とビジネス ロジックを 1 つまたは複数のクラス内に分離することです。GUI コンポーネントは、必要に応じて簡単に変更できるように、可能な限りシンプルかつ薄型に保たれています。これは、Model-View-Controller パターンと呼ばれることがよくありますが、他の名前もあります。あなたの例では、ビジネスロジックをカプセル化する「コントローラー」クラスには、情報の読み取りと設定のためのプロパティとメソッド、および変更をデータベースに書き込む「保存」または「コミット」メソッドがあります。保存が完了すると、すべてのコントロール (「ビュー」) に通知する「保存済み」または「変更済み」イベントが発生します。