- ベストアンサー
【初心者】ダイアログについて
ダイアログには、「エラー・情報・警告」のタイプがあります。 また、ダイアログのメッセージ内容もそれぞれ違います。他にもボタンの数等・・・ そこで、あるダイアログを表示する際に、 データベースに、コードをキーとして、タイプ・メッセージ内容を格納して、そのダイアログを表示した方が良いのか? それとも、ローカル上のファイルで設定してダイアログを表示した方が良いのでしょうか? PS データベースが万が一落ちてしまった事を考えると・・・ 日本語が変で申し訳ないのですが、ご教授頂けると幸いです。
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
ダイアログのメッセージ管理ということでお話します。 質問者様が上げた ・データベースのテーブル上にコードをキーとしてメッセージを格納 ・ローカルのファイル(TextやXml等)にコードをキーとしてメッセージを格納 両方ともやろうと思えばユーザが変更できてしまいます。 前者に限ってはデータベースが落ちた場合メッセージの取得ができません。 ※システム的にもデータベースが落ちたら止まってしまうと思うが。 後者はファイルの中身を簡単に変更できてしまう。 これはメリットでもデメリットでもあります。 簡単に変更ができるのでメンテナンスがしやすい。 触られるのが嫌であれば、隠しファイルにすれば滅多な事でもない限り大丈夫でしょう。 提案として1つだけ。 開発環境がVBAなのかVB6なのかVB.NETなのかわかりませんが、メッセージをクラス化するのはどうでしょうか? エラー・情報・警告・問合せの4つほどクラスを分ければメッセージの混在も少しは回避できます。 VB.NETの場合はクラス化することでdllとして提供することが可能になり、それなりのツールで内部を除かない限りメッセージは全て見ることができませんし、見れたとしても変更はできないはずです。 VB.NET以外の場合はモジュールとなりますが、ソースを提供してあげない限りどのようなメッセージが存在するかわからないはずです。
その他の回答 (1)
私も、DBや設定ファイルにメッセージを持たせるような開発に色々と参加してきました。 メリットは、 1.再コンパイルをしなくても文言の変更ができる 2.文章の末尾や、漢字・送り仮名等のゆらぎを統一する為に、リソースを一か所で集中管理できる といったところだと思うのですが、 過去の経験から得た結論は、たいそうな仕組み・規約を用意してまでやるメリットがあるとは思えない、というところに今は(私個人は)落ち着いています。 こういう仕組みを用意している割に、コンパイルレスの文言変更を積極的に行っている開発に遭遇した事がない為です。 つまり、ローカルファイルに出す必要すらない、というのが私の考えです。納品後にダイアログの文言だけを変える可能性がどれだけあるかを考えてみれば良いと思います。 むしろ、横断的に全ソースまたは全画面をレビューするいわば文言品質管理者のような役割の人を設定してチェックさせる方が統一性を保てそうです。 DBや設定ファイルの仕組みを用意するからには、全開発メンバーに周知徹底させる(独自でメッセージボックスを作って埋め込みの文章をコーディングする事を絶対にしない)ことが要求されます。すると、それを遵守しているかどうかも見る必要があります(文言の為にそんな事をしているプロジェクトを見た試しがないです)。 メッセージIDの採番ルールを考えたり、どのメッセージがサブシステムをまたがって共通的に使えるかも洗い出さなければ、実際にはメッセージの文言変更もそう簡単にはできなかったりします。 あくまで一開発者の意見ですが、以上参考になれば幸いです。