11

私は、ソフトウェアの同じ部分が 1 つの実行可能ファイルといくつかの DLL に分割されている小さな製品を数多く見てきました。これらの DLL は、他の誰かによって作成された単なる共有ライブラリではなく、このソフトウェア専用に作成されたライブラリです。同じ開発チーム。(ここでは、何百もの DLL を必要とし、それらを他の製品と広く共有するだけの大規模な製品について話しているのではありません。)

コードをいくつかの部分に分割し、それぞれを個別の DLL にコンパイルすることは、開発者の観点からは良いことだと理解しています。だということだ：

  • 開発者が 1 つのプロジェクトを変更した場合、このプロジェクトと依存するプロジェクトのみを再コンパイルする必要があり、これによりはるかに高速になる可能性があります。
  • プロジェクトはチーム内の 1 人の開発者が行うことができますが、他の開発者はコードに介入することなく、提供されたインターフェイスを使用するだけです。
  • ソフトウェアの自動更新は、サーバーへの影響が少なく、高速になる場合があります。

しかし、エンドユーザーはどうでしょうか? すべてをグループ化できるのに、1 つの EXE と複数の DLL で構成されるソフトウェアを提供するのは、単に悪いことではないでしょうか? 結局：

  • ユーザーは、それらのファイルが何なのか、そしてなぜそれらが自分のハードディスクのメモリをいっぱいにするのかさえ理解していないかもしれません。
  • ユーザーは、USB フラッシュ ドライブにプログラムを保存するなど、プログラムを移動したい場合があります。1 つの大きな実行可能ファイルがあると作業が簡単になります。
  • ほとんどのウイルス対策ソフトウェアは、各 DLL をチェックします。1 つの実行可能ファイルをチェックする方が、小さな実行可能ファイルと多数のライブラリをチェックするよりもはるかに高速です。
  • DLL を使用すると、いくつかの処理が遅くなります (たとえば、.NET Framework では、「適切な」ライブラリを見つけて、署名されているかどうかを確認する必要があります)。
  • DLL が削除されたり、不適切なバージョンに置き換えられたりするとどうなりますか? すべてのプログラムはこれを処理しますか? それとも、何が問題なのかを説明することさえせずにクラッシュしますか?
  • 1 つの大きな実行可能ファイルを持つことには、他にもいくつかの利点があります。

小規模/中規模のプログラムの場合、エンド ユーザーの観点からは、1 つの大きな実行可能ファイルを提供する方がよいのではないでしょうか? もしそうなら、それを簡単に実行できるツールがないのはなぜですか (たとえば、ソリューション全体を 1 つの実行可能ファイルにコンパイルする一般的な IDE に統合された魔法のツールは、もちろん毎回ではなく、オンデマンドまたは展開中に)。

これは、すべての CSS ファイルまたはすべての JavaScript ファイルをユーザー向けの 1 つの大きなファイルに入れることにいくらか似ています。複数のファイルを持つことは、開発者にとってはるかにスマートで保守が容易ですが、Web サイトの各ページを数十ではなく 2 つのファイルにリンクすると、パフォーマンスが最適化されます。同じように、CSS スプライトはデザイナーにとっては厄介なものです。なぜなら、CSS スプライトはより多くの作業を必要とするからです。しかし、ユーザーの観点からはより優れています。

4

6 に答える 6

9

これはトレードオフ
です (ご自身ですでにお気づきでしょう ;))
ほとんどのプロジェクトでは、顧客はインストールされるファイルの数を気にしませんが、時間内に完了する機能の数を気にします。開発者の作業を楽にすることは、ユーザーにも利益をもたらします。

DLL のその他の理由

一部のライブラリは、同じビルド内ではうまく動作しませんが、DLL 内で動作するように作成できます (たとえば、1 つの DLL は WTL3 を使用し、もう 1 つの DLL は WTL8 を必要とする場合があります)。

