Архитектура приложения для Codeigniter - несколько доменов, одна кодовая база, несколько баз данных - PullRequest
2 голосов
/ 22 января 2010

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

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

Для кодовой базы я пошел по пути создания всего, что нужно: одна установка codeigniter и связанного кода, и вся связанная с сайтом конфигурация находится в наборе файлов конфигурации, которые выбирают имя хоста и используют его для определения заголовка сайта , код отслеживания, каталоги css / js и т. д. Это, кажется, хорошая установка, и я вижу, что она работает для большого количества сайтов с одинаковым кодом.

Для баз данных, как можно управлять несколькими базами данных при изменении схемы в процессе разработки? Будете ли вы вручную вносить изменения в базы данных по мере необходимости или использовать автоматический инструмент? Здесь есть плагин Rails как миграция для Codeigniter здесь , который, кажется, может быть хорошей идеей.

Ответы [ 3 ]

4 голосов
/ 22 января 2010

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

Как выполнить настройку CodeIgniter на нескольких площадках

1 голос
/ 04 января 2012

У меня недавно была похожая ситуация. Я хотел, чтобы несколько каталогов работали в одном приложении, но использовали разные базы данных. Вот как я это сделал:

Сначала я создал несколько пустых подкаталогов. Для этого примера мы назовем их /subdir_1, /subdir_2 и /subdir_3.

В каждом из этих каталогов я сделал копию файла CodeIgniter index.php и поместил его в каждый каталог. Моя файловая структура теперь выглядит примерно так:

/application
/system
/subdir_1
     index.php
/subdir_2
     index.php
/subdir_3
     index.php

Это также может быть достигнуто с помощью некоторых правил .htaccess, но это совсем другая история.

В каждом из файлов index.php я изменил переменные $system_path и $application_folder, чтобы они указывали на каталоги /application и /system. Для моего конкретного случая я изменил свой файл index.php на:

/*
*---------------------------------------------------------------
* SYSTEM FOLDER NAME
*---------------------------------------------------------------
*
* This variable must contain the name of your "system" folder.
* Include the path if the folder is not in the same  directory
* as this file.
*
*/
    $system_path = "../system";

/*
*---------------------------------------------------------------
* APPLICATION FOLDER NAME
*---------------------------------------------------------------
*
* If you want this front controller to use a different "application"
* folder then the default one you can set its name here. The folder
* can also be renamed or relocated anywhere on your server.  If
* you do, use a full server path. For more info please see the user guide:
* http://codeigniter.com/user_guide/general/managing_apps.html
*
* NO TRAILING SLASH!
*
*/
    $application_folder = "../application";

В этот момент при нажатии любой из подкаталогов должно отображаться ваше приложение.

Отсюда нам нужно установить base_href для каждого каталога. Мы сделаем это с помощью простого изменения основного /application/config/config.php файла. Замените строку $config['base_url'] в файле /application/config/config.php на:

$uri = $_SERVER['REQUEST_URI'];
$pieces = explode('/', $uri);

if ($pieces[1] == 'index.php') {
    $config['base_url'] = 'http://' . $_SERVER['HTTP_HOST'] . '/';
    define('SITE', 'default');
} else {
    $config['base_url'] = 'http://' . $_SERVER['HTTP_HOST'] . '/' . $pieces[1] . '/';
    define('SITE', $pieces[1]);
}

Приведенный выше фрагмент устанавливает $config['base_url'] для соответствующего подкаталога (или корневого каталога, если его нет в подкаталоге).

Строка define('SITE', $pieces[1]) создает константу, к которой мы можем обращаться по всему нашему приложению, чтобы сообщить нам, в каком подкаталоге мы находимся.

Последний кусочек пазла - пусть наше приложение знает, какую базу данных использовать. В моем случае я хотел, чтобы каждый подкаталог использовал свою собственную базу данных. Для этого мы будем использовать константу SITE, которую мы создали в файле config.php.

В нашем файле /application/config/database.php мы собираемся добавить несколько альтернативных настроек базы данных. Для этого мы копируем настройки подключения к базе данных [default] и устанавливаем альтернативные настройки для каждого из наших поддоменов. Вот как выглядит один из моих сетов:

$db['subdir_1']['hostname'] = "localhost";
$db['subdir_1']['username'] = "[USERNAME]";
$db['subdir_1']['password'] = "[PASSWORD]";
$db['subdir_1']['database'] = "[DATABASE]";
$db['subdir_1']['dbdriver'] = 'mysql';
$db['subdir_1']['dbprefix'] = '';
$db['subdir_1']['pconnect'] = TRUE;
$db['subdir_1']['db_debug'] = TRUE;
$db['subdir_1']['cache_on'] = FALSE;
$db['subdir_1']['cachedir'] = '';
$db['subdir_1']['char_set'] = 'utf8';
$db['subdir_1']['dbcollat'] = 'utf8_general_ci';
$db['subdir_1']['swap_pre'] = '';
$db['subdir_1']['autoinit'] = TRUE;
$db['subdir_1']['stricton'] = FALSE;

У меня есть другие наборы для [subdir_2] и [subdir_3]. Теперь нам нужно сообщить нашему приложению, какие настройки базы данных использовать. Для этого мы берем константу SITE, поэтому последняя строка в нашем файле /application/config/database.php:

$active_group = (defined('SITE') && array_key_exists(SITE, $db)) ? SITE : 'default';

Приведенная выше строка устанавливает группу активных настроек базы данных для соответствия подкаталогу.

И это все :) Надеюсь, это кому-нибудь поможет.

1 голос
/ 22 января 2010

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

Это известно как ' Multitenancy '; и вы сможете найти множество архитектурных советов для этого.

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

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

Извините, я не могу предложить более конкретную помощь.

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