2012-01-08 7 views
2

У нас есть два веб-сайта, построенных поверх одних и тех же данных. Их дизайн (и представление данных) совершенно разные, но базовые данные одинаковы.рельсы: два сайта - одна база данных

Оба имеют свой домен верхнего уровня.

Каков наилучший способ структурирования этого? Есть 2 разных приложения для рельсов? или два набора точек зрения?

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

Предложения, ссылки на статьи и т. Д. Наиболее приветствуются!

ответ

3

У нас есть несколько приложений, которые используют общие базы данных по адресу Aframe с набором общих моделей.

Try что-то вроде этой структуры:

app_one 
    rails app structure 
    ... 
app_two 
    rails app structure 
    ... 
shared 
    models 

Затем в каждом из приложений, включить все, что в общей разделяемой директории/модели.

Настройте оба приложения для получения одинаковых сведений о базе данных.

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

+0

+1 i.e. 2 приложения. –

+0

не это, по сути, ручная работа двигателя? С двигателем вы также можете делиться моделями. – phil

+0

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

2

Зависит от необходимости доступа ко всем данным в обоих приложениях или только к определенным частям.

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

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

+0

+1 Также верно, что следует учитывать текущий или будущий объем таблиц и сложность приложения. –

+0

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

+0

@phil вы могли бы это сделать, но если база данных не очень большая, вы можете просто пойти с двумя приложениями и быть счастливыми. Иногда разумнее идти с менее совершенным (некоторые дубликаты), но более практичным решением. –

Смежные вопросы