- - PR -
DLLでの動的プロパティの利用について
1
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-07-14 16:55
皆さんこんにちはAYAと申します。
早速質問なのですが、dllからデザイン時/実行時、両方に有効な動的プロパティ （もどき）を利用する方法はないものでしょうか？ シチュエーション ・DLLのコーディング ・データアダプタ構成ウィザードを利用したい ・DB接続文字列をコードの外に持ちたい テスト時、本番時、開発環境の変化などいろいろな理由のため接続文字列を簡 単に切り替えたい考えているのですが、データアダプタ構成ウィザードを利用 すると、デフォルトではコード中に接続文字列が直接記述されてしまいます。 これは不便だということで、動的プロパティの利用を思いつくのですが、これ はDLLでの利用は未サポートです。（デザイン時は利用できるようですが・・） せめてデザイン時だけでも融通が利くようにと思い、動的プロパティを使おう と考えたのですが、そのコードは実行時にエラーが発生します。 コードに接続文字列を埋め込んだ場合、接続先を切り替えたいような状況になっ た場合、DB接続を行っているコードを特定して手作業で一つずつ変更を行わな ければなりません。 あきらめて接続文字列を設定するコードを自分自身で記述する事もできるので すが、せっかくのお便利ウィザードのありがたみが半減してしまいます。 行いたいこと ・DLLの中から利用するDB接続文字列を何らかの方法でコードの外に持っていきたい ・ウィザードなどお便利機能をそのまま利用したい（デザイン時にも有効） ・楽をしたい(^-^;; どなたか上記の条件クリアする妙案もしくは、あきらめる覚悟ができる一言を 私に授けてください。 よろしくお願いします。 | ||||
|
投稿日時: 2003-07-14 18:20
これならやっています。 「データベース接続に関する設定を保持するクラス」を作成し、 その中で設定をXMLシリアライズしてコードの外に保存しています。 そんなのでいいのかな？ | ||||
|
投稿日時: 2003-07-14 19:38
お返事ありがとうございます。
>「データベース接続に関する設定を保持するクラス」を作成し、 >その中で設定をXMLシリアライズしてコードの外に保存しています。 ふむふむ。 これはアセンブリのマニフェストリソースとしてXMLを埋め込むことでしょう か？ でも、デザイン時ってどうしてますか？実行時が勝負時？ やはりコードを書かなければならないのでしょうか。むむぅ。 あくまでもウィザードは簡易機能であって、まじめにやるにはコードを記述し なければならないのでしょうね。 (どうせならコードを書くならJavaのJNDIみたいな機能があると良いのにね) データアダプタ構成ウィザードは魔法使い見習いだったという結論なのかなぁ。 怠け者には辛いです。(^-^;; | ||||
|
投稿日時: 2003-07-14 20:15
わはははは！座布団２枚！！大受けしました。 私の中の結論としては、データアダプタ構成ウイザードは「使えません」？？ 「使ってはいけない」かな？「使っても信用するな」かな？ とにかく、これを使うとデータをクラス化するのが、 とてもややこしくなってくるため、使わないことにしました。 ただ、ConnectionStringを知るためには非常に有用なので、 そのためだけに使っています。 あとは、一度読み込んだら変更することがないデータとか。 Borlandのツールでは、「データを扱うためのフォーム」 が用意されているんですよ。 そんな風に、表示するものを集めたページと、 表示するものがないページを別個で構成する方が、 クラスとしては見やすいかな？と、、、 （そのためのDataSetか？） >>これはアセンブリのマニフェストリソースとして ？？ c:\Documents and Settings\All Users\Application Data\… に保存しています。 MSDNのトピックでは、「アプリケーション設定の永続化」かな？ デザイン時も有効です。が、ウイザードのように「知る」ことはできません。 | ||||
|
投稿日時: 2003-07-14 23:17
こんにちはJittaさん。
すばやいお返事ありがとうございます。 > 私の中の結論としては、データアダプタ構成ウイザードは「使えません」？？ >「使ってはいけない」かな？「使っても信用するな」かな？ うすうす気づいていたのだが、気が付かないふりをしていた一言をいわれてし まった。 そうなんですよ、こいつを利用しようとするといろいろ無理というか思い通り にいかないのです。 単に、私とMSとのシンクロ率が低いのが原因なんだと思い込んでいたのですが、 場合によっては割り切りも必要だという覚悟がつきました。 DB関係のウィザードにあこがれていたんですよ・・使ってみたかったんですよ。 とほほ・・ >c:\Documents and Settings\All Users\Application Data\… >に保存しています。 >MSDNのトピックでは、「アプリケーション設定の永続化」かな？ Application.CommonAppDataPathと、XmlSerializerの組み合わせのことでしょ うか？ これは良いですね。なんていったって楽チンです。 私はいちいち ・カスタムなxmlを作成 ・ビルドアクションの「埋め込まれたリソース」としてAssemblyに埋め込む ・Assembly.GetManifestResourceStreamによって取得 ・読み込み なーんて遠回りな事を行っていました。 しかし、しかしですよ。 ASP.NETではどうやってこのような都合がよい場所を取得できるのでしょうか？ WebとWindowsForms両対応な方法があるとうれしいのですが・・・ 解決方法をご存知でしたら教えていただけないでしょうか？ お願いします。 | ||||
|
投稿日時: 2003-07-15 08:58
>DB関係のウィザードにあこがれていたんですよ・・使ってみたかったんですよ。
私も、テーブルを視覚的に連結してビューや 問い合わせ文（WHERE句）を作るウイザードorツールが欲しい・・・ >Application.CommonAppDataPathと、XmlSerializerの組み合わせのことでしょうか？ あ゛！？ いやいや、webなんで、Application変数は使えない、と。 ので、私はWin.API呼び出ししています。 Private Declare Auto Sub GetAllUsersProfileDirectory Lib "userenv.dll" (ByVal sysDirBuffer As System.Text.StringBuilder, ByRef buffSize As Integer) ' buffSize は戻ってくるのでByRef Dim ProfilePathRoot As New System.Text.StringBuilder(256) Dim size As Integer = ProfilePathRoot.Capacity ' 設定したバイト数が戻ってくるのでsizeに入れ直す GetAllUsersProfileDirectory(ProfilePathRoot, size) パス用には3200バイト（？UNCパスのバイト数）用意するべきかもしれませんが、 ローカルなはずなので、２５６バイトにしています。 この後、"Application Data"などを足しています。 System.IO.Path.Combine(ProfilePathRoot.ToString, "Application Data") また、XML化は、やってみたら簡単だったので、Serializable属性をつけ、 ISerializableインターフェースをインプリメントしています。 こっちだと、バージョンアップの対応も可能だし、 オブジェクトそのものをXMLに落としてくれるので。 （って、XMLSeliarizerはまだ読んでへんやん） [ メッセージ編集済み 編集者: Jitta 編集日時 2003-07-15 10:44 ] | ||||
|
投稿日時: 2003-07-15 12:55
お返事ありがとうございます。 ふむ、API呼び出しですか。なるほど。 それは盲点でした。 この方法を使えばJittaのアイディアは問題なく実現できますね。 大変ためになりました。 ありがとうございます。 | ||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。