MVC php

[Hector]

Мне тут пара разрабов делали проекты на похапэ но хоть они и брали фреймворки но все выглядело примерно так:
1. Вьюха тут понятно, шаблон с каким-то smarty, или просто пхп
2. Контроллер куда пихалась логика и запросы в базу данных. Между базой и контроллером была прослойка под pdo или mysqli.
3. А моделей нет. Объектов тоже нет.

Когда проект растет то из-за отсутствия моделей и объектов получается каша. Каждый метод контроллера берет данные в каком ему удобно виде, тут либо звездочка в mysql запросе либо именованные поля. Это порождает кучу дублей при выборке данных.

Вы скажите это нормальная практика так делать или это говнокод? Надо ли переделывать проекты в таком стиле или проще забить?

[Dippa]

Это ненормальная практика. У такого говнокода есть название - Fat Stupid Ugly Controllers.

Если работает - забей. Если работает криво могу переделать под HMVC.

[Hector]

Оно работает но проект получается раздутым больше чем нужно. Я чего спросил думал мало ли в этом кроется тайный смысл что эту схему применяют многие. В java например такой фокус не проходит.
Один разраб сказал что это большая гибкость.
Один такой контроллер например имеет 6000 строк

[isoff]

Сообщение от Hector

2. Контроллер куда пихалась логика и запросы в базу данных.

Это дикость. Если предполагается что проект будет развиваться.

[веломан]

Сообщение от isoff

Это дикость. Если предполагается что проект будет развиваться.

+1
контроллер пилит только запросы: на авторизацию/AJAX/шаблонов
в принципе нет ничего сложного их по файлам раскидать - простой копи-паст + чуть допилить
а вот разбросать кучу запросов по моделям и объектам будет сложнее
нужен глубокий рефакторинг

[Hector]

Там рефакторить надо очень дохуя плюс во вьюхи залетают то user_id то userId. Переделывать нужно начиная с моделей.

[веломан]

Сообщение от Hector

очень дохуя

ага, это синоним слова "глубокий" )

Переделывать нужно начиная с моделей.

как же их переделывать, если их нету?

в общем радуйся, что тебе её вообще написали
зная рынок пхп-студентов ты ещё молодец, что нашёл исполнителей, которые до конца довели
были бы они чуть поумнее, зарефакторили бы сами и набрались бы опыта

[Markus]

Так делать можно только в одном случае, если вас быстродействие не устраивает.
ORM накладывают дополнительные расходы и не всегда позволяет описать качественно взаимосвязи между объектами БД. Если под траф и не ТП писали то так даже лучше.
А насчет как это все выглядит это уже другой вопрос, главное чтобы документация было сопроводительная для дальнейших доработок =)

[Hector]

тут не орм я имел ввиду а обычные dao с моделями
orm я терпеть не могу

Markus, какая документация там даже коментов по коду нет))))
Это я так по неопытности заказывал))

[Markus]

Сообщение от Hector

тут не орм я имел ввиду а обычные dao с моделями
orm я терпеть не могу

Markus, какая документация там даже коментов по коду нет))))
Это я так по неопытности заказывал))

Ну DAO разные есть, иной раз лучше вообще них. Где идет обычный роутинг + шаблонизатор а запросы в контроллерах. Сразу видно что и откуда. Свой DAO нужен если планируется менять источники данных, а так и PDO стандартной хватит.
Это зря всегда требуй чтобы комментарии везде писали... Потому что чувак который будет это дорабатывать может не понять логику того кто писал. В итоге ошибка может вылезти уже после сдачи.
PS можно еще и тесты зафигачить)