ダイアログをポップアップするクラスライブラリがありますが、これは悪い考えですか?
9 に答える
クラス ライブラリは、ビジネス ロジックを統合し、コードの重複を減らすことを目的としています。ダイアログは、プレゼンテーション レイヤーに表示する必要があります。そこで、より適切な方法を決定できます。
たとえば、クラス ライブラリが winform アプリケーションで使用されている場合、そのダイアログは Web サイトに表示されるダイアログとは異なります。
はい、それは悪い考えです。Windows サービスがライブラリを使用するとどうなりますか?
これで問題ないと私が考える唯一のシナリオは、クラス ライブラリがビジュアル ディスプレイ コンポーネント用であり、そのコンテキストでのみ使用される (つまり、ダイアログ ボックスと UI コンポーネントのみを含む) 場合です。
多くの異なるシナリオで使用されるクラス ライブラリを作成する場合、人間の介入を必要とするブロッキング呼び出しは望ましくありません。
セッションがインタラクティブかどうかを確認し、ポップアップの作成を選択できる場合がありますが、これはせいぜいハックです。
意図した目的を達成するために、ライブラリはできるだけ他のライブラリにバインドしないようにする必要があります。ライブラリがある種の gui ライブラリでない限り、ポップアップ ダイアログを使用しないでください。
ダイアログを表示するためのクラス ライブラリであれば、はい。他の種類のクラス ライブラリの場合は、いいえ。
ライブラリが行うべき正しいことは、「getInformationFromUser」や「showError」などのコールバックを取得することです。それがどのように行われるかを決定するのは、ライブラリの呼び出し元です。または、エラーを報告するために、例外を発生させるか、エラー コードを返す必要があります。
ライブラリがダイアログ自体を表示するには、ライブラリが GUI プログラムで使用されていること、使用されている GUI フレームワーク、ユーザーが理解できる言語など、多数の仮定を行う必要があります。これは間違っています、間違っています、間違っています.
それは非常に依存します。このクラス ライブラリに他の多くの GUI クラスが含まれている場合は、そうかもしれません。このライブラリにドメイン オブジェクトが含まれている場合、これは悪い考えのように思えます。
それは悪い考えだと思います。ただし、場合によっては、UI ロジックを再利用可能にしたい場合があります。その場合、別のライブラリでユーザー インタラクション コードを引き出すようにしてください。
私は悪い考えだと思います。非ビジュアル ライブラリ クラスの例については、QFileをご覧ください。これを使用すると、エラー ステータスを戻り値として報告し (例: if(!file.open(mode...)))、最後のエラーをアプリケーション フレンドリな列挙型 ( http://doc.trolltech. com/4.6/qfile.html#error ) および人間が読めるエラー文字列 ( http://doc.trolltech.com/4.6/qiodevice.html#errorString ) として、アプリケーションがダイアログを簡単にポップアップ表示するために使用できます。コンソールに追加したり、ログに追加したりします。
ご覧のとおり、このアプローチにより、アプリケーションがエラー メッセージの処理方法を決定する力がアプリケーションに与えられます。これは、ライブラリが現時点で適切と思われるものを作成するのではありません。
理論的には、GUI でのみ使用されることがわかっている 1 つの特定のアプリケーションでのみ使用される場合、害はありません。
しかし厳しい現実として、ライブラリはますます汎用的になる傾向があり、GUI ベースのアプリケーションだけでなく、あらゆる種類のアプリケーションでライブラリが必要になります。そのため、前もって計画を立ててライブラリでダイアログを禁止し、別の方法でエラー報告を処理することもできます。
これが私が思うことです:それがいくつかのUI機能を提供するUIモジュールである場合、クラスライブラリの主な目的に依存し、いくつかのダイアログやフォームなどが必要ですが、いくつかのサービスを提供するはずのライブラリである場合(ビジネスまたはデータアクセス) アプリケーションの他の部分に、ライブラリに UI 要素があってはなりません。