- PR -

設定情報の保存法について

投稿者投稿内容
ほげた
ベテラン
会議室デビュー日: 2002/05/08
投稿数: 67
お住まい・勤務地: なごやん
投稿日時: 2005-11-13 05:50
引用:

刹那さんの書き込み (2005-11-12 16:07) より:

2, シリアライズを利用する
Imageに[System.Xml.Serialization.XmlIgnoreAttribute]を付けてImageFileという新しい項目を作りシリアライズ。
デシリアライズ後にImageFileの値からImageを作成。

Imageがかなりあるので余計な文字列変数が大量になる…きれいなコードとはいえないかなと思う。


の改良系ですが・・・

まずImageとファイル名をまとめて扱うクラスを作成します。
 ・ImageFileという新しいクラスを作成し、そこにImageとファイル名をもたせる。
 ・ImageはIgnoreしておき、ファイル名などの必要な情報だけシリアル化。
 ・デシリアライズ時は読み込み後にイメージを読み込む。

skinクラスにImageがたくさんあるのならば、
 ・ImageFileクラスのコレクションImageFileCollectionを作成
 ・ImageFileCollectionのインデクサでは引数に応じたImageFileのImageを返す
 ・skinクラスにはImageFileCollectionをフィールドとしてもたせる
 ・ImageFileCollectionをImagesプロパティとする
とすると以下のように使えますね。

コード:
 Image image = skin.Images["hoge"];


