Думай Головой: очень даже реально. Работал в ремонте сотовых (ноуты делал редко, в основном знакомым и себе), оборудование там аналогичное (и не очень дорогое, кстати). Запчасти же берутся с доноров и покупаются у оптовиков ну вообще без проблем.
Alex_Wells: Странно, судя по описанию elephant.io должен был подойти. Можно по идее еще нативными функциями php по работе с сокетами обойтись www.php.su/stream_socket_client, а вообще почему логика разделена на два языка, не легче ли писать на одном? И поддерживать легче (по крайней мере в будущем достаточно будет разраба, который знает один язык).
Откуда вы взяли такую глупость? Поиск как раз часто реализуется именно в виде get запроса потому, что такую ссылку можно сохранить, отправить пользователю или скормить поисковику. В качестве примера вам как раз яндекс с гуглем, блоги и тысячи интернет-магазинов с фильтрами товаров.
phxdev: все с говнокода начинают, это нестрашно. В процессе деятельности вы все равно будете прокачиваться и новые знания получать, в том числе по архитектуре и в том числе из хороших чужих примеров, с ними говнокод и будет уходить от вас :)
ГЛЕБ ГЛЕБОВ: Commands deprecated. Их сейчас оставили только для совместимости, а так они полностью заменены на Jobs. Я лично предпочитаю разделять команды, которые отдают результат вызвавшему их контроллеру от команд, которые просто запускаются и чего-то кладут в очередь (Первые я несмотря на deprecated держу именно в папке Commands). И еще на затравку - между вашими командами и моделями можете репозитории положить дополнительным слоем :) вдруг потом захотите вместо eloquent использовать доктрину или сырые запросы к базе, либо если пилите опенсорс, то вместо вас это может захотеть сделать кто-то другой.
Sanes: Если это типовое делается на популярном сервисе, сделанном для широкой общественности, в том числе для сторонних разработчиков, то да. Но если маячит перспектива делать что-то на мутном движке местечковой конторы, лучше перестраховаться. Есть неиллюзорный шанс, что "типовое" в понимании программиста из этой конторы - это какие-то эксклюзивные велосипеды, отличающиеся по устройству от распространенных практик.
Andrzej Wielski: А это уже очень сильно зависит от деталей и требований проекта. В двух словах - не усложняйте без причины. Для атрибутов вполне подойдет many to many - каждый товар имеет разные атрибуты и каждый атрибут может быть у разных товаров. И не забывайте, что связующие таблицы - такие же таблицы, как и все остальные. Для них иногда легче сделать модель и получать все что нужно через hasmany или с помощью with, чем городить огород и получить кучи лишних запросов.
hitakiri: ну если хорошо погуглить, то наверное можно, https://github.com/Xethron/migrations-generator поставьте. Можете в крайнем случае в качестве первой миграции создать скрипт, импортирующий sql со структурой вашей таблицы еще.
amfetamine: Возможно, в этом у нас разные взгляды. Для меня opencart - это движок для создания магазинов и я использую его исключительно в сочетании с теми контроллерами и моделями, что он предоставляет помимо папки system. То есть для меня модели, позволяющие брать из базы товары или заказы - это неотъемлемая часть движка, если вы пишете проекты исключительно на ядре opencarta, прошу меня извинить за неточную формулировку, просто я предпочитаю использовать для этого полноценные фреймворки. Переформулирую вопрос: в какой ситуации изменение кода контролеров и моделей, идущих с движком opencart надежнее, чем написание кода в виде отдельного модуля?
Александр Макаров: Просто мысль зацепилась за фразу "а почему бы тогда не оставить всю логику на уровне приложения (php)". Если кто-то посчитал, что не стоит - это ответ на заголовок, приношу всем свои извинения.
