アプリケーションの構造に関する一般的なアドバイスを探しています。
私が最近構築しているアプリケーションでは、クラス(以降の質問ではDataManagerと呼びます)を使用して、すべての個々のオブジェクトと関連するすべてのメソッドを保持し始めました。 DataManagerをシングルトンにすることで、他のすべてのクラスやフォームからDataManagerにアクセスできるようにし、個々のコンポーネントがサブスクライブできるDataManagerからイベントを発生させます。次に、コンポーネントはDataManagerにアクセスし、それに応じてUIを更新します。
アプリケーションのデータを管理し、すべてのUI要素が必要なデータにいつでもアクセスできるようにする中央クラスが存在するため、このようにしています。デバッグがはるかに簡単になり、アプリケーションがどのように機能するかを思い出します(後で再確認する必要がある場合)。
私の質問は、これは良い習慣ですか?そうでない場合、良い習慣は何ですか?私は自分のアプリケーション設計を改善しようとしているので、これについてのアドバイスをいただければ幸いです。
NB。この構造はC#winformsプロジェクトで使用しています。
私は通常、ソフトウェアを整理するための1つの真の方法(TM)だけではないと言って飛び込む最初の人です。それを説明するアジャイルフレーズは、あなたがMinimum Viable Product(MVP)を構築する必要があるということです。そこから、自分の持っているものを基にしてそれを改良し、完全な完全なニーズに適応させることができます。経験から、最初の印象(人とデザインの両方)が通常間違っているなど、いくつかのことがわかりました。
技術スタックに応じて、アプリケーションを構築するためのいくつかの確立されたパターンがあります。
これらのパターンは、変更をローカライズして分離するのに役立ちます。これにより、バグを見つけたり、脆弱性を導入したりする必要がなくなります。
とはいえ、使い捨ての小さなアプリケーションを作成しているだけの場合は、実際に考える必要はありません。機能させるだけで、不要になったら捨ててください。
シングルトンがうまくいかなかった私の話
Java Swingアプリケーションを継承しました。アプリケーションのコアロジックはすべてシングルトンのセットにありました。問題は、ユーザーが1つのページのドロップダウンの値を変更したとき、またはバックエンドがコントロールを更新すると、アプリケーションがフリーズします。チームが問題を切り分けて調査したところ、ドロップダウンが変更されたときに発生するイベントがあったことがわかりました。このイベントにより、シングルトンによって管理されている値の1つが更新されました、別のイベントを開始し、別のページの同様のコントロールを更新しました。その別のページには、さらに別のイベントを開始するトリガーがありました。一番下の行は、イベントがバックエンドを更新し、コントロールが更新され、コントロールが更新され、バックエンドが更新されました。コントロール... StackOverflowException
ができるまで。
このシナリオで学ぶべきいくつかのレッスンがありました:
この問題を解決するために、データモデルにバインドされた表示コードとデータの格納をバックエンドが処理するように変更を加えました。バインディングは、情報が実際に異なる場合にのみコントロールを更新しました。また、各シングルトンが実行する必要のある操作のインターフェースを導入し、依存性注入を使用して、必要に応じてフロントエンドコードにシングルトンを提供しました。静的アクセスを切断し、インターフェースを形式化することで、どこからでもアクセスできるため、シングルトンでコードを突き刺すという誘惑を取り除きました。