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

Question

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

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

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

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

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

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

---

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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