В продолжении этой темы вот что сейчас имею: модель, где есть функции добавления для type и word, вспомогательные функции. Сейчас требуется добавить еще 3 функции, которые тоже будут добавлять в БД. Назовем их param1, param2, param3. К ним тоже нужны будут вспомогательные функции и т.д. Модель раздувается. терпим. Но если есть добавление должно быть и удаление, а там и на подходе CRUD. То есть запись мы должны будем добавить, удалить, редактировать, обновить. А для каждого еще валидаторы всякие, хэлперы, да еще и поиск + выборка по ид. Все страшно пухнет и модель превращается в помойку. будет ли разумнее сделать для каждого отдельно добавляемого в БД параметра свою модель, куда запихивать весь CRUD, хэлперы, поиски, выборки, а текущая модель таким образом похудеет и будет в себе вызывать другие модели( ну или как там правильно). Явно я не изобрела ноу хау и это уже реализовано, только я не знаю название
То есть было: MyModel.php где все содержится, а будет: MyModel.php, Param1Model.php, ..., ParamNModel.php. Единственное, что делать с контроллерами это еще не додумала

Я делаю так, если к примеру есть выборка данных одинаковая но разные таблицы, то я передаю переменую в функцию с названием таблицы.
С удалением точно также, только дополнительно передаешь условие или же можно написать отдельные функции.
Редактирование, смотря по месту

Я вот недавно проект переписывал но не сразу а постепенно и у меня началось - для работы с ордерами отдельный хелпер, потом с сервисами отдельный, потом с юсерами отдельный и при этом в итоге у всех есть такой запрос на полную выборку и получается в итоге 3 одинаковые функции. А зачем они одинаковые? Потом переписал и сделал одну функцию, только в итоге остальные пришлось править. Я бы то что одинаковое сделал в одном экземпляре и такие функции запихал в отдельный файл.
Хотя.... Кому как Кому то проще к примеру как я описал отдельный файл с функциями для работы к примеру с юсерами

А вообще создай ядро, где нет вот таких копий, вот к примеру на полную выборку одна функция, на выборку одной колонки одна функция, на выборку одной строки одна функция, на выборку одной переменой одна функция, удаление одна передаешь таблицу и условие
Ну как то так

Благодарю

Итак, какие же мысли надумала в итоге. Раньше помню часто были движки в которых вся требуха была видна, то есть ссылки были вида: site.ru/audio.php; site.ru/add_audio.php; site.ru/create_audio_album.php и т.д. - так быть не должно. Все должно быть опрятно и аккуратно. Поэтому должен быть один файл являющий чем то единой точкой входа но только для одного модуля. Например на сайте будет аудио, видео, фото соответственно будут следующие единые точки входа для этих модулей: site.ru/audio.php; site.ru/video.php; site.ru/photo.php. На модуль могут быть возложены обширные задачи, то это не значит, что 1 модуль 1 точка входа 1 контроллер 1 модель. Допустим модуль аудио будет у нас загружать аудио, редактировать, удалять, обновлять, создавать альбомы, редактировать альбомы, удалять альбомы, загружать обложки для треков и т.д. Если будет 1 класс-то будет он очень большим. Проще сделать так(имхо): AudioController.php, AudioAlbumController.php, Audio...Controller.php. В каждом задать методы add, update, delete, edit и другие. А тогда файл audio.php будет в зависимости от задачи подгружать свой подмодуль и выполнять.
Пойдет ли так?

Предпочитаю все адреса с index.php
Для обложки аудио соответственно index.php?act=audio&part=album
Для эстетов можно это распилить мод-реврайтом.

_____________
Бесплатному сыру в дырки не заглядывают...

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

act=audio — подгрузить audio.php в котором класс audio, в нем уже обрабатывается, что param=album означает подгрузить album.php с классом album.

_____________
Бесплатному сыру в дырки не заглядывают...

Возможно я не права, но мне кажется много подгружать. Тем более audio.php подгружаем только ради определения чего подгружать дальше. То есть это как бы саброутер получается. Но все равно обдумаю вариант.
Единственное вот что задумалась: альбомы есть у фото, видео,аудио. album.php будет непонятно альбомы чего вызываются. Может называть так: PhotoAlbumController.php, VideoAlbumController.php? Хотя с другой стороны эти названия будут выбиваться из: UserController.php, ProfileController.php где по сути одно слово.

Вообще я не очень сам люблю принцип MVC
Делаю так, создаю библиотеку общих функций, библиотеки функций для работы с тем и тем
Имею единую точку входа
Подгружаю всю эту кучу в один файл и там разгребаю могические кавычки, кодироку, глобальные переменные, создание объектов класса, далее уже знаю по роутеру какая страница передана, ее заголовок, описание и так далее
Мне чаще попадаются проекты где нет основного шаблона и пишу правила для подключения того или иного шаблона
Обработка данных в осносном на аджаксе, все запросы пердаю в один файл, в этом файле подключаю ядро и файлы обработки запросов, спецом не пишу в один файл обработку, просто потом отыскать нужное проще
Ну вот как то так. Иногда подгрузка даных чрез аджакс, иногда через dataTable а так если не то и не то просто функция из библиотеки котораю те или те данные выводит

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

