о велосипедах

[igortik]

Я все компилирую в голове как сделать лучше ...

MVC принцип ясен, с ТТУК тоже знаком не по наслышке, но вот вопрос, который меня интересует:

- в идеале по принципу MVC у нас есть, например, uri http://host/controller/action
логически очевидно, что обращаясь к конкретному контроллеру мы обращаемся к некоторому из его действий (экшн), собственно в чем вопрос:

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

1. Есть модуль new
2. Есть контроллеры /news/controllers/ ...
3. Есть модели /news/models/ ...

Запрос /host/news/do_something вызовет контроллер do_something, который будет работать с моделью do_something.

Но такой подход увеличивает кол-во файлов и мой мозг уходит в бесконечную рекурсию

Вообще, с Вашей точки зрения, как должно быть, если в целом говорить еще и о понятии модуля в системе, т.е. неких папок modules, хранящих модели, контроллеры и даже статику (css, js, forms layouts).

За статику не бейте, вся статика берется на правах инклуда и выводится выше php-файлов (которые лежит ниже корня), на мой взгляд, так проще выдерживать понятие модульности, т.к. все лежит в одной папке, что касается данного модуля.

Спасибо

 

[Духовность™]

- в идеале по принципу MVC у нас есть, например, uri http://host/controller/action

MVC к URL и способу их обработки отношения не имеет.

тоже самое касается и контроллера

У меня 1 контроллер = 1 action. У контроллера один основной метод run. Контроллеры наследуются, тем самым я избегаю дублирования кода.

Но такой подход увеличивает кол-во файлов

Мне такой подход очень нравится.

 

[igortik]

Духовность™
Спасибо, мнение очень важно!
Про URI я написал, стараясь показть ход мыслей.. ясно, что MVC не имеет к этому отношение, а скорее, здесь уже речь идет о роутере запросов..
Просто в моей системе по дефолту, если нет юзерского роутера, то парсится урл именно таким способом + куча доп. логики, но без регулярок

 

[AmdY]

igortik
не волнуйся о количестве, размере файлов и даже скорости работы, если это нужно для быстрой, качественной и удобной разработки и поддержки.

 

[Духовность™]

не волнуйся о количестве, размере файлов и даже скорости работы, если это нужно для быстрой, качественной и удобной разработки и поддержки.

Вот-вот.

Вообще, такие вопросы от давления стереотипов. Надо делать так, как считаешь нужным.

 

[igortik]

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

В то же время, разделение контроллера на действия (независимые контроллеры) как-то лаконично группирует все по полочкам, но создает n-ное кол-во файлов.

Плюсы и минусы очевидны :/

Духовность™
Действительно.. стереотипы давят на мозг, но не дают спокойно спать, ведь писать стараюсь не только для возможности самому использовать и работать с кодом...

 

[craz]

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

Как я понимаю лучше заинкудить один раз много чем много раз по малу.

 

[igortik]

Как я понимаю лучше заинкудить один раз много чем много раз по малу.

я бы не советовал так мыслить, иначе получится joomla #2 или иная говно-цмс, где всегда есть все "про-запас" и хостинг нужен волшебный для комфортной работы, минимум VPS

 

[craz]

я бы не советовал так мыслить, иначе получится joomla #2 или иная говно-цмс, где всегда есть все "про-запас" и хостинг нужен волшебный для комфортной работы, минимум VPS

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

 

[igortik]

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

здесь соглашусь, конечно.

Я гонюсь за скоростями, т.к. являюсь сторонником интерактивных приложений (сервисов), вся фишка которых - ajax, т.е. мне нужно максимально быстро выполнить запрос и вернуть результат, при этом этот запрос будет практически полноценным (за исключением полной работы с view), т.к. все запросы валятся на одно ядро, т.е. в итоге это выходит реальный запрос, тянущий за собой всю цепочку данных.

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

 

[AmdY]

igortik
а чем ajax отличается от обычного запроса?

 

[igortik]

igortik
а чем ajax отличается от обычного запроса?

ничем по существу. Учитывая, что я могу на один клик юзера вызывать несколько запросов, то отсюда и растут корни желания сделать все максимально оптимально.

 

[igortik]

меня еще интересует один момент - как и кто должен рапортовать системе (ядру) о том, что мы работаем в режиме "полного вывода" (вывод общего шаблона), ведь запрос инициирует работу контроллера, выходит, конкретный контроллер?

Я просто ранее использовал запросы вида: http://host/ajax/module/controller
"ajax" инициировал создание константы, которая участвовала в логике работы контроллера...

на сколько это плохо или бесполезно, на Ваш взгляд?

 

[AmdY]

ну да. можно передавать принудительно параметр, но лучше анализировать заголовки,

class Request {
    public function isAjax() {
        if ($this->get('ajax') == 1) {
            return true;
        } elseif (isset($_SERVER['HTTP_X_REQUESTED_WITH'])
                && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
            return true;
        } else {
            return false;
        }
    }
}

 

[igortik]

Великолепно!

А что на счет манипуляции над выводом?
Бывают случаи, например, нужно вернуть только результат выполнения модуля (конкретного контроллера) и обернуть этот результат "в фантик" (view конкретного контроллера).
В данном случае сам контроллер должен принуждать view к выводу?

p.s. вопрос покажется немного глупым, просто реализации бывают разные, вот у меня была такая:
1. Есть массив допустимых экшенов в конфиге модуля, например, тех, которым вывод вовсе не нужен, их задача - контроль работы модели (апдейт данных в базе, например)
2. По этому массиву решалась данная логическая задача с view

 

[c0dex]

AmdY +1
у меня примерно так сделано через проверку переменной в SERVER

 

[craz]

Великолепно!

А что на счет манипуляции над выводом?
Бывают случаи, например, нужно вернуть только результат выполнения модуля (конкретного контроллера) и обернуть этот результат "в фантик" (view конкретного контроллера).
В данном случае сам контроллер должен принуждать view к выводу?

да это событие рендер для вью хелпера

 

[AmdY]

igortik
никакой массив не нужен, экшен должен быть самостоятельной единицей и не требовать никаких записей в другом месте, а изменять стандартное поведение он может и сам.
$this->render = false;

хотя я теперь от автоматического рендеринга отказался и делаю его принудительно
$this->setModule('шаблон данного контроллера');
$this->display();

 

[igortik]

да это событие рендер для вью хелпера

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

 

[igortik]

igortik
никакой массив не нужен, экшен должен быть самостоятельной единицей и не требовать никаких записей в другом месте, а изменять стандартное поведение он может и сам.
$this->render = false;

AmdY
спасибо
важно было для меня это еще раз подчеркнуть