ところで、最初に「速度面の問題から」とありますが、iniファイルの読み書きが
xmlファイルの読み書きよりも遅いってことですか?
笊頭刹那
ベテラン
会議室デビュー日: 2005/10/17
投稿数: 55
お住まい・勤務地: オーストラリア
投稿日時: 2005-11-13 14:43
>Jubeiさん
なるほど、DataSetの使い方示していただいてありがとうございます。
んーやはりファイル名を指定したいですね(汗。

>ほげたさん
それは一応考えました、ただシリアライズ・デシリアライズで作られるXmlがどのようなものになるのか分からないので…今のところ一番有力な方法ですが。

イメージのインデクサは思いつきませんでしたね、ですが
Skin.Active.Header.Image
SKin.Active.Footer.Image
Skin.Inactive.Image
のように別れているのでそれを指定するのはインデクサでは難しいような気がします(これに関する説明書いてませんでしたね、すいません汗)また別の機会に使用させていただきます。

INIファイルを読み込むAPIが遅いとのことです、実際に確認はしていませんが前回作ったソフトの状態を見ると修正すべき点と思われました。自分で読み込みクラス作ればいいんですがね(汗、Xmlが推薦されているということもあり使ってみようと思ったわけです。

ここまでで新たな疑問出てきたのですが、スタイルファイルなどは
1, INIやXMLなどのテキストファイルで記述
2, 独自のエディタで記述→バイナリ形式
3, 独自のエディタで記述→テキスト形式
のどちらがいいのでしょうか?バイナリのほうが速度面では速いですが…そこまで必要なスキンじゃないです。
速度に関しては妥協できるのです(INIは極端に遅いとのことなので妥協しかねますが)
スキンなど作ったこと無いので今までの経験からこっちのほうがいいよという意見があればご教授願いたいです。条件として「簡単に作成可能である」「コーディングが簡単である(スキン考えてる時点で飽きたらもともこも無いのでw)」
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2005-11-13 15:54
引用:

1, 力技で読み込む
コード:
skin.Width = int.Parse(dc.GetElementsByTagName("Width","")[0].Value);
skin.Size.Width = int.Parse(dc.GetElementsByTagName("Width","Size")[0].Value);
...


コーディング大変ですよね…



同じ力業にしても、SelectSingleNode や SelectNodes を使ってみるとか。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-11-13 16:48
引用:

刹那さんの書き込み (2005-11-13 14:43) より:

INIファイルを読み込むAPIが遅いとのことです、実際に確認はしていませんが前回作ったソフトの状態を見ると修正すべき点と思われました。
自分で読み込みクラス作ればいいんですがね(汗、Xmlが推薦されているということもあり使ってみようと思ったわけです。


そりゃ何度も読み出せば読み出すほど、GetPrivateProfileString 関数の方が不利になりますよね。
読み込む時にキャッシュを作っておくとか、セクション単位で読むなどの工夫をしないと。

引用:

ここまでで新たな疑問出てきたのですが、スタイルファイルなどは
1, INIやXMLなどのテキストファイルで記述
2, 独自のエディタで記述→バイナリ形式
3, 独自のエディタで記述→テキスト形式
のどちらがいいのでしょうか?バイナリのほうが速度面では速いですが…そこまで必要なスキンじゃないです。


速度ではなく保守性を重視しましょう。
やはり、XML でしょう。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-11-14 06:32
引用:

刹那さんの書き込み (2005-11-12 19:44) より:
>Jitta
…すいませんおっしゃっている意味がよく分からないのですが(汗。

スキン情報ファイルをXml形式で書くとぱっと見てどれが何の値か分かりにくいのでスキン情報ファイルにXmlファイルを使用するというのは目的に合わない

という意味ですか???

あ、今書いてて思いましたがシリアライズで画像をBase64で行う場合って意味ですね、きっと…?


 SerializeAttribute で XML 化 するのと、ISerializable インターフェイス を実装して SoapFormatter で SOAP-XML 化 するのとでは、できあがった XML の形式が違います。

SOAP-XML では、リモートでオブジェクトを転送するため、循環参照しているオブジェクトであってもシリアライズできます。そのため、参照などを解決するための記述に置き換わるため、意図しない要素が多数紛れ込みます。
 一方、属性によるシリアライズでは、パブリックで読み書き可能なフィールドおよびプロパティという制約はつきますが、属性で指定したとおりの XML ができあがります。
 どちらも、バイナリを可視テキスト化して保存することが可能です。

 SoapFormatter の話が出ているので、「SOAP-XML では、外部の人間が特定の値を変更するのは困難」という意味で書きました。


 出てきた案は、採用する、しないにかかわらず、テストアプリ作って確認しておくといいですよ。次の時の選択肢が増えますから。


 ついでに、.NET Framework 2.0 で、アプリケーションプロパティを簡単に外出しできますが、同じ理由で、あまりお薦めしません。もっとも、エンドユーザがさわらないのなら、お薦めします。
___________________________________________________________________
□ written by Jitta on 2005/11/14
□ Microsoft MVP :Visual Developer ASP/ASP.NET Oct.2005-Sept.2006
_________________
笊頭刹那
ベテラン
会議室デビュー日: 2005/10/17
投稿数: 55
お住まい・勤務地: オーストラリア
投稿日時: 2005-11-14 12:39
>じゃんぬさん
保守性、人間に分かりやすいのはINIのほうだと思うのですが。XMLの場合タグを使った入れ子なのでぱっと見では分かりにくいと僕は感じます(人それぞれでしょうが)
っと、この意見がかなりじゃんぬさんの言いたいこととずれている気がします(汗。保守性=メンテナンス性=どれほどメンテナンスが行いやすいか=人間に理解しやすいか?と解釈したのですが…間違いがあればご指摘ください。

>Jittaさん
なるほど…ぜんぜん知らなかったです(汗。
と、いうか
---------------------------------------------------------------------------------
出てきた案は、採用する、しないにかかわらず、テストアプリ作って確認しておくといいですよ。次の時の選択肢が増えますから。
---------------------------------------------------------------------------------
が刺さりました、いや悪い意味じゃないです、そのとおりじゃんって(笑。
なかなかテストアプリ作るのも大変なんですがね、今後作っていくようにしたいと思います、ご忠告ありがとうございました(*´∇`*)
笊頭刹那
ベテラン
会議室デビュー日: 2005/10/17
投稿数: 55
お住まい・勤務地: オーストラリア
投稿日時: 2005-11-14 12:51
うぁすげぇ…実験してみましたSoapFormatter

確かにこれはちょっと分かりにくいですね(汗。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2005-11-14 12:54
引用:

保守性、人間に分かりやすいのはINIのほうだと思うのですが。XMLの場合タグを使った入れ子なのでぱっと見では分かりにくいと僕は感じます(人それぞれでしょうが)
っと、この意見がかなりじゃんぬさんの言いたいこととずれている気がします(汗。保守性=メンテナンス性=どれほどメンテナンスが行いやすいか=人間に理解しやすいか?と解釈したのですが…間違いがあればご指摘ください。



間違いでは無いと思いますが。。。

.ini がシンプルなのはそのとおりですが、その代わり「出来ること」の限界も相当低い位置にあります。

XML はタグがごちゃごちゃして見難いかもしれませんが、構造化データを簡単に記述できるなど、.ini には到底出来ないことが簡単に実現できます。

「その割には」簡単かつ可読性があるというのが XML の利点です。

スキルアップ/キャリアアップ(JOB@IT)