Ну вот пример, имеем две ссылки

1 На категорию biznes
2 Вторя на пост из этой категории biznes/post

Допустим правило и подключение

$inc = array('biznes' => 'modyl/category/rouner.php');

$reqvest = Допустим сюда передаем перевый индекс REQUEST_URI

if (array_key_exists($reqvest, $inc)) {
	
    include $inc[$reqvest];
} else {
	notfaund();
}

В роутере уже разбираю. Если есть второй индекс и он передан получаю post подключаю шаблон для post, иначе выведу весь список который находится в biznes

Ну вот в принцепе примерно так

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

Спасибо.

В продолжение.
Посмотрела разные порталы, крупные и не очень. Не обошла стороной и ВКонтакте. Увидела у них некий бардак, а именно: для фотоальбомов есть отдельная(персональная скажем так) ссылка вида https://vk.com/albumN_M и https://vk.com/albumsN для списка всех альбомов.Так же есть еще отметки(сейчас остались только для фото, для видео прикрыли) которые тоже имеют отдельные ссылки вида https://vk.com/tagN Для видео такого нет, а альбомы и другое представлены в гет параметре section, то есть альбомы имею ссылку https://vk.com/videosN?section=album_M. С аудио все еще печальнее. Плейлисты(так они называются у них) имеют ссылки вида: https://vk.com/music/album/N_M. Казалось бы, все отлично для сео и чпу, но при нажатии такая ссылка не откроется( даже если скопировать и вставить в строку), а откроется монстроозная ссылка вида: https://vk.com/audiosN?section=all&z=audio_playlistN_M и https://vk.com/music/album/-N_M_hash-salt. Тут уже плейтлист хранится в гет параметре z. Поизучав еще, поняла, что ВКонтакте для параметра z отвел особую роль-там подгружаются и записи со стены и фотографии для бокса, плейлисты, фотоальбомы и т.д. В общем параметр ответственный за аякс подгрузку что ли. и у плейлистов своей неаяксовой ссылки не существует. Бардак, который меня опечалил. Да, все эти три сервиса появились не сразу, а постепенно и скорее всего их даже делали разные люди.
Особняком стоит баг-трекер у ВКонтакте. Имеет отдельную ссылку вида https://vk.com/bugs.
Для отдельного бага https://vk.com/bugM. Помимо этого данный сервис имеет свой список пользователей(отдельный от списка всех зарегистрированных на вк), список продуктов(помимо вк) для которых заводятся баги. Подсервисы так сказать. И вот тут мне просто понравилось как они все оформили, без бардака, путаницы и прочего.
Для всех продуктов https://vk.com/bugs?act=products, а вывести баги для одного продукта - https://vk.com/bugs?act=product&id=263. Для участников https://vk.com/bugs?act=reporters, а информацию об отдельном участнике https://vk.com/bugs?act=reporter&id=M. То есть не стали делать ссылки вида https://vk.com/reporters и https://vk.com/products, а нагрузили гет параметр act. Мне пришлось такое по душе.
Для интереса выбрала все параметры(гет и пост) для сервиса баг-трекера их оказалось 39. А для act оказалось 119 различных не числовых значений. А всего у данного сервиса может быть 486 различных адресов(гет+пост). Всего же для вк мне удалось собрать 1109 не числовых значений для act, 500+ различных гет, пост параметров. Плюс особый параметр __query который отвечает за fullajax для сайта вк. Это и есть тот самый гет параметр z добавляющийся в строку.
Мысль о создании fullajax сервиса со столькими параметрами и значениями для них с единой точкой входа как то отпала. Ибо как сделать через реврайты https://site.ru/module567890?album=45 если без чпу ссылка имеет вид https://site.ru/index.php?content=module&us...890&album_id=45 это похоже на джумлу уже.
А вот сделать для модуля свой отдельный файл, свое имя и грамотно выделить параметры под подмодули мне кажется более рационально.
Возвращаясь к моей проблеме все будет как то так:

• https://site.ru/photo.php?act=albums фотоальбомы
• https://site.ru/photo.php?act=album&album_id=12&owner_id=1 фото с альбома
• https://site.ru/audio.php?act=playlists плейлисты
• https://site.ru/audio.php?act=playlist&playlist_id=12&owner_id=1 аудио с плейлиста
• https://site.ru/video.php?act=playlists плейлисты видео
• https://site.ru/video.php?act=playlist&playlist_id=12&owner_id=1 видео с плейлиста

Кто что думает?