Данные на одной стороне, API для предоставления данных на другой стороне -> 2 разных проекта со своим собственным слоем ORM?

Question

Это не классический вопрос о языке программирования, но он заставляет меня быть занятым, поэтому я решил, что я мог бы также воспользоваться опытом Stack: -)

У меня есть система, которая принимает данные измерений из разных источников. Эти сообщения с данными помещаются в очередь. Теперь мне нужно построить:

1. Система для регулярного чтения сообщений из этой очереди и сохранить данные внутри них в базу данных (возможно PHP-скрипт, который вызывается хрон)
2. Система для предоставления этих данных внешним сторонам (реализована как API / вебсервис)

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

Теперь, если я использую два проекта, мне придется использовать Doctrine в обоих, причем оба они имеют объекты, которые отражают одни и те же таблицы в базе данных ниже. Поэтому, если БД изменится, мне нужно изменить модель двух проектов. Это неправильно.

Я могу использовать один проект с одним ORM, поэтому, если есть изменения, мне нужно будет изменить только один слой. Однако тогда у меня есть и скрипт, использующий эту модель, и веб-сервис, все в одном «проекте».

Мышление буквально «проектов», как, например, в Netbeans. Я полагаю, я бы создал папку 'model' с объектами Doctrine, папку 'script', к которой обращается cron, и папку 'api', к которой обращается веб-сервер.

Кажется странным, что в одном проекте есть разные приложения, но также лучше иметь только один слой ORM. Что приличного делать?

Answer 1

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

Что касается изменения схемы и использования ORM, я бы предложил проверить MongoDB (или другую NoSQL DB, я склонен к Mongo, потому что это то, что я знаю). Вы все еще, вероятно, захотите использовать что-то вроде Doctrine, но, поскольку оно по своей природе «без схемы», вы можете быть немного более гибкими с тем, что вкладываете в него. Я предлагаю по-прежнему использовать Doctrine, потому что это может быть как пассивом, так и активом, если вы не справляетесь с этим должным образом (т. Е. Вставьте дату в целочисленное поле, и Монго это не волнует ...)