Высоконагруженный проект на php без фреймворков?

Question

[svilkov87]

Добрый день!
На сколько реально и логично создавать высоконагруженные проекты (порталы, форумы итд..) без использования фреймворков php, используя процедурный стиль? Будет ли это правильным подходом? Какие трудности могут при этом возникнуть?

Спасибо.

Comments

[vasIvas]

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

[Oleg Shevelev]

Соглашусь с vasIvas, ведь фреймворки тоже люди пишут, часто что бы реализовать свои какие-то потребности.

Answer 1

[Владислав]

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

Answer 2

[Tlito]

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

Answer 3

[Семен]

Я работал в компании iMesh Inc. (60 млн. активных клиентов) - там все было на процедурном PHP4, но это было в 2009-2010, сейчас не знаю как там.

Answer 4

[Александр Мелеховец]

Без PHP-фреймворков - вполне возможно, есть же фреймворки на Python, Ruby, Java. В процедурном стиле - не вопрос, но в итоге оно будет работать медленнее, потому что с нормальным ооп вносить изменения в приложение будет дешевле, чем с процедурщиной, и сэкономленное бабло можно вложить в железо.

Answer 5

[Станислав]

Не нужно пренебрегать грамотной архитектурой и готовыми библиотеками. Ну и процедурно писать глупо серьезный проект. Лучше купите www.ozon.ru/context/detail/id/33506422 изучите, потом идите на github.com или https://packagist.org/ берите готовые библиотеки и на их основе стройте свой проект. 90% велосипедов уже написанны и протестированны профессионалами, вам осталось понять принцип построения архитектур высоконагруженных систем, а так же ООП/Паттерны )

Answer 6

[xmoonlight]

Вполне возможно и даже НУЖНО пробовать создавать, т.к. нормально работающих "велосипедов" сейчас нет.

Плюс ко всему, Вы сможете наступив на те же "грабли", что и все, кто разрабатывал свой "дижок" с нуля, прокачать свой уровень знаний.

Реальные и основные "грабли":
1. Организация модели и структуры приложения: пласты абстракций © (роутер, сервис, ACL, шаблон, сессия, валидатор, хранилище (БД, файловая структура, сторонний веб-сервис) и т.д.) с одной стороны и MVC-модель с другой.
2. Предотвращение использования дублирующейся логики или кода внутри всего приложения. Таким образом, решив эту проблему: уменьшится время разработки и использование памяти.