Форум PHP

Данный вопрос был поднят на другом форуме, но т.к. я не нашёл там помощи, то решил обратиться сюда :)

Начал интересоваться MVC. Написал небольшой скрипт гостевой. Я понимаю, что скрипт гостевой - это не совсем правильный выбор для изучения MVC, но в данном случае, он представляется как часть(модуль) скрипта CMS. В скрипте нет защиты, т.к. в данном случае, я лишь просто пытаюсь понять как построить приложение, а не как его защитить.

Можете сказать, правильно ли я построил архитектуру приложения? Если нет, то указать на ошибки и т.п.

Архитектура приложений чем хороша, не обязательно даже код видеть (тем более вы его и не приводите). Расскажите, как вам видится архитектура вашего приложения с учетом MVC, а так же какую выгоду вы хотите извлечь, применяя этот паттерн? С радостью поправим, предложим, расширим и углубим :)))

Ой, совсем забыл прикрепить архив со скриптом. Исправляюсь)

Просишь рассказать словами, а не выкладывать, тут же выкладываете :))) Надо в следующий раз будет попросить выложить :))), чтобы вы наоборот рассказали о своем видении.

Ну я подумал, что код лучше расскажет)

Чем метод showMess() модели, отличается от showMess() контроллера? И зачем в модели такой метод, она же ничего не показывает? Она только предоставляет данные, причем модель "не знает" зачем эти данные могут потребоваться, может для отображения, может для печати, может для сохранения в файл, может для статического анализа... не совсем удачное имя для метода, который совершенно не должен соваться в задачи представления... это даже для контроллера не совсем удачное имя. Поймите, что когда вы создаете объектно-ориентированную программу, вы создаете язык, если язык будет неудачным, программы на них хороших не напишите, вы не будете понимать язык, вы будет совершать ошибки (ошибку совершить в ООП-программе тоже очень легко, только интерпретатор вам уже не скажет, что у вас тут архитектурная ошибка).

"Чем метод showMess() модели, отличается от showMess() контроллера?", в модели этот метод только предоставляет информацию для вывода, а в контроллере одноимённым методом определяется показывать сообщения или нет.
"И зачем в модели такой метод, она же ничего не показывает? Она только предоставляет данные, ..", если честно, то я думал, что модель должна только предоставлять данные и не более. А контроллер и модель уже сами решат, что с этими данными делать.
"не совсем удачное имя для метода", да.. с придумыванием названий у меня всегда были проблемы.

Поэтому в ООП нужно сначала чертить схемы, придумывать названия и лишь затем кодировать - иначе, когда таких классов будет 30-40, попросту свихнетесь среди десятка методов у десятка же классов, которые все называются showMess(), но делают совершенно разные вещи. Представьте в PHP было бы несколько классов с методом showMess(), которые бы и данные из файла читали, и в базу данных бы запросы отправляли, и HTTP-запросы бы формировали... исторически бы так сложилось: писали гостевую книгу, а получился язык программирования (собственно PHP пример плохой, вернее хороший для того, чтобы показать как не следует языки проектировать)... Если вы создаете абстрактную модель, для налаживания архитектуры, то спроектируйте её так, чтобы была удобно не только для гостевой книги. Представьте, что вам при помощи этих классов нужно будет создать и каталог товаров, и интернет магазин с кабинетами пользователей, и форум, где эти пользователи будут общаться, и внутреннюю переписку и систему администрирования всех этих блоков и он-лайн игру и вообще любое приложение, которое вы видите в Интернет. Вот исходя из этого и называйте методы.

PS Есть удобное слово называется "entity", которое переводят как "сущность", "нечто", вы наверное уже заметили, что у программистов, интенсивно использующих ООП, это слово самое любимое :))) Когда поймете почему, считайте, что половину ООП знаете :))) class, privat, public и прочие ключевые слова - это просто ключевые слова, ООП он не в инструментах, он в организации кода. Win32 изначально был написан на С, который вообще объектно-ориентированных инструментов не поддерживает, тем не менее эта разработка считается классической объектно-ориентированной программой (с классами и объектами, хотя на уровне ключевых слов их нет). Верно и обратное, можно используя весь набор ключевых слов, применяющихся объектно-ориентированных программ, построить совершенно не объекто-ориентированную программу, даже если она внешне будет её напоиминать.

