- - PR -
共通ライブラリクラスについて
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-04-27 14:42
これは、呼び出される前までの段階に着目して欲しかったのだと思います。 確かに細分化すれば、必要でない部分はロードされずに済むでしょうけど... _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||||||
|
投稿日時: 2006-04-27 22:37
んっと、わかりにくい書き方だったかもしれませんが、Side By Side のことを言っています。 各プロジェクトに特化した DLL を作る・・・「各プロジェクト」というか、「各アセンブリバージョン」の方が正確かな? また、時々「特定の場所にある DLL をロードしたいのですが、どうすればいいですか」という質問があります。このときには、発生する可能性があると考えられます。
ちらっと書いていますが、小さなファイルをたくさん作ると、ファイルの実サイズ以上のディスク容量が必要です。これは、XP だとファイルのプロパティを表示すると、「サイズ」と「ディスク上のサイズ」が違うことで確認できます。これをどう思うか、というのが、まず一点。 「コントロールがたくさんあるフォームの表示が遅い。早くするにはどうしたらいいか」という質問があります。また、「初期起動が遅くてもいいが、それ以降のフォームの表示を早くしたい」という質問もあります。この2つは、小さな DLL を複数作ったり、ひとつの巨大な exe だけにしたり、対応方法が異なるでしょう。 つまり、「効率」とだけ聞かれると、「時と場合による」という答えになると思います。「こういう場合に、これの効率を良くしたい」と聞かれると、Yes/No で答えられると思います。 じゃんぬさん、囚人さんが説明してくださっているとおり、「明確に呼び出すまで使用されない」ことを意図していました。 | ||||||||||||||||||||
|
投稿日時: 2006-04-28 10:51
自分としては単純に、Jittaさんの投稿内容がとても興味深くて純粋に分からない 所を質問させていただいたつもりだったのですが、自分の投稿内容を読み返すと、 何やら Jittaさんに突っ込みを入れているようにも取れてしまいますね。 Jittaさん、すみませんでした _(_*_)_ #そんなスキルないですし、そんな大それたことしようとも思っていない訳です。
なるほど、そういうことだったんですね。 実はSide By Side自身が良くわかっていなかったので勉強になりました。 今後は、そのアプリケーションで使用する DLL は同じディレクトリーに配置するよ うにしたいと思います。
言われてみると確かにそうですね。
なるほど、よくわかりました。 詳しいご説明をありがとうございました。 | ||||||||||||||||||||
|
投稿日時: 2006-04-28 22:41
いや、どんどん突っ込んでくださいよ。 時々、妙な勘違いしていますし、その方がおもしろいですから。 別のスレッドではありませんが、肯定的な意見しか出ないのは、それはそれで怖いです。人それぞれ違う背景、違う文化を持っていますから、その中でいろいろな方法、考えがあるのは当然です。他の人の意見を聞くことは、今までとは違う要求をされたときに、考えの幅を広げることになります。 | ||||||||||||||||||||
|
投稿日時: 2006-04-29 00:59
共通ライブラリをDLL参照する場合
DLL参照パスと、各プロジェクトのEXEファイル出力パスを 同一にすると、DLLのローカルコピーは発生しません。 ただし、開発環境を別の場所に移した際に vbproj.userファイルがいろいろ悪さをする (元々の参照パスと現在の参照、出力パスのDLLが置き換わる) ので注意が必要です。 何回DLLがディグレードしたことか… [ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2006-04-29 01:02 ] [ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2006-04-29 01:17 ] | ||||||||||||||||||||
|
投稿日時: 2006-04-29 09:37
深く納得です。 このスレを見て思ったのですが、例えば業務管理システムのような比較的大きなサ イズになりがちなソフトウェアの場合、やはり Exe で一本化するよりは、DLL で 分ける方が良いのでしょうか? Jittaさん初め、皆さんならどうされますか? ・商品マスター ・取引先マスター ・発注機能 ・売上機能 ・売上集計機能 ・入金管理機能 こんな場合、僕は今まで大きな EXE ファイル1本にしていましたが、このスレを 読むことで、各タイトルごとに DLL を作ろうかなー、と思い始めている訳です。 | ||||||||||||||||||||
|
投稿日時: 2006-04-29 12:17
効率が云々の話を私もしましたが、実際には深く考える事はあまりないですね。 アセンブリと名前空間名は全く別の概念ですが、やはりアセンブリの分け方も、名前空間同様「グループ」と考えます。そのアセンブリの「独立性」と言ってもよいかもしれません。 internal(C#) や Friend(VB) を有効に活用できるシナリオも、アセンブリを分ける理由になるでしょう。あるクラスは、同じアセンブリのクラスしかインスタンス化出来ない等。 クラス設計や名前空間の分け方などは、.NET Framework クラスライブラリを参考にしたりしますが、アセンブリの概念も同様に参考になるでしょう。見渡すと良いかもしれません。
・データベース入出力(商品マスター等のDB周り。売り上げ集計等の一部(DB周り)) ・ビジネスロジック(売り上げ集計等の一部(ビジネスロジック部)) 「分けるとしたら」こんな感じ?無理に分ける必要もないけど。 _________________ 囚人のジレンマな日々 | ||||||||||||||||||||
|
投稿日時: 2006-04-29 13:38
話を少し戻して保守性という概念で見てください。 これによって臨機応変になることはわかりますか? その機能が、ソリューション全体で必要な場合、 そのプロジェクトでしか使わない場合とで対応が変わります。 個人的には無作為に機能ごとに分けるのではなく、利用範囲を見て分けるべきだと思います。 利用範囲が狭い場合、機能で分けるならばそれは「クラス」の役目であり、 「アセンブリ」の役目ではないということです。 ですので、
これだけでは利用範囲が明確でないので、お答えできませーん。 が、正解だと思います。(^^) _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 |