Зачем создавать DLL вместо того, чтобы скомпилировать все в один большой исполняемый файл?

Я видел и делал себе множество небольших продуктов, в которых одна и та же часть программного обеспечения разделена на одну исполняемую и несколько DLL, а эти библиотеки DLL - это не только разделяемые библиотеки, созданные кем-то другим, но библиотеки, которые выполняются исключительно для этого программного обеспечения, той же командой разработчиков. (Я не говорю здесь о крупномасштабных продуктах, которым требуется только сотни DLL и широко использовать их вместе с другими продуктами.)

Я понимаю, что разделение кода на несколько частей, каждый из которых компилируется в отдельную DLL, хорош с точки зрения разработчика. Это означает, что:

  • Если разработчик меняет один проект, он должен перекомпилировать только этот и зависимые, которые могут быть намного быстрее.
  • Проект может быть выполнен одним разработчиком в команде, в то время как другие разработчики просто будут использовать предоставленные интерфейсы, не вступая в код.
  • Автоматические обновления программного обеспечения иногда могут быть быстрее, с меньшим воздействием сервера.

Но как насчет конечного пользователя? Разве не так просто доставить часть программного обеспечения, состоящего из одного EXE и нескольких DLL, когда все можно объединить вместе? В конце концов:

  • Пользователь может даже не понимать, что это за файлы и почему они заполняют память на своем жестком диске,
  • Пользователь может захотеть переместить программу, например, сохранить ее на USB-накопителе. Наличие одного большого исполняемого файла упрощает работу,
  • Большинство антивирусных программ проверит каждую DLL. Проверка одного исполняемого файла будет намного быстрее, чем меньший исполняемый файл и десятки библиотек.
  • Использование DLL делает некоторые вещи медленнее (например, в .NET Framework должна быть найдена "хорошая" библиотека и проверена, если она подписана),
  • Что произойдет, если DLL будет удалена или заменена плохой версией? Поддерживает ли каждая программа это? Или он рухнет, даже не объяснив, что с ним не так?
  • Наличие одного большого исполняемого файла имеет некоторые другие преимущества.

Значит, не лучше ли с точки зрения конечных пользователей, для программ малого и среднего размера, предоставить один большой исполняемый файл? Если да, то почему нет инструментов, позволяющих сделать это легко ( например, волшебный инструмент, интегрированный в общие IDE, который компилирует все решение в один исполняемый файл, но не каждый раз, конечно, но по запросу или во время развертывания).

Это похоже на помещая все CSS или все файлы JavaScript в один большой файл для пользователя. Наличие нескольких файлов гораздо умнее для разработчиков и их проще поддерживать, но привязка каждой страницы веб-сайта к двум файлам, а не десяткам, оптимизирует производительность. Точно так же CSS спрайты ужасны для дизайнеров, потому что они требуют гораздо больше работы, но лучше с точки зрения пользователей.

ОТВЕТЫ

Ответ 1

Это компромисс
(Вы сами это поняли сами;))
Для большинства проектов клиенту не важно, сколько файлов установлено, но он заботится о том, сколько функций завершено вовремя. Кроме того, облегчить жизнь разработчикам.

Еще несколько причин для DLL

Некоторые библиотеки не очень хорошо взаимодействуют в одной сборке, но могут вести себя в DLL (например, одна DLL может использовать WTL3, а другая - WTL8).

Некоторые из DLL могут содержать компоненты для загрузки в другие исполняемые файлы (глобальные перехватчики, расширения оболочки, аддоны браузера).

Некоторые из DLL могут быть сторонними, доступными только как DLL.

В компании может быть повторное использование - даже если вы видите только один "общедоступный" продукт, его можно использовать в десятке внутренних проектов, используя эту DLL.

Некоторые из DLL, возможно, были созданы с другой средой, недоступной для всех разработчиков в компании.

Автономный EXE против установленного продукта
В любом случае, многие продукты не будут работать как автономный исполняемый файл. Они требуют установки, и пользователь не прикасается к вещам, которые он не должен касаться. Наличие одного или нескольких двоичных файлов не имеет значения.

Эффект времени сборки
Возможно, вы недооцениваете влияние времени сборки и поддерживаете стабильную сборку для крупных проектов. Если сборка занимает 5 минут, вы можете эфемерно назвать это "заставляйте разработчиков думать впереди, а не возиться, пока, похоже, не получится". Но это серьезный пожиратель времени и создает серьезное отвлечение.

Время сборки одного проекта трудно улучшить. Работа над VC9, построение распараллеливания в рамках одного проекта неустойчиво, как и инкрементный компоновщик. Время ссылки особенно сложно "оптимизировать" быстрее.

Независимость разработчиков
Еще одна вещь, которую вы можете недооценить. Чтобы использовать DLL, вам нужны DLL и .h. Чтобы скомпилировать и связать исходный код, вам обычно нужно настроить каталоги, каталоги вывода, установить сторонние библиотеки и т.д. Это действительно боль.

Ответ 2

Да, это лучше ИМХО - и я всегда использую статическую привязку именно по причинам, которые вы даете, где это возможно. Множество причин, по которым динамическая связь была изобретена (например, для сохранения памяти), больше не применяется. OTOH, есть архитектурные причины, например архитектуры плагинов, почему динамическая компоновка может быть предпочтительнее статической.

Ответ 3

Я думаю, что ваше общее мнение о тщательном рассмотрении окончательной упаковки результатов хорошо сделано. В случае JavaScript такая упаковка действительно возможна, и с сжатием имеет существенное значение.

Ответ 4

Готово много проектов, никогда не встречал конечного пользователя, у которого возникли проблемы с некоторыми DLL файлами, находящимися на его поле.

Как разработчик, я бы сказал, да, это может иметь значение. Как конечный пользователь, который заботится...

Ответ 5

Да, часто может быть лучше с точки зрения конечного пользователя. Однако преимущества для разработчика (и процесса разработки), которые вы упоминаете, часто означают, что бизнес предпочтет рентабельный вариант.

Это функция, которую очень мало оценят пользователи, и это будет стоить нетривиальной суммы для доставки.

Помните, что мы в StackOverflow "выше среднего". Сколько у вас (друзей и друзей) членов семьи и друзей, которые действительно ценят возможность установки своего программного обеспечения на USB-накопитель?

Ответ 6

Большие преимущества для dll связаны с внедрением границ и независимости.

  • Например, в C/С++ отображаются только экспортированные символы. Представьте себе модуль A с глобальной переменной "scale" и модулем B с другой глобальной шкалой "scale", если вы все вместе перейдете в desaster; в этом случае dll может вам помочь.

  • Вы можете распространять эти dll как компоненты для клиентов без точно таких же параметров компилятора/компоновщика; и это часто является хорошим способом взаимодействия между языками.