Рекомендации по созданию приложения, которое будет обновляться часто - C++

Question

Я разрабатываю портативное приложение на C++ и искал некоторые рекомендации по этому поводу. Это приложение будет иметь частые обновления, и мне нужно его построить таким образом, чтобы части программы могли быть легко обновлены.

1. Для часто обновляемой программы создание программных частей в библиотеках - лучшая практика? Если части программы находятся в отдельных библиотеках, пользователи могут просто заменить библиотеку, когда что-то изменится.
2. Если ответ для пункта 1 «да», какой тип библиотеки я должен использовать? В LINUX я знаю, что могу создать «разделяемую библиотеку», но я не уверен, насколько портативен это для Windows. Какую библиотеку я должен использовать? Я также знаю об ошибках DLL в Windows.

Любая помощь будет замечательной!

Answer 1

Как только вы пытаетесь разобраться с и Windows и система UNIX, например Linux, жизнь усложняется.

Каковы требования к обслуживанию, которые вам необходимо удовлетворить? Можете ли вы контролировать обновление клиентских систем? Сколько систем вам нужно будет поддерживать? Сколько требуется для обеспечения обратной совместимости.

Answer 2

1. Да, с использованием библиотек хорошо, но идея «просто» заменить библиотеку с новой может быть нереальным, так как библиотека API, как правило, изменения и приложения часто должны быть обновлены, чтобы воспользоваться, или даже совместимы с различными версиями библиотеки. Однако при хорошем количестве integration testing вы сможете «поддерживать» ряд различных версий библиотеки. Или, если вы сами управляете кодом библиотеки, вы можете убедиться, что изменения в коде библиотеки никогда не прерывают приложение.

2. В Windows DLL - это прямой эквивалент разделяемым библиотекам (так) в Linux, и если вы скомпилируете их как в общей среде (либо с помощью кросс-компиляции, либо с использованием MingW в Windows), тогда компоновщик будет делать то же самое путь. Предполагая, конечно, что весь остальной код является кросс-платформенным и правильно настроен для целевой платформы.

   IMO, DLL hell был действительно более сложной задачей в прежние времена, когда приложения устанавливали свои DLL в общий каталог, такой как C: \ WINDOWS \ SYSTEM, что люди действительно не делают больше просто потому, что он создает аддон DLL. Вы можете поместить ваши общие библиотеки в более подходящее место, где оно не будет мешать другим незнакомым приложениям, или - самое простое - просто имейте их в том же каталоге, что и исполняемый файл, который им нужен.

Answer 3

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

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

Answer 4

Если это приложение, моим первым выбором было бы отправить статически связанный одиночный исполняемый файл.У меня была возможность работать с продуктом, который был отправлен на 5 платформ (Win2K, WinXp, Linux, Solaris, Tru64-Unix) и полагал, что поддержка разделяемых библиотек или библиотек DLL с большой базой данных - чертовски сложная задача. Предположим, что это нетривиальное приложение, которое включает использование стороннего графического интерфейса, потоков и т. Д. Используя C++, нет реального в одном направлении делать это на всех платформах. Это означает, что вам все равно придется поддерживать разные кодовые базы для разных платформ. Затем на разных платформах существуют некоторые странные поведения (ошибки) сторонних библиотек. Все это создаст нагрузку, если приложение будет отправлено с использованием разных версий библиотеки, то есть различные версии должны быть привязаны к различным платформам. Я видел людей, отправляющих библиотеки на все платформы, когда исправление предназначено только для конкретной платформы, чтобы избежать путаницы версий. Но это не так просто, клиент часто имеет другой подход к тому, как он/она хочет обновить/запланировать, что также необходимо учитывать.

Конечно, если бинарный файл, который вы строите, огромен, то можно рассмотреть библиотеки DLL/shared-libraries. Даже если это так, я бы предложил построить ваше приложение в виде слоев, например: - Приложение -> GUI -> Платформа -> База -> Фундаментальный

Итак, некоторые библиотеки может иметь общий код для всех платформ. Только конкретные библиотеки, такие как «Платформа», могут быть обновлены для конкретных действий. Это облегчит вам жизнь.

IMHO опция DLL/shared-library жизнеспособна, когда вы создаете продукт, который действует как полное решение, а не просто приложение. В этом случае разные подсистемы используют общую логику одновременно в рамках вашей структуры продукта, логика которой затем может быть разделена в памяти с использованием DLL/разделяемых библиотек.

НТНА,

Answer 5

Чтобы ответить на ваш вопрос с вопросом, почему вы делаете собственное приложение, если быть портативным является одной из ключевых целей?

Вы можете рассмотреть возможность перехода на виртуальную платформу, такую ​​как Java или .Net/Mono. Вы все равно можете писать библиотеки C++ (разделяемые библиотеки на linux, DLL на окнах) для всего, что было бы лучше, чем собственный код, но основная часть вашего приложения будет действительно переносимой.