Ну с названиями я понял) Имя метода изменил. Что ещё можете посоветовать?)

Ну начало положено... понятно, что внутри классов можно улучшать и улучшать, так как они пока не охватывают слишком большой интерфейс, но это и хорошо. Не нужно сразу в классе реализовывать поддержку всего SQL, классы как раз и ценят на то, что у них интерфейс не перегружен и они выполняют именно то, что нужно... Другое дело, что у вас SQL-запросы и в контроллере и в модели - в чем их смысл тогда? Идея в том, чтобы модель инкапсулировала данные и уровень базы данных, чтобы контроллер вообще не знал, откуда данные поступают из файла, из базы данных и комического разума... он бы просто обращался к методам модели, как для извлечения данных, так и для их добавления. А у вас контроллер напрямую помещает данные в базу данных при помощи SQL-запроса, поменяется таблица, вам придется и контроллер и модель править... ну и смысл в их раздельном существовании? Если изменение модели приводит к необходимости исправлять контроллер? Строже к себе нужно относиться, когда за ООП беретесь, думайте не о себе а том, что у вас в руках только интерфейс, разработали модель и создавайте контроллер вообще не обращаясь к базе данных... не получается? Значит плохо с моделью поработали, думайте над ней снова. Работаете над видом, делайте так, чтобы он модели вообще не касался... не получается? Значит плохо с контроллером поработали, думайте над ним снова. По началу 10-20 можно делать, будет медленно и не эффективно - это нормально, ООП не для ускорения создавался, а для того, чтобы у вас была возможность строить вот такие секции, как в подводной лодке.

"так и для их добавления.", аа а я то думал, что модель только предоставляет данные) ну тогда всё понятно)) Спасибо) Исправлю)
А что можете подсказать насчёт самой структуры файлов, каталогов и навигации? К примеру, это нормально, что у меня в файле /index.php подключается всё? Смотрел исходники некоторых MVC-проектов, там максимум подключали 1-2 файла. А ведь этот скрипт, это всего лишь "тренировочный" пример. При таком подключении, в больших скриптах мне придётся подключать гораздо больше файлов, что на качестве кода отразится не в лучшую сторону, и на производительности наверняка тоже.
А с навигацией, как мне кажется, у меня полный бардак))

>там максимум подключали 1-2 файла.
Просто эти 1-2 файла подключают все остальные файлы, со временем тоже к этому придете, когда утомитесь новый файл в кучу других добавлять. Или если хотите заранее можете этим озаботиться.

>А с навигацией, как мне кажется, у меня полный бардак))
Лиха беда начало. Если ничего не делать вообще, а ждать просветления, дело вообще не движется. Разрабатывайте новые версии, улучшайте.

Спасибо за советы! :) Пошёл пробовать.

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

".. а так же какую выгоду вы хотите извлечь, применяя этот паттерн?", хочу улучшить свой код. К тому же, сейчас многие веб-приложения, а так же фреймворки используют подобный паттерн, так что я подумал, если не буду это изучать, то самому только сложнее будет.

>".. а так же какую выгоду вы хотите извлечь, применяя этот паттерн?", хочу улучшить свой код.
В какую сторону улучшить? Код может быть читабельным, эффективным, более удобен для повторного использования и зачастую эти характеристики взаимоисключающие. ООП же бъет сразу по нескольким из них, т.е. сначала вы резко ухудшаете свой код сразу по нескольким направлениям и если у вас нет четкого плана, как воспользоваться преимуществами ООП, что точно вы улучшите, когда и на сколько, вы просто ухудшаете свой код (а до преимуществ дело может не дойти).

>К тому же, сейчас многие веб-приложения, а так же фреймворки используют подобный паттерн,
>так что я подумал, если не буду это изучать, то самому только сложнее будет.
Только нужно четко понимать зачем. Основное предназначение, чтобы модель (базу данных), котроллер (PHP-код) и представление (HTML, CSS и обслуживающий код) можно было разрабатывать и использовать независимо. Т.е. вынимаете из проекта каждую из этих частей и вставляете в другой, при этом они почти не зависимы друг от друга и не тащат за собой пол сайта. Вот если вам это удалось и разработка новых блоков будет проходить теперь проще, так как вам не придется создавать скажем код контроллера по-новой (достаточно будет заменить модель) или смена дизайн будет сводится только к работе с представлением, поздравляю, вы освоили MVC.