Dauren: Повторюсь - вам не запрещают в Laravel все сделать в какой то директории.
/App/Controllers
/App/Models
/App/...
или
/AppCore/Models
/AppCore/...
/AppMain/API/v1/Controllers/..
Структуру можно делать любую, какую вам удобно, как и в SF
Dauren: Как минимум AR, постоянные Singelton, многокостыльность для гибких проектов.
Т.е. вам придется делать или по документации проект или писать костыли на постоянной основе.
Суть в том, что yii2 это более монолитное сооружение и подходит для быстрой реализации простых проектов.
Плохо подходит для реализации RESTful API (правильного стандартизированного API)
SF3 это гибкая система, типа завода по производству деталей и бетона для строительства дома.
Данный фреймворк, оч. гибок и не ограничен какими то правилами. Имеет все необходимые инструменты для работы с API. Так же, sf учит работать с объектами и забыть про SQL, кучу нативного кода и т.д.
Laravel, это можно сказать - компромисс между Yii2 и SF3
Dauren: Да пишите все в одной директории. Не хотите делать правильно и грамотно, ваше право.
Вот вы говорите - ладно симфони, хоть в бандлах. А то что модели разделены от представления и т.д., это вы не замечаете.
И в симфони опять же, пишется все по другому.
Простой пример архитектуры приложения.
AppBundle - тут содержаться базовые конфиги, контроллеры, команды, хендлеры и возможно представления.
CoreBundle - тут содержатся персистенции, модели, репозитории, маппинг и все что связанно по работе с данными.
Конечно, вам не кто не запрещает все сунуть в одну кучу (это можно сделать как в Laravel так и в Symfony).
Но тогда вам будет оч. сложно работать с HL++ проектом.
Я вам отвечал исключительно о HL++ проектах, т.к. вы ранее задавали вопрос Yii2 или Symfony3?
Разбивайте все на логические сущности, делайте связи и работайте по ним
Вводные данные: Россия, Москва, с х по y на 1 взрослый и 1 ребенок.
Ищем квоты по привязанному типу размещения SGL/ DBL/DBL for Single use.
Дальше у вас связь должна идти к тарифам/ценам, тут мы найдем более выгодные предложения и отсортируем как того требуется.
Все предложения имеют связь с отелем.
При поиске, учитываем местоположения (в связи отель-город-страна) и периоды прибывания (ищем в квотах и ценах)
Более подробно, надо уже разбирать, что к чему в вашем бизнесе.
Я сказал на примере некоторых наших букинг сервисов.
driver458:
1) Это не скрипт а просто функция
2) Если не ваш, то стоит сначала все изучить а затем подробно задавать вопрос.
3) Вам надо сделать на др. сервере, так пропишите нужный путь, или дайте развернутый вопрос.
Еще для реализации RESTful API я был посоветовал подключить swagger.