3

winformアプリケーションに関して私が読んだ質問のほとんどは、すべてのアプリケーションを含むメインフォームとしてフォームクラスを持ち、このメインフォームで Application.Run を呼び出します

メイン フォームのコードが成長し始めると、フォームはいくつかのユーザー コントロールに分割されます。

しかし、私を悩ませているのはここです。フォームとユーザー コントロールは UI コントロールのみであると想定されており、プログラムのロジックを含めることはできません。

しかし、アプリケーションを開いてからアプリケーションを閉じるまでのアプリケーションの存続期間を処理する「メイン フォーム」のアイデアには、依然として幅広い用途があります。

これを避けるために、私はプログラムロジックを、プログラムの別々の部分を管理する別々の静的な「マネージャー」クラスに提供しようとしました。そして、メインフォームを使用してそれらを管理します。

たとえば、次の「ThemesManager」クラスがあります

            public static class ThemesManager
            {
                public static void InstallTheme(string themefile) { }
                public static void ApplyTheme(Theme theme) { }
                public static void RemoveTheme(Theme theme) { }
                public static Theme[] GetThemes() { }
            }

そしてメインフォームで

            public class MainForm
            {
                void InstallTheme_Click(object sender, EventArgs args)
                {
                // Call THeme.Install
                }

                void RemoveTheme_Click(object sender, EventArgs args)
                {
                // Call THeme.Remove
                }
            }

現在、アプリケーションロジックは何とか分離されていますが、多くのクラスがそれらに依存しているほど多くの静的クラスでアプリケーションアーキテクチャを破壊していると思います。たとえば、テーマを表示するユーザー コントロールは、ThemesManager.GetThemes() を使用します。このようにOOPの基本的な概念を失っていると感じています

アプリケーションのメインコンポーネントまたはコントローラーとして「メインフォーム」を持たずに、UIからロジックを分離するために他にどのような代替手段が必要ですか

4

1 に答える 1

1

次のような設計パターンを使用できます。

  • モデル - ビュー - プレゼンター (MVP)。
  • モデル-ビュー-ビューモデル (MVVM);
  • モデル - ビュー - コントローラー (MVC)。

これらは、ロジック レイヤーをユーザー インターフェイス レイヤーから分離するのに最適です。ここでいくつかの例を見ることができます。これは Model-View-ViewModel (MVVM) 用で、私にとってはうまくいきます。

デザイン パターンの良いところは、コードをテストしやすくすることです。

于 2013-08-21T12:05:44.203 に答える