- PR -

共通ライブラリクラスについて

投稿者投稿内容
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-04-27 14:42
引用:

R・田中一郎さんの書き込み (2006-04-27 14:22) より:

Jittaさんの「また、DLL は、必要になるまでロードされません。よって、消費する
メモリ量を減らすという点でも」の部分に妙に納得して一人で過剰に反応してしまいました。


これは、呼び出される前までの段階に着目して欲しかったのだと思います。
確かに細分化すれば、必要でない部分はロードされずに済むでしょうけど...

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

R・田中一郎さんの書き込み(2006-04-27 09:20)より:

DELL Hell は SideBySide で解決されたと言われていますが、まだ生じることはあるのでしょうか?


 んっと、わかりにくい書き方だったかもしれませんが、Side By Side のことを言っています。
各プロジェクトに特化した DLL を作る・・・「各プロジェクト」というか、「各アセンブリバージョン」の方が正確かな?

 また、時々「特定の場所にある DLL をロードしたいのですが、どうすればいいですか」という質問があります。このときには、発生する可能性があると考えられます。


引用:

よく、オンラインで配布されているソフトで、exe と dll が1つずつの組合せにな
っていて、exe が小さくて dll がやけにでかかったりしますが、この場合も上記の
ようなメリットはあるのですか?
それとも、小さな dll を複数作るほうが効率が良いのですか?


 ちらっと書いていますが、小さなファイルをたくさん作ると、ファイルの実サイズ以上のディスク容量が必要です。これは、XP だとファイルのプロパティを表示すると、「サイズ」と「ディスク上のサイズ」が違うことで確認できます。これをどう思うか、というのが、まず一点。

 「コントロールがたくさんあるフォームの表示が遅い。早くするにはどうしたらいいか」という質問があります。また、「初期起動が遅くてもいいが、それ以降のフォームの表示を早くしたい」という質問もあります。この2つは、小さな DLL を複数作ったり、ひとつの巨大な exe だけにしたり、対応方法が異なるでしょう。


 つまり、「効率」とだけ聞かれると、「時と場合による」という答えになると思います。「こういう場合に、これの効率を良くしたい」と聞かれると、Yes/No で答えられると思います。

 じゃんぬさん、囚人さんが説明してくださっているとおり、「明確に呼び出すまで使用されない」ことを意図していました。
R・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-04-28 10:51
引用:

じゃんぬねっとさんの書き込み (2006-04-27 14:42) より:

これは、呼び出される前までの段階に着目して欲しかったのだと思います。
確かに細分化すれば、必要でない部分はロードされずに済むでしょうけど...



自分としては単純に、Jittaさんの投稿内容がとても興味深くて純粋に分からない
所を質問させていただいたつもりだったのですが、自分の投稿内容を読み返すと、
何やら Jittaさんに突っ込みを入れているようにも取れてしまいますね。

Jittaさん、すみませんでした _(_*_)_

#そんなスキルないですし、そんな大それたことしようとも思っていない訳です。

引用:

Jittaさんの書き込み (2006-04-27 22:37) より:

引用:

R・田中一郎さんの書き込み(2006-04-27 09:20)より:

DELL Hell は SideBySide で解決されたと言われていますが、まだ生じることはあるのでしょうか?


 んっと、わかりにくい書き方だったかもしれませんが、Side By Side のことを言っています。
各プロジェクトに特化した DLL を作る・・・「各プロジェクト」というか、「各アセンブリバージョン」の方が正確かな?



なるほど、そういうことだったんですね。
実はSide By Side自身が良くわかっていなかったので勉強になりました。
今後は、そのアプリケーションで使用する DLL は同じディレクトリーに配置するよ
うにしたいと思います。

引用:

Jittaさんの書き込み (2006-04-27 22:37) より:

 ちらっと書いていますが、小さなファイルをたくさん作ると、ファイルの実サイズ以上のディスク容量が必要です。



言われてみると確かにそうですね。

引用:

Jittaさんの書き込み (2006-04-27 22:37) より:

 「コントロールがたくさんあるフォームの表示が遅い。早くするにはどうしたらいいか」という質問があります。また、「初期起動が遅くてもいいが、それ以降のフォームの表示を早くしたい」という質問もあります。この2つは、小さな DLL を複数作ったり、ひとつの巨大な exe だけにしたり、対応方法が異なるでしょう。



なるほど、よくわかりました。
詳しいご説明をありがとうございました。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-04-28 22:41
引用:

R・田中一郎さんの書き込み (2006-04-28 10:51) より:

自分としては単純に、Jittaさんの投稿内容がとても興味深くて純粋に分からない
所を質問させていただいたつもりだったのですが、自分の投稿内容を読み返すと、
何やら Jittaさんに突っ込みを入れているようにも取れてしまいますね。

Jittaさん、すみませんでした _(_*_)_

#そんなスキルないですし、そんな大それたことしようとも思っていない訳です。


いや、どんどん突っ込んでくださいよ。
時々、妙な勘違いしていますし、その方がおもしろいですから。

別のスレッドではありませんが、肯定的な意見しか出ないのは、それはそれで怖いです。人それぞれ違う背景、違う文化を持っていますから、その中でいろいろな方法、考えがあるのは当然です。他の人の意見を聞くことは、今までとは違う要求をされたときに、考えの幅を広げることになります。
ハニワ祭り
大ベテラン
会議室デビュー日: 2005/11/15
投稿数: 115
投稿日時: 2006-04-29 00:59
共通ライブラリをDLL参照する場合
DLL参照パスと、各プロジェクトのEXEファイル出力パスを
同一にすると、DLLのローカルコピーは発生しません。
ただし、開発環境を別の場所に移した際に
vbproj.userファイルがいろいろ悪さをする
(元々の参照パスと現在の参照、出力パスのDLLが置き換わる)
ので注意が必要です。

何回DLLがディグレードしたことか…

[ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2006-04-29 01:02 ]

[ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2006-04-29 01:17 ]
R・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-04-29 09:37
引用:

Jittaさんの書き込み (2006-04-28 22:41) より:

す。人それぞれ違う背景、違う文化を持っていますから、その中でいろいろな方法、考えがあるのは当然です。他の人の意見を聞くことは、今までとは違う要求をされたときに、考えの幅を広げることになります。



深く納得です。
このスレを見て思ったのですが、例えば業務管理システムのような比較的大きなサ
イズになりがちなソフトウェアの場合、やはり Exe で一本化するよりは、DLL で
分ける方が良いのでしょうか?
Jittaさん初め、皆さんならどうされますか?

・商品マスター
・取引先マスター
・発注機能
・売上機能
・売上集計機能
・入金管理機能

こんな場合、僕は今まで大きな EXE ファイル1本にしていましたが、このスレを
読むことで、各タイトルごとに DLL を作ろうかなー、と思い始めている訳です。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-04-29 12:17
引用:

このスレを見て思ったのですが、例えば業務管理システムのような比較的大きなサ
イズになりがちなソフトウェアの場合、やはり Exe で一本化するよりは、DLL で
分ける方が良いのでしょうか?


効率が云々の話を私もしましたが、実際には深く考える事はあまりないですね。
アセンブリと名前空間名は全く別の概念ですが、やはりアセンブリの分け方も、名前空間同様「グループ」と考えます。そのアセンブリの「独立性」と言ってもよいかもしれません。

internal(C#) や Friend(VB) を有効に活用できるシナリオも、アセンブリを分ける理由になるでしょう。あるクラスは、同じアセンブリのクラスしかインスタンス化出来ない等。

クラス設計や名前空間の分け方などは、.NET Framework クラスライブラリを参考にしたりしますが、アセンブリの概念も同様に参考になるでしょう。見渡すと良いかもしれません。

引用:

・商品マスター
・取引先マスター
・発注機能
・売上機能
・売上集計機能
・入金管理機能


・データベース入出力(商品マスター等のDB周り。売り上げ集計等の一部(DB周り))
・ビジネスロジック(売り上げ集計等の一部(ビジネスロジック部))

「分けるとしたら」こんな感じ?無理に分ける必要もないけど。

_________________
囚人のジレンマな日々
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-04-29 13:38
引用:

R・田中一郎さんの書き込み (2006-04-29 09:37) より:

このスレを見て思ったのですが、例えば業務管理システムのような比較的大きなサ
イズになりがちなソフトウェアの場合、やはり Exe で一本化するよりは、DLL で
分ける方が良いのでしょうか?

こんな場合、僕は今まで大きな EXE ファイル1本にしていましたが、このスレを
読むことで、各タイトルごとに DLL を作ろうかなー、と思い始めている訳です。


話を少し戻して保守性という概念で見てください。
これによって臨機応変になることはわかりますか?

その機能が、ソリューション全体で必要な場合、
そのプロジェクトでしか使わない場合とで対応が変わります。

個人的には無作為に機能ごとに分けるのではなく、利用範囲を見て分けるべきだと思います。

利用範囲が狭い場合、機能で分けるならばそれは「クラス」の役目であり、
「アセンブリ」の役目ではないということです。

ですので、

引用:

・商品マスター
・取引先マスター
・発注機能
・売上機能
・売上集計機能
・入金管理機能


これだけでは利用範囲が明確でないので、お答えできませーん。
が、正解だと思います。(^^)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌

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