?

Log in

No account? Create an account
Main

Архитектурный вопрос про MVC

Задал волнующий вопрос про архитектуру MVC в ru_php
http://community.livejournal.com/ru_php/1504684.html

Если не трудно, загляните туда пожалуйста.

Comments

Один вопрос есть: "Ну вот нахера это в php для веба?"
Программирование ради программирования что-ли?
хм. ну если программить что-то более сложное, чем гостевая книга, без mvc не обойтись, иначе сам будешь себе злобный буратино. Ну или на php не писать. Но на java все это есть внутри, и она явно тяжелее php, в рельсах это тоже есть и в django. А где нету?

Наверное есть и другая парадигма какая-нибудь. Но я ее не знаю :)
Про более сложное - это прикол что-ли такой?
Вот sport-express.ru например - это гостевая книга или более сложное?

каждый программист мечтает о "чтобы сделать чтобы ничего не делать", я такой же (:
систематизации повторяющихся задач это нормально! а mvc и php как средство(плохое или хорошее не важно) решения этих задач, и не более.
Мне было бы интересно посмотреть, как там сделано внутри, если это не mvc. Об этом можно где-нибудь прочитать?
Нет, пресс-релиза нет ;-)
от про спорт-экспресс не надо :)
Вы видимо имеете в виду, несколько скриптов-точек входа и реврайт апача вместо роутера, внутри скрипта.

Я должен немного подумать, чтобы написать интересующие меня вопросы, по поводу такой организации. Мне все-таки кажется, что хотя некоторое общее разделение и можно вынести в это место (админка-фронтенд, медиа файлы (тут вообще nginx можно навесить), еще что-то служебное), более детальное разделение -- статьи, список статей, комментарии и т.д., все таки лучше разгребать в скрипте. Но нужно проанализировать перед тем, как так утверждать.
> без mvc не обойтись, иначе сам будешь себе злобный буратино
Я одного товарища допинал-таки и он сделал нормальный URL-парсер для его сайта. В общем, получился у него детерминированный автомат. Тут он потестировал свое изделие и прибежал ко мне с выпученными глазами и испуганным голосом говорит: "раньше соотношение нагрузок было system=10% user=90%? а сейчас стало system=85% user=15%. Что я не так сделал?". Пришлось объяснять, что раньше у него код писался как Бог на душу положит, вернее как MVC, неэффективно. Сейчас, после того как он сделал основу сайта в виде автомата URL-парсера, то весь код сразу нормализовался и превратился в детерминированный автомат. Т.е. его программа не выполняет ненужных, лишних действий. Время исполнения запроса раньше у него было 230-250 мсек, а стало 15-18 мсек. И, поскольку он оптимизировал свою клиентскую программу, а ядро системы никто не трогал, то и получились такие соотношения нагрузок.
>Я одного товарища допинал-таки и он сделал нормальный URL-парсер для его сайта.
>В общем, получился у него детерминированный автомат.

А как у него было до этого? Что еще может делать парсер урлов?

>как Бог на душу положит, вернее как MVC,
>неэффективно. Сейчас, после того как он сделал основу сайта в виде
>автомата URL-парсера, то весь код сразу нормализовался и превратился в
>детерминированный автомат. Т.е. его программа не выполняет ненужных,
>лишних действий.

Опа. А где-это MVC провоцирует неэффективный разбор урлов? Вроде как раз именно конечный набор состояний и вызов подпрограмм в зависимости от состояния она и проповедует?

>"раньше соотношение нагрузок было system=10% user=90%? а сейчас
>стало system=85% user=15%.

Ага, это и правда забавная реакция на оптимизированное приложение
> Что еще может делать парсер урлов?
Это обычный автомат. Что запрограммируете, то и будет делать. Посмотрите yacc и bizon. Для perla есть тоже модуль Yapp.

> А где-это MVC провоцирует неэффективный разбор урлов?
MVC - это не преобразователь грамматик и не построитель автоматов из грамматик. Очень сомнительно, что можно построить детерминированный автомат не занимаясь анализом и преобразованиями грамматик.

> это и правда забавная реакция на оптимизированное приложение
Проверялось на машине командой ab -n 10000 -c 100 <тестируемый _URL>
На другом терминале была запущена команда top.
В MVC разбор урлов это некоторый компонент. Урл должен быть разобран на составляющие: модуль-действие-парметры. Все. Больше ничего про разбор урлов MVC не говорит.

Насколько я помню yacc и bizon это лексические парсеры для ЯП. Не слишком ли круто ими урлы разгребать? Какие там причудливые грамматики в урлах могут быть-то?
> Какие там причудливые грамматики в урлах могут быть-то?
Я думаю, что стоит один раз попробовать описать все допустимые URL конкретного проекта в виде грамматики.
А в рассматриваемом примере именно yacc или bizon дали такой прирост производительности при разборе урлов лексическим парсером?
Человек писал для PHP. Писал по мотивам построения автомата перловым модулем yapp. Но даже та кастрированная версия, которую он сваял, дала неплохие результаты.
ну зависит от того, чем вы занимаетесь. если сидите программите один сайт, то похеру, какая у него архитектура, лишь бы работало и вам было удобно.

если у вас производство движков поставлено на поток (похожих, но не одинаковых, т.к. у каждой кастомизации своя специфика), то MVC очень даже решает.

так что тут дело не в "сложности", а в производственном процессе.

Дима, я тебе там ответил.

У модуля есть стандартное поведение - "всё, что начинается на мой base_url, то моё". В то же время, если модуль какой-то хитрый, то он это поведение может переопределить, отобрав себе какую-нибудь няшку.
Перестал следить за ru_php.
Но на ваш пост написал ответ.