Как правильно оформлять файл? Сначала писать в файле html-код а потом php - код или наоборот? Как считается правильно и более читабельно? Почему спрашиваю - однажды получил замечание на эту тему. но успел забыть как правильно.
Ну если не используется шаблонизатор а-ля smarty, то среди HTML всё равно будет php. Но лучше, чтоб этот php отвечал только за вывод информации, а не лез в базу, не делал какие-то расчеты и т.п. Вот это всё должно быть до, или даже в другом файле
Потому что подготовкой и обработкой данных занимается контроллер, а выводом - вью. Даже если то и другое на php, все равно контроллер это контроллер, а вью это вью. Если у тебя во вью идут выборки из бд и обработка.ю это хреново. Даже если архитектура такова, что только на стадии генерации нужно выбрать какие-то данные, то пусть это будет дергание методов контроллера, инкапсулированная логика, а не чистая. Сам себе спасибо скажешь, когда будешь поддерживать такую систему. Она легко управляется, расширяется, сопровождается.
Из прочитанного я понимаю что делаю не правильно , например - у меня файл login.php в нём форма для логина-пароля и там же обрабатывается авторизация и перекидывает в файл index.php . из написанного я понял необходимо три файла - форма, обработчик и страница куда перенапрялется при входе. --- Добавлено --- можно краткое определение что такое контрлер, и что такое вью? Спасибо.
Это два из трех мифических китов, держащих на своей спине мироздание. Слышал же про MVC? Model View Controller. Хотя, как по мне, MCV правильнее было бы. Model, она же "модель" - слой представления данных, модель данных. БД это модель, файлик, в котором ты что-то хранишь это модель, мемкеш это тоже модель. Данные в чистом своем виде. Controller, он же "контроллер" - это слой управления приложением. Тут у нас бизнес логика. View, оно же "представление", оно же "вью" - это слой отображения данных. И вот по-хорошему, по канону, модель должна отвечать только за хранение данных. Контроллер за работу с ними. А вью за представление. Если у тебя вьюха лезет в модель, это значит, что она берет на себя функции контроллера. Если при этом в системе уже есть контроллер, это порождает ад сопровождения такого кода. Возможен случай, когда границы между моделью, контроллером и вьюхой размыты, да. Например, контроллера как такового нет, но в каждой вьюхе есть набор методов, берущий на себя его роль. Это допустимо, но размывает слой управления по нескольким, часто независимым модулям. Хорошо это или плохо - зависит от архитектуры приложения. Но, опять же, в таком случае подготавливать данные будет один метод, а собирать ответ сервера - другой. А бывает, когда делают по принципу "и так сойдет", и когда посреди HTML-кода появляются PHP-вставки, в которых идет непосредственное обращение к модели, обработка, и тут же вывод. И так по нескольку раз в разных местах. ДА, БИТРИКС? Это очень плохо и так лучше не делать никогда.
Надо же. Не, я стараюсь в слой модели и всю бизнес-логику запихать. Для меня идеальный метод контроллера создаёт модель (1 строчка), кидает в неё данные (2 строчка), передаёт это в просмотр то, что модель вернула - 3 строчка. Другое дело, что не всегда так получается, но в общем и целом я стремлюсь к такому коду.
Ну вот по этому вокруг MVC стоит вечный холивар Кто-то пытается все делить, у кого-то размыты границы контроллера и вьюхи, у кого-то, как у тебя, модели и контроллера. Но фраза "запихать в слой модели бизнес-логику" личной мной слышится как "запихать в mysql на хранимые процедуры как можно больше". Потому как в моем понимании за хранилищем данных и его API модель заканчивается. Дальше есть только данные, полученные от модели, которые поехали в контроллер, а там уж как получится. Но так или иначе, главное не то, кто как понимает терминологию, а парадигма - мухи отдельно, котлеты отдельно. Код должен иметь логическое и, главное, логичное разделение. А остальное - по вкусу.
Ну да, поэтому в Laravel нет папки Models, как они пишут - поскольку все это понимают по-разному. Вот сейчас мне пришлось принять на разработку проект на Code Igniter, его модели я вообще не понял, что это, (это такие бесполезные классы, которые только делают sql-запросы), поэтому перенёс всё на слой под названием "бизнес-логика", и там вся, относительно сложная, фигня с данными и происходит. Контроллеры правда в этом проекте мне пока не нравятся, но я потихоньку рефакторю. Там они работают с похожими сущностями, но немного поразному, и на ранних этапах (поскольку задачи мне ставят по одной, маленькие) мне не было понятно, что будет общего, в чём будет разница, поэтому контроллеры - копипастой большей частью. Но, думаю, когда это всё будет подходить к концу, я разгребу это (вернее, уже начал). Есть правда ещё всякая работа с входными данными, повторяющаяся, и громоздкая (с $_POST и $_FILES), которую я вынес в слой, который обозвал "вспомогательные классы".
Из того что я понял - модель это база данных , её архитектура, контролеры это php который обрабатывает базу данных и бизнес логику а вью это то что я вижу в браузере - html , js и прочие инструменты.. И основная мысль - не стоит это смешивать и размывать границы. и вставлять в html куски php - это зло! но сразу вопрос . как я могу в выпадающий список (html) вставить данные из базы не используя php ? <select> ...<?php .... ?></select> Данную тему которую мы обсуждем как можно класифицировать? - проектирование программы ? или как то ещё? я хочу литературу почитать на эту тему. думаю в мануале я на эту тему не найду информации.
Не совсем так. Модель - часть программы, работающая с данными. Не только база данных. Контроллер - часть программы, обрабатывающего пришедшие от пользователя запросы. Просмотр - часть программы, формирующая вывод. В любой из этих частей может быть в нашем случае php, тут вопрос - чем этот php занимается. Т.е. в просмотре нормален код php, который выводит значения, записанные в массив, ради бога. Но вот код, который лезет за каким-то чёртом в базу данных там неуместен. Или который, к примеру, выполняет редиректы.
Уже понятнее. Правильно ли я понял - модель это база данных и запросы к ней ("SELECT user FROM t1..") . то есть все запросы на каждый конкретный случай надо писать в отдельный фаил? селект в одном файле а вывод в браузер значений в другом, грубо говоря? С чем это связано? это функции защиты или таким образом закладывается расширяемость проекта? --- Добавлено --- где почитать на эту тему? я тут Стива Маконела хочу начать читать , там есть про это? или мне надо что то попроще почитать?
Ды как ж ты умудряешься по-своему переосмысливать и понимать то, что вот было прям сказано ну яснее некуда? Перечитай, что было ранее написано.
Это плохо. Учись воспринимать, когда по-русски пишут. Очень бесят люди здесь, которым всё решение их проблемы распишешь, весь прямо алгоритм, а они код клянчить продолжают.
Тут не чувствовать надо. Тут либо понял, либо не понял. Не понял? Перечитай заново. Разберись, что именно не понял. Погугли. Перечитай еще раз и так, пока не поймешь однозначно и точно.
Всё же просто. Возьмём, к примеру, регистрацию пользователей. Что она из себя представляет? Пользователь идёт на страницу регистрации Сайт выводит формочку для ввода имени, пароля и прочих данных Пользователь заполняет формочку, отправляет её на сервер Эта формочка проверяется на правильность заполнения Данные заносятся в базу Пользователю выводят сообщения об успешной регистрации или ошибках Надеюсь, сразу понятно, что шаги 1 и 6 - это просмотр? Но чтоб выбрать какой просмотр выводить, надо обработать как-то запрос пользователя - это слой контроллера. Даже если нету роутинга, и обрабатываются фалы типа regForm.php, regSuccess.php - их тоже можно по выполняемой задаче отнести к контроллеру. В шаге 3 - данные принимаются тоже контроллером. А вот шаг 5 - кандидат в модель, естественно. Даже если предположить, что не используются классы, можно вынести функции в файл userModel.php, типа PHP: function getUser($user_id) { /* ... */ } function storeUser($user_id, $userData) { /* ... */ } function addUser($userData) { /* ... */ } Вот куда ставить шаг 4 - это предмет разных подходов и споров. Кто-то говорит, что в контроллер, кто-то - в ещё один слой, называемый "сервисным", кто-то считает, что в модель.