語彙の乱立
拙作の.NET Webクライアント用GUIフレームワークですが現時点で以下の種類の設定ファイルを使用しています。
[App.config(ビルド時にはアセンブリ名.config]
他の全ての設定ファイルの基点であり他の設定リソースへのパスを記述します。
GUIの基本部分を構成する語彙を記述します(メニューやイメージリソース等へのパス)。
.NETの標準的なconfigファイルです。(.NETの.configファイルで指定できる全ての語彙)
[components.config]
DIContainer+AOP用のコンポーネント生成と取得用の語彙を記述します。
(基本的にはSeasar2と同様の語彙を使用可能ですがOGNL対応とwebアプリケーション対応は不要なので省略してます)
[validation.config]
Java側(クライアント又はサーバサイド)のバリデーションと同様のバリデーションを行う為の語彙を記述します。
App.configとLog4Netは仕方が無いとしても4つの別々な語彙の設定ファイルを使い分けるのは開発した自分でも面倒だというのに実際にアプリケーションを開発して貰う周りのプログラマ達にとっては苦痛以外の何ものでもないだろうな、と反省してここ数日は実際に書いたテスト用の設定ファイルをじっと見ることが多かったのですが、ちょっとしたインタフェースの設計し直しで全てDIContainer経由でいけるのではないかと思ったのが昨日です。
例) App.configの専用セクションに記述しているForm(System.Windows.Forms)の構成
語彙を見ると大体どのような事を記述しているかは想像が付くと思いますが設定している内容の全てはGUI用のクラス、又はそれらに対応した適当なバウンダリ・インタフェースを用意することによりDIContainer経由で全て記述が可能であることが判ります。(AvalonやXAMLを待つ程余裕があれば良いんですが今は無理です)
DIContainer用設定ファイルで同様の記述を行う例
"642, 661"
"361, 282"
root
file
"file"
"Ctrl+F"
"ファイル(&F)"
一見してDIContainer用の記述の方が冗長ですが全ての設定において同じ語彙を運用できるというのは非常にメリットが大きいですしDIContainer用の記述に統一することによりテストが容易になるでしょうから全てこの方法で統一しようかな、と計画しています。
少し前からJavaでも.NETでもこのように独自のXMLの語彙を用いて設定ファイルを記述するのが当たり前になっていますが私のようなボケは別にして複数のソフトウェアを使用している場合には私と同様の「語彙乱立問題」等の問題が発生するのでXMLの採用に慎重な方も最近多いですね。
