Как Вы развертываете и управляете веб-приложением C# клиенту с некоторыми незначительными различиями от Вашего основного проекта?
Лучше всего использовать SQLite, если вы хотите манипулировать данными, особенно если вы думаете, что база данных будет расширяться. Посмотрите здесь о том, как создать базу данных в Android.
Как использовать SQLite в Android?
Используя его, вы сможете создать базу данных, вызвать ее и вернуть результаты в упражнении
I Я не уверен насчет файловой структуры в AIDE, но я уверен, что вы можете понять это с помощью метода проб и ошибок.
4 ответа
Ответвление Ваш код.
Надо надеяться, Ваш код является источником, которым управляют (в противном случае запускаются теперь!), необходимо перейти от основы до "Клиента X" ответвлений и просто сделать небольшие косметические модификации в том ответвлении. Затем просто создайте и развернитесь прочь того ответвления для того клиента.
Кроме того, если изменения достаточно незначительны, Вы могли бы попытаться делать изменения настраивающимися. Тем путем Вы могли развернуть тот же сайт везде и просто изменить конфигурацию для соответствия тому, что хочет клиент. Чем более сложный различия, тем тяжелее это должно будет сделать их настраивающимися все же.
После рассмотрения комментариев: Его польза, чтобы отметить, что конфигурация практична, но ТОЛЬКО ЕСЛИ # изменений незначительны, иначе Вы загрязните свой код логикой конфигурации. (Спасибо комментаторы)
Так: много изменений-> Ответвление (более удобный в сопровождении), немного незначительных изменений-> Делают настраивающимися (более практичный).
Мы обычно имеем те значения, будучи управляемыми данными. Различием клиента является просто другая установка; любой другой пользователь в будущем мог также снова использовать те же "пользовательские" опции позже.
Создание "одноразового" s не масштабируется.
Пользовательские патчи являются болью по этой самой причине. Мы обычно просто переходим в нашей системе управления исходным кодом и вручную применяем изменения после обновления со сценарием. Из-за дополнительных издержек мы препятствуем пользовательским патчам как можно больше.
Мы должны сделать все это время. Мы пытаемся обобщить и иметь значения между настраивающимися версиями. Наиболее распространенные причины настроек:
- дополнительные поля базы данных: мы реализовали динамический способ сохранить эти объекты в дб
- Расположение UI: у нас есть специальные папки, куда мы помещаем изображения и файлы CSS, которые загружаются по требованию
- различные обязательные поля ввода: мы храним определение в конфигурации и активируем их программно
- специальные отчеты: мы помещаем шаблонные файлы в пользовательскую папку, чтобы быть выбранными вместо стандартного шаблона
Некоторые изменения требуют программирующих новых модулей. Мы кодируем их в пользовательской библиотеке, которая будет динамично загружена в главном приложении.