Почему создание DLLs вместо того, чтобы компилировать все в один большой исполняемый файл?
Я видел и сделанный я много маленьких продуктов, где та же часть программного обеспечения разделена на один исполняемый файл и несколько DLLs, и те DLLs не являются просто совместно использованными библиотеками, сделанными кем-то еще, но и библиотеками, которые сделаны исключительно для этого программного обеспечения той же командой разработчика. (Я не говорю здесь о больших продуктах масштаба, которые просто требуют сотен DLLs и совместно используют их экстенсивно с другими продуктами.)
Я понимаю, что разделение кода в несколько частей, каждый компилирующий в отдельный DLL, хорошо с точки зрения разработчика. Это означает что:
- Если разработчик изменяет один проект, он должен перекомпилировать только этого и зависимые, которые могут быть намного быстрее.
- Проект может быть сделан единственным разработчиком в команде, в то время как другие разработчики будут просто использовать обеспеченные интерфейсы, не ступая в код.
- Автоматические обновления программного обеспечения могут иногда быть быстрее с более низким влиянием сервера.
Но что относительно конечного пользователя? Разве это не просто плохо для поставки части программного обеспечения, состоявшего из одного EXE и нескольких DLLs, когда все могло группироваться? В конце концов:
- Пользователь даже не может понять то, что является теми файлами и почему они заполняют память на его жестком диске,
- Пользователь может хотеть переместить программу, например, сохранить ее на карте флэш-памяти с интерфейсом USB. Наличие одного большого исполняемого файла делает вещи легче,
- Большая часть антивирусного программного обеспечения проверит каждый DLL. Проверка одного исполняемого файла будет намного быстрее, чем меньший исполняемый файл и десятки библиотек.
- Используя DLLs делает некоторые вещи медленнее (например, в Платформе.NET, "хорошая" библиотека должна быть найдена и проверена, если она подписывается),
- Что происходит, если DLL удален или заменен плохой версией? Каждая программа обрабатывает это? Или это отказывает, даже не объясняя что случилось с ним?
- Наличие одного большого исполняемого файла имеет некоторые другие преимущества.
Так разве это не лучше с точки зрения конечных пользователей, для маленьких программ / программ среднего размера, для поставки одного большого исполняемого файла? Если так, почему нет никаких инструментов, позволяющих сделать это легко (например, волшебный инструмент, интегрированный в общих IDE, который компилирует целое решение в один исполняемый файл, не каждый раз, конечно, но по запросу или во время развертывания).
Это некоторым образом подобно помещению всего CSS или всех файлов JavaScript в один большой файл для пользователя. Наличие нескольких файлов намного более умно для разработчика и легче поддержать, но соединение каждой страницы веб-сайта в два файла вместо десятков оптимизирует производительность. Таким же образом спрайты CSS ужасны для разработчиков, потому что они требуют намного большего количества работы, но лучше с пользовательской точки зрения.
5 ответов
Это компромисс
(Вы уже сами это поняли ;))
Для большинства проектов заказчику не важно, сколько файлов будет установлено, но ему важно, сколько функций будет выполнено в срок. Облегчение жизни разработчикам идет на пользу и пользователю.
Еще несколько причин для DLL
Некоторые библиотеки не очень хорошо работают вместе в одной сборке, но их можно заставить вести себя в DLL (например, одна DLL может использовать WTL3, а другая требует WTL8).
Некоторые DLL могут содержать компоненты для загрузки в другие исполняемые файлы (глобальные крючки, расширения оболочки, аддоны браузера).
Некоторые DLL могут быть сторонними и доступны только в виде DLL.
Возможно повторное использование внутри компании - даже если вы видите только один "публичный" продукт, он может использоваться в дюжине внутренних проектов, использующих эту DLL.
Некоторые DLL могли быть созданы в другой среде, которая доступна не всем разработчикам в компании.
Автономный EXE против установленного продукта
Многие продукты в любом случае не будут работать как автономный исполняемый файл. Они требуют установки, и пользователь не должен трогать то, что ему не положено. Наличие одного или нескольких двоичных файлов не имеет значения.
Влияние времени сборки
Возможно, вы недооцениваете влияние времени сборки и поддержания стабильной сборки для больших проектов. Если сборка занимает хотя бы 5 минут, можно эфемистически назвать это "заставить разработчиков думать наперед, вместо того, чтобы возиться, пока не покажется, что все работает нормально". Но это серьезный пожиратель времени и создает серьезный отвлекающий фактор.
Время сборки одного проекта трудно улучшить. При работе над VC9 распараллеливание сборки в рамках одного проекта шаткое, как и инкрементный компоновщик. Время компоновки особенно трудно "оптимизировать" с помощью более быстрых машин.
Независимость разработчика
Еще одна вещь, которую вы можете недооценить.
Чтобы использовать DLL, вам нужны .dll и .h.
Чтобы скомпилировать и связать исходный код, обычно нужно настроить каталоги include, каталоги output, установить сторонние библиотеки и т.д. Это очень хлопотно.
Да, это лучше ИМХО - и я всегда использую статическое связывание именно по тем причинам, которые вы указываете, везде, где это возможно. Многие причины, по которым было изобретено динамическое связывание (например, для экономии памяти), больше не применимы. OTOH, есть архитектурные причины, например архитектура плагинов, почему динамическое связывание может быть предпочтительнее статического.
Я думаю, что ваш общий тезис о тщательном рассмотрении окончательной упаковки поставляемых продуктов хорошо сделан. В случае JavaScript такая упаковка действительно возможна, и при сжатии она дает существенную разницу.
Да, часто это может быть лучше с точки зрения конечного пользователя. Однако преимущества для разработчика (и процесса разработки), о которых вы упоминаете, часто означают, что бизнес предпочтет экономичный вариант.
Это функция, которую оценят очень немногие пользователи, и ее доставка будет стоить нетривиальной суммы.
Помните, что мы в StackOverflow - пользователи «выше среднего». Сколько у вас (не компьютерных) членов семьи и друзей, которые действительно оценят возможность установки своего программного обеспечения на USB-накопитель?
Делал много проектов, никогда не встречал конечного пользователя, у которого были бы проблемы с некоторыми dll-файлами, расположенными на его коробке.
Как разработчик я бы сказал, что да, это может иметь значение. Как конечного пользователя это не волнует...