Архив веб-приложений - Общее решение + независимый экземпляр -> Рост и обслуживание? - PullRequest
1 голос
/ 02 марта 2011

В настоящее время я работаю над веб-решением (backend & frontend), которое будет доставлено нескольким клиентам.Каждый из них будет размещаться независимо со своей собственной базой данных.

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

Важным моментом является то, что в любом случае приложение / сайт /Решение (особенно в веб-интерфейсе) не будет одинаковым для всех, и некоторые файлы (шаблоны // CSS / ...) будут независимыми.

Поэтому мой вопрос заключается в том, как нам разработать / структурировать такое приложение, чтобымы можем поддерживать его годами и несколькими клиентами?Я не хочу устранять ошибку в одном «экземпляре», и мне нужно скопировать ее на 50 других клиентов, где может возникнуть другой конфликт, потому что мы забыли скопировать предыдущую версию файла X ...

Одним из решений, о котором я думал, является:

  • Создайте один BASE-проект, который будет содержать все классы, компоненты, общие для всех, и предлагает своего рода «каркас».
  • Создание одного проекта для каждого клиента (одна независимая папка).
  • SYMlink все файлы / папки, которые будут поддерживаться глобально (на уровне BASE).

Преимущества:

  • Одно изменение в базовом проекте (новая функция / исправление ошибки ..) будет автоматически доступно везде.
  • Мы все еще можем сохранить определенноеУровень «независимости» в коде, так как каждый проект независим и файл может быть обновлен (кроме базового)

Я не уверен в том, что является лучшим решением и есть ли«лучшая практика» для таких.Пожалуйста, поделитесь своим опытом по этой теме.

Спасибо!

1 Ответ

1 голос
/ 03 марта 2011

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

Возможно, вы захотите следовать определенному типуархитектура.MVC является наиболее популярным, в котором часть, которая обрабатывает взаимодействия с базой данных (M), рендеринг результатов в html (V) и часть, которая выполняет сложные операции (C), являются отдельными.

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

Кстати, я разработчик Python / Django, и я использую эту комбинацию для создания проектов, придерживающихся DRY (не повторяйте себя)) принцип, а также для ваших нужд, имеет возможность предоставить конкретные настройки сайта.Поскольку вы упомянули в основном о различиях внешнего интерфейса, в качестве примера, он позволит вам указать приложению использовать template1 (html, css) при доступе к www.example1.com и template2 при доступе к www.example2.com,все же они все живут в одном экземпляре проекта.

Надеюсь, что это помогло.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...