一部の DLL には、他の実行可能ファイル (グローバル フック、シェル拡張、ブラウザー アドオン) に読み込まれるコンポーネントが含まれている場合があります。

一部の DLL はサード パーティ製であり、DLL としてのみ利用可能です。

社内で再利用される可能性があります。「パブリック」製品が 1 つしか表示されていなくても、その DLL を使用する多数の社内プロジェクトで使用されている可能性があります。

一部の DLL は、社内のすべての開発者が利用できるわけではない別の環境で構築されている可能性があります。

スタンドアロン EXE とインストール済み製品
多くの製品は、スタンドアロンの実行可能ファイルとしては機能しません。それらにはインストールが必要であり、ユーザーは触れてはいけないものに触れないでください。バイナリが 1 つ以上あることは重要ではありません。

ビルド時間の影響 ビルド時間
の影響を過小評価し、大規模なプロジェクトの安定したビルドを維持している可能性があります。ビルドに 5 分もかかる場合でも、「問題なく動作するようになるまでいじくりまわすのではなく、開発者に前もって考えさせる」ことを婉曲的に言うことができます。しかし、それは深刻な時間食いであり、深刻な注意散漫を引き起こします。

1 つのプロジェクトのビルド時間を改善するのは困難です。VC9 での作業では、1 つのプロジェクト内でのビルドの並列化は不安定であり、インクリメンタル リンカーも同様です。リンク時間は、より高速なマシンによって「最適化」するのが特に困難です。

開発者の独立
性 過小評価されているかもしれないもう 1 つのこと。
DLL を使用するには、.dll と .h が必要です。ソース コードをコンパイルしてリンクするには、通常、インクルード ディレクトリ、出力ディレクトリ、サードパーティ ライブラリのインストールなどを設定する必要があります。これは本当に面倒です。

于 2010-06-04T10:59:32.993 に答える
1

はい、私見の方が良いです-可能な限り、あなたが与えた理由とまったく同じように、私は常に静的リンクを使用しています。動的リンケージが発明された多くの理由 (メモリの節約など) は、もはや実際には当てはまりません。OTOH、プラグインアーキテクチャなどのアーキテクチャ上の理由があり、動的リンクが静的リンクよりも望ましい場合があります。

于 2010-06-04T09:54:23.743 に答える
0

多くのプロジェクトを行ってきましたが、自分のボックスにあるいくつかの dll ファイルに問題があるエンドユーザーに会ったことはありません。

開発者として、私はそう言うでしょう。気にするエンドユーザーとして...

于 2010-06-04T09:58:05.000 に答える
0

はい、エンド ユーザーの観点からは、多くの場合、そのほうがよい場合があります。ただし、あなたが言及した開発者 (および開発プロセス) へのメリットは、多くの場合、企業が費用対効果の高いオプションを好むことを意味します。

これは非常に少数のユーザーが評価する機能であり、提供するのにかなりの費用がかかります。

私たち StackOverflow は「平均以上」のユーザーであることを忘れないでください。ソフトウェアを USB スティックにインストールできることを本当に評価する(オタクではない) 家族や友人は何人いますか?

于 2010-06-04T10:13:35.353 に答える
0

成果物の最終的なパッケージングを慎重に検討することについてのあなたの一般的なポイントはよくできていると思います。JavaScript の場合、そのようなパッケージ化は確かに可能であり、圧縮によって大きな違いが生じます。

于 2010-06-04T09:54:19.347 に答える
-1

dll の大きな利点は、国境と独立性の導入に関連しています。

  • たとえば、C/C++ では、エクスポートされたシンボルのみが表示されます。グローバル変数「scale」を持つモジュール A と、別のグローバル変数「scale」を持つモジュール B を想像してみてください。この場合、dll が役に立ちます。

  • まったく同じコンパイラ/リンカー オプションがなくても、これらの dll をコンポーネントとして顧客に配布できます。これは多くの場合、言語間の相互運用を行うための良い方法です。

于 2012-02-13T11:04:04.597 に答える