設定ファイルについて

環境/言語:[ＸＰ　ＮＥＴ２００５]
分類:[.NET]

こんにちは。

アプリケーションの作成にあたって設定ファイルの扱いについて悩んでいます。

設定ファイルを外部(ini or config）に持たせてアプリを作成しようと考えています。
ここで、設定ファイルの扱いについて悩んでいます。

今までは最初のsub main()で設定ファイルを読み込むメソッドを作成して、
エラーチェック等をして構造体orクラス（メモリー上？）に持たせていました。
この為に画面が複数あった場合などの為にpublicなモジュールに構造体の変数を
持たせていましたが、オブジェクト指向的に間違っている気がしています。

iniファイルやconfigファイルの取得方法は調べれば見つけれたのですが、
アプリ上での設定ファイルの位置（モジュール構成？）のような考え方が探しても見つかりませんでした。

ご相談に乗っていただければと書き込みしました。
よろしくお願いします。

文章がながながとなりましたが下記のような感じになると考えています。

１．アプリ起動時にまとめて、クラスや構造体に取り込んでメモリー上に持たせる

２．必要な時に必要な情報を設定ファイルからとってくるか

３．その他の方法？

以上

> 今までは最初のsub main()で設定ファイルを読み込むメソッドを作成して、
> エラーチェック等をして構造体orクラス（メモリー上？）に持たせていました。
> この為に画面が複数あった場合などの為にpublicなモジュールに構造体の変数を
> 持たせていましたが、オブジェクト指向的に間違っている気がしています。

　　複数あるからこそ、一意に管理する必要があるのでは？

　　次に、Public と言うかGlobalがダメなら、Form.Tagに渡して
　　連携させる方法もあるかと。

> iniファイルやconfigファイルの取得方法は調べれば見つけれたのですが、
> アプリ上での設定ファイルの位置（モジュール構成？）のような考え方が探しても見つかりませんでした。

　　そこをどうするか・・・は、プログラマーの本来の仕事では？

※　ただ、.NETでの、user.configファイルは、何かの都合でよく
　　壊れたりするので、いろいろ別の手段も講じてますが・・・

以上。

返信ありがとうございます。

■No27010に返信(オショウさんの記事)
>>今までは最初のsub main()で設定ファイルを読み込むメソッドを作成して、
>>エラーチェック等をして構造体orクラス（メモリー上？）に持たせていました。
>>この為に画面が複数あった場合などの為にpublicなモジュールに構造体の変数を
>>持たせていましたが、オブジェクト指向的に間違っている気がしています。
>
> 　　複数あるからこそ、一意に管理する必要があるのでは？
>
> 　　次に、Public と言うかGlobalがダメなら、Form.Tagに渡して
> 　　連携させる方法もあるかと。
>

Globalはダメなど特にこだわりがあるわけではなかったのです。
今まではpublicモジュールで一意に管理して作成していました。
ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
聞いたことがあったので。。。

>>iniファイルやconfigファイルの取得方法は調べれば見つけれたのですが、
>>アプリ上での設定ファイルの位置（モジュール構成？）のような考え方が探しても見つかりませんでした。
>
> 　　そこをどうするか・・・は、プログラマーの本来の仕事では？

申し訳ないです。publicモジュールをやめた時に、main()で取得したクラスや構造体を各フォームで取得する方法がどうしても思いつかず書き込んでしまいました。
「Form.Tag」等、もう少し考えてみたいと思います。

>
> ※　ただ、.NETでの、user.configファイルは、何かの都合でよく
> 　　壊れたりするので、いろいろ別の手段も講じてますが・・・

知らない情報でした。ありがとうございます。

> Globalはダメなど特にこだわりがあるわけではなかったのです。
> 今まではpublicモジュールで一意に管理して作成していました。
> ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
> 聞いたことがあったので。。。

　　では、それら変数を一意に管理するクラスを作って・・・
　　また、同時アクセスが可能性的にあるならば、ReadWriteLock
　　を使って、排他制御も可能かと。

　　因みに構造体でも同様のことが可能ですし・・・

　　結局、どう作るか・・・しかないかと。

※　SyncLockは、使いたくない・・・
　　なんとなくデッドロックと言うか、トラブル多かったので。

以上。参考まで

返信ありがとうございます。

もうすこし、考えてみようかと思います。
よい方法が思いついたら、また書き込みするかもしれません。
そのときはお願いします。



■No27012に返信(オショウさんの記事)
>>Globalはダメなど特にこだわりがあるわけではなかったのです。
>>今まではpublicモジュールで一意に管理して作成していました。
>>ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
>>聞いたことがあったので。。。
>
> 　　では、それら変数を一意に管理するクラスを作って・・・
> 　　また、同時アクセスが可能性的にあるならば、ReadWriteLock
> 　　を使って、排他制御も可能かと。
>
> 　　因みに構造体でも同様のことが可能ですし・・・
>
> 　　結局、どう作るか・・・しかないかと。
>
> ※　SyncLockは、使いたくない・・・
> 　　なんとなくデッドロックと言うか、トラブル多かったので。
>
> 以上。参考まで

■No27011に返信(みけんにしわさんの記事)
> ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
> 聞いたことがあったので。。。
反する？･･･ような事を聞いたことがあった？？？
「オブジェクト指向では無い」というだけでは？

別にオブジェクト指向至上主義じゃないから、使わないほうが
ベターなら使わなければいいと思うけど？？？
設定をどこに持つかは、それを必要とするオブジェクトに分散
して持ってます。
目的に応じてオブジェクトを設計してますから。

データを読込む頻度、処理速度、目的に応じて変わります。

> １．アプリ起動時にまとめて、クラスや構造体に取り込んで
> メモリー上に持たせる
それが一意ならモジュールにしたらいいのでは？
逆にオブジェクト指向(クラス)を使う目的は？
それが無いなら本末転倒です。

> ２．必要な時に必要な情報を設定ファイルからとってくるか
いまどきのパソコンでは毎回読み直してさえもストレスは感じ
ませんが。必要な時に読んで、2回目以降はメモリ上のデータを
使うようにもプログラムできますね。
ユーザが INI ファイル時代の設定方法に慣れてて、設定ファイル
編集したら、画面更新でプログラムにすぐ反映して欲しい。。。
などという要件があれば、毎回読込む方がいいという判断もあり
でしょう。

プログラムとは、明確な計画を立てる行為です。
目的が無いなら、答えも無いです。

返信ありがとうございます。

■No27025に返信(るしぇさんの記事)
> ■No27011に返信(みけんにしわさんの記事)
>>ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
>>聞いたことがあったので。。。
> 反する？･･･ような事を聞いたことがあった？？？
> 「オブジェクト指向では無い」というだけでは？
>
申し訳ない、はっきり覚えてないのですがそうだったかも知れません。


> 別にオブジェクト指向至上主義じゃないから、使わないほうが
> ベターなら使わなければいいと思うけど？？？
特にこだわってはいませんが、上記のような事を聞いたことで、
新しいやり方を模索してみたのですが自分では限界があった為に
人の意見を聞くために書き込みしました。
ご意見ありがとうございます。


> 設定をどこに持つかは、それを必要とするオブジェクトに分散
> して持ってます。
> 目的に応じてオブジェクトを設計してますから。
>
> データを読込む頻度、処理速度、目的に応じて変わります。

今回はログに関する設定ファイル以外はすべてまとめてしまおうかと思っています。



>>１．アプリ起動時にまとめて、クラスや構造体に取り込んで
>>メモリー上に持たせる
> それが一意ならモジュールにしたらいいのでは？
> 逆にオブジェクト指向(クラス)を使う目的は？
> それが無いなら本末転倒です。
特にありませんが、あえて挙げるなら
作成方法は統一するべきかなと思った程度です。

>>２．必要な時に必要な情報を設定ファイルからとってくるか
> いまどきのパソコンでは毎回読み直してさえもストレスは感じ
> ませんが。必要な時に読んで、2回目以降はメモリ上のデータを
> 使うようにもプログラムできますね。
> ユーザが INI ファイル時代の設定方法に慣れてて、設定ファイル
> 編集したら、画面更新でプログラムにすぐ反映して欲しい。。。
> などという要件があれば、毎回読込む方がいいという判断もあり
> でしょう。
ご意見ありがとうございます。
この方法の場合は処理でどうするかになりそうですね。


> プログラムとは、明確な計画を立てる行為です。
> 目的が無いなら、答えも無いです。
耳が痛いです。オブジェクト指向に踊らされ過ぎたのかもしれません。

ご意見、ご指摘ありがとうございます。
とても参考になりました。

時間があれば、モジュール構成図を作成し画像でアップしてみたいと思います。
その時はなにとぞご指摘お願いいたします。

■No27011に返信(みけんにしわさんの記事)
> Globalはダメなど特にこだわりがあるわけではなかったのです。
> 今まではpublicモジュールで一意に管理して作成していました。
> ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
> 聞いたことがあったので。。。

アプリケーションで唯一つ(あるいは限定的な数)の情報を管理するなら、
Singletonを調べてみるとよいと思います。

1. 設定を管理するクラスを用意する
2. 設定を管理するクラスは唯一つだけインスタンスを作成するようにする(Singleton)
3. すべての機能はこのインスタンスを使用する

といった感じですかね。

返信ありがとうございます。

情報ありがとうございます。
Singletonについて調べてみます。



■No27028に返信(よねＫＥＮさんの記事)
> ■No27011に返信(みけんにしわさんの記事)
>>Globalはダメなど特にこだわりがあるわけではなかったのです。
>>今まではpublicモジュールで一意に管理して作成していました。
>>ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
>>聞いたことがあったので。。。
>
> アプリケーションで唯一つ(あるいは限定的な数)の情報を管理するなら、
> Singletonを調べてみるとよいと思います。
>
> 1. 設定を管理するクラスを用意する
> 2. 設定を管理するクラスは唯一つだけインスタンスを作成するようにする(Singleton)
> 3. すべての機能はこのインスタンスを使用する
>
> といった感じですかね。
>

みなさん。ご意見ありがとうございます。
最終的には自分で考えるてどうすべきかな内容だったと思います。

いつまでも意見を聞いているわけにはいかないので、いったん閉めておきます。

返信下さった、みなさんありがとうございます。

よねＫＥＮさん
Singletonについては、調べて検討したいと思います。
困った時は別スレッド立てるかもしれませんがその時はよろしくお願いします。



■No27031に返信(みけんにしわさんの記事)
> 返信ありがとうございます。
>
> 情報ありがとうございます。
> Singletonについて調べてみます。
>
>
>
> ■No27028に返信(よねＫＥＮさんの記事)
>>■No27011に返信(みけんにしわさんの記事)
> >>Globalはダメなど特にこだわりがあるわけではなかったのです。
> >>今まではpublicモジュールで一意に管理して作成していました。
> >>ここ最近でＶＢ.NETでモジュールは使うのはオブジェクト指向に反するような事を
> >>聞いたことがあったので。。。
>>
>>アプリケーションで唯一つ(あるいは限定的な数)の情報を管理するなら、
>>Singletonを調べてみるとよいと思います。
>>
>>1. 設定を管理するクラスを用意する
>>2. 設定を管理するクラスは唯一つだけインスタンスを作成するようにする(Singleton)
>>3. すべての機能はこのインスタンスを使用する
>>
>>といった感じですかね。
>>