私は実装しているフローチャートを持っていて、ユーザーの入力と処理結果に応じて4つまたは5つのパスがあります。当然、私はこの論理をWindowsのフォームですべて望むわけではありません。クラスのメソッドをフォームで呼び出すだけです。ビジネスロジッククラスでSystem.Windows.Formsを参照し、ダイアログとメッセージボックスを表示して、処理して結果を返すために必要な入力を得ることは悪い設計ですか？ビジネスロジックオブジェクトで入力を求めるプロンプトが表示されるのは悪い設計ですか？
はい、これは悪いデザインです。あなたのクラスはフォームと通信してデータを取り戻す手段を提供する必要があります。イベントを作成してFormに登録し、カスタムEventArgsクラスからダイアログを作成するための情報を取得するだけです。それが入力を取得した後、同じクラスを2番目のイベントを介して追加情報とともに押し戻すだけです。
これはMVPパターンに似ています。
はい、これは悪い考えです。事実上、ビジネスロジックをプレゼンテーションと密接に結びつけています。他の状況ではビジネスロジックを簡単に再利用できるため、ビジネスロジックに触れることなくUIを置き換えることはできません。
UIレイヤとビジネスロジックレイヤが通信し、UIレイヤがUIを処理できるようにする必要があります。
悪いデザインだと思います。アプリケーションのコンポーネントを分離する場合、経験則は、それらを別々のコンピュータで実行できるように十分に分離しておくことです。
はい。なぜなら、あなたのビジネスシーンのオブジェクトは単にビジネスオブジェクトではないからです。
MVVMパターンを使用し、ロジックをviewmodelに入れます。
私はMVCがWinFormsの方が適切だろうと思っていますが、正確なパターンは十分に検証されたパターンを使用するよりも重要です。 –
イベントベースのMVPパターンもオプションだと思います。ビューはイベントを起動し、プレゼンターは魔法のような神秘的な方法でそれらを処理します。 – nick
UIやUIがまったくない状況（ビジネスプロセスやバッチプロセスなど）でビジネスロジックを実行する必要がある可能性があるため、設計が間違っています。それがビジネスロジックとUIの分離です。可能であれば、必要なユーザー入力をすべてUIクラスで手に入れてから、ビジネスロジックに渡す方がよいでしょう。ただし、ビジネスロジックのプロンプトで詳細を確認する必要がある場合は、ビジネスロジックAPIがコールバックメソッドデリゲートを受け取り、それを呼び出してさらに入力を要求する方がよいでしょう。次に、UI層は、ユーザからどのように要求するのが最適かを決定することができる。
MVPパターン私は信じていませんか？ – nick
これは私の最初のやり方でした。私はちょうどそれを検証するために誰かを探していたと思います。ありがとう。 – Keith
はい、これは真実であるはずです。しかし、私はその例がより適していると思う、私はそれを言及すべきだった。 – Femaref