Комментарии 55
function page_add(){
function widgetAdd(){
вы уже определитесь со стилем написания
Это явное не best practice для новичков, а скорее наоборот.
(омг, нет, только не опять)
В архитектуре MVC важно, что компоненты ничего не знают друг о друге, а потому – независимы.
То есть контроллер ничего не знает ни о модели, ни о представлении, а представлении — ничего не знает о модели? Хм… а кто же знает, какое представление показать?
Каждый контроллер унаследует базовый, в котором реализуем функцию выводящую представление
… а говорите — контроллер ничего не знает о представлении. Как минимум, знает имя.
В нём, и каждом другом контроллере создаём ссылку, на его модель.
… и про модель контроллер знает.
Я предлагаю в качестве архитектуры простого приложения использовать:
А почему вы в качестве архитектуры показываете структуру файлов?
r::gЭээ, что?
Статья ориентирована на новичков, т.е. ничего нового в ней нет, просто несколько идей собраны в рабочий проект, решающий большинство задач.
"Рабочий проект" с обращениями в БД без параметров? Спасибо, нет.
В приложении используется реестр — реализация паттерна singleton – одиночка, хранящий все инстансы ( инициализированные объекты классов ) всех моделей и контроллеров.
Реестр и синглтон — это два разных паттерна. Вам, кстати, никогда не говорили, что синглтон — это антипаттерн? Ну и почему у вас модели — это синглтоны?
Ещё в базовом контролере реализуем реестр для хранения заголовка страницы, с возможностью изменить его из любого контролера.
Но зачем?
//Сохранение исходного вида запроса к приложению private static $request = null;
Я так понимаю, никакой многопоточности быть не может?
В общем, как обычно — зачем? Зачем писать свой велосипед очередной раз? Нет MVC-фреймворков?
Вам, кстати, никогда не говорили, что синглтон — это антипаттерн?
Поцчему? :)
Я так понимаю, никакой многопоточности быть не может?
Покажите мне сайты с многопоточностью :)
Нет MVC-фреймворков?
Они унылы. :)
А фреймворк может быть не MVC? :)
Поцчему?
Потому что (а) это разделенное состояние и (б) это статическая зависимость.
Покажите мне сайты с многопоточностью
Любой сайт, на котором больше одного одновременного посетителя.
А фреймворк может быть не MVC?
Легко.
Любой сайт, на котором больше одного одновременного посетителя.
Они запускают несколько процессов и реактивно процессят запросы с асинхронным io. Общий стейт кладут в memcached. Нету там многопоточности на уровне «прикладного» кода.
Они запускают несколько процессов и реактивно процессят запросы с асинхронным io. Общий стейт кладут в memcached.
Ты вот прямо за все сайты в интернете готов сказать?
(Другое дело, что я тоже не вполне прав, и не на любом сайте есть многопоточность, где-то есть многопроцессность, и поэтому нет конкурентности, это да. Но, как мы оба знаем, многопоточные сайты тоже вполне себе существуют.)
Потому что (а) это разделенное состояние и (б) это статическая зависимость.
а.1) возможно необходимое именно статичное состояние
а.2) есть вариант с пулом одиночек
б.1) чем плоха статика?
б.2) статика есть и на фреймворках, была где-то статистическая информация о ее проценте в них
Любой сайт, на котором больше одного одновременного посетителя.
Шта?
Это любой сайт автоматом становится многопоточным? :)
Хотя ниже Вы все же признали, что были не правы и примеры сайтов с многопоточностью привести не смогли :)
Легко.
Например?
П.С.
У минусующего быдла такие же аргументы?
возможно необходимое именно статичное состояние
Ну так и антипаттерны иногда нужны. Просто надо осознавать, что это антипаттерны.
чем плоха статика?
Невозможностью подмены.
статика есть и на фреймворках, была где-то статистическая информация о ее проценте в них
Ну, это личное дело каждого фреймворка.
Шта? Это любой сайт автоматом становится многопоточным?
Я уже уточнил ниже. Формально, не любой. Но вот любой сайт на asp.net — многопоточен.
Например?
asp.net webforms, asp.net webapi.
Но вот любой сайт на asp.net — многопоточен.
Для зануд: на asp.net под IIS. За другие хосты не отвечаю.
Невозможностью подмены.
Не факт. В Laravel, например, есть такая штука как "фасады", которые являются прокси на объект контейнера, получаемые через сервислокацию. А это значит что подмена более чем практикуема при условии сохранении интерфейса элемента контейнера.
Например?
Любой билд TS php многопоточный и требуется для работы вместе с Apache в режиме mod_apache (как модуль). В противоположность оному существуют NTS билды, которые используются в nginx и iis, например в cgi, fcgi (fpm) режимах. В этом случае fpm процесс спамит процесс под запрос (или всё же процесс + несколько тредов на процесс? Я не уверен).
Так что пример — 80% сайтов и ынтернетах.
В Laravel, например, есть такая штука как "фасады", которые являются прокси на объект контейнера, получаемые через сервислокацию.
Ключевое слово: сервис-локатор. Сервис, полученный через сервис-локатор — это не синглтон, даже если внутри сервис-локатора хранится ровно один экземпляр сервиса.
(я могу тут порассуждать еще почему сервис-локатор — это тоже антипаттерн, но не буду)
Ключевое слово: сервис-локатор. Сервис, полученный через сервис-локатор — это не синглтон, даже если внутри сервис-локатора хранится ровно один экземпляр сервиса.
Ну так доступ же к нему полностью статический и глобальный (привет синглтоны), магия и всякая хурма.
P.S. Оффтоп: Антипаттерн, никто не спорит. Но, признаться, я не вспомню случаев когда он мне мешался или становился камнем преткновения на практике.
Ну так доступ же к нему полностью статический и глобальный (привет синглтоны), магия и всякая хурма.
Доступ к сервис-локатору, да. Который обычно синглтон и так далее, см. выше. Но сервис, полученный из сервис-локатора — не синглтон. Это такие вот мелочи, которые сильно меняют поведение системы.
признаться, я не вспомню случаев когда он мне мешался или становился камнем преткновения на практике.
А мне регулярно приходится разрывать зависимости-через-синглтон потому что или с видимостью проблемы, или протестировать не удается, или не кастомизируется в достаточной мере.
А мне регулярно приходится разрывать зависимости-через-синглтон потому что или с видимостью проблемы, или протестировать не удается, или не кастомизируется в достаточной мере.
Я про сервис-локацию, а не синглтон. Синглтоны — это вообще открытое зло, единственное место, где он действительно необходим — это контейнер приложения, имхо.
… а с сервис-локацией я как встретил один раз ситуацию, когда результат тестов зависел от порядка их выполнения (а параллельно они вообще отказывались работать) — так и стал ее избегать.
Но это не проблема сервис-локации же? Это проблема, подозреваю, рантайма контейнера, когда он билдится и фризится и после этого подмена элемента контейнера проблематична.
Просто надо осознавать, что это антипаттерны.
Вообще осознавать нужно всегда, что делаешь :)
Невозможностью подмены.
Придется смириться :)
Ну или подсовывать другую обертку, которая использует другую статику. :)
Ну, это личное дело каждого фреймворка.
Но на автора все набросились и поставили в пример фреймворки…
Но вот любой сайт на asp.net — многопоточен.
Это как-то относиться к PHP? :)
asp.net webforms, asp.net webapi.
Там вывод шаблона и логика в одном файле? :)
Придется смириться
Ну и зачем, если есть паттерны, которые позволяют без этого обойтись.
Но на автора все набросились и поставили в пример фреймворки…
Никто не идеален. Это не отменяет того, что когда пишешь сам, ошибок надо избегать.
Это как-то относиться к PHP?
Нет. Зато относится к сайтам. Вы же не просили показать вам сайты на PHP с многопоточностью.
Там вывод шаблона и логика в одном файле?
Нет.
Ну и зачем, если есть паттерны, которые позволяют без этого обойтись.
Например?
Что мне даст ленивую инициализацию и один и тот же экземпляр?
Кстати, если приложение одно, то можно поручить хранить экземпляры ему. :)
Нет. Зато относится к сайтам. Вы же не просили показать вам сайты на PHP с многопоточностью.
Включайте мозг.
Нет.
Ну, поздравляю. Они изобрели MVC. (Да и Вы опять вспоминаете ASP в ветке PHP :))
А то, что его нет в названии — плевать.
Это для лохов придумали asp.net mvc. :)
Что мне даст ленивую инициализацию и один и тот же экземпляр?
Dependency Injection.
Ну, поздравляю. Они изобрели MVC. [...] А то, что его нет в названии — плевать.
Но нет. Во-первых, не всякое Separated Presentation — MVC. Во-вторых, в вебформзах даже separated presentation будет только если его тщательно написать руками, а обычно там лапша. А в-третьих, asp.net webapi — вообще не UI-фреймворк.
(в-четвертых, MVC старше всего asp.net вместе взятого, если не asp вообще, так что говорить, что они изобрели MVC — это смешно, конечно)
Это для лохов придумали asp.net mvc
Вы, судя по вопросам, немножко не знаете разницы между asp.net webforms и asp.net mvc, так что я бы, на вашем месте, воздержался...
Dependency Injection.Да, норм. :)
Это примерно то:
Кстати, если приложение одно, то можно поручить хранить экземпляры ему. :)
Во-первых, не всякое Separated Presentation — MVC.Это все условности.
Главное сам принцип разделения.
говорить, что они изобрели MVC — это смешно, конечноЭто типа выражение: «Поздравляю, ты изобрел велосипед (колесо) :)»
Вы, судя по вопросам, немножко не знаете разницы между asp.net webforms и asp.net mvcНе знаю.
Поэтому не пишите в теме PHP информацию, подразумевая ASP, но не указывая этого явно. :)
П.С.
Пока ожидал возможности отправить свой ответ, написал свою реализацию DIC. :)
Проверил хабр, нашел статью https://habrahabr.ru/post/183658/
Написал примерно то же. :)
П.П.С.
А как хабровчане относятся к хранению экземпляров в статической переменной (не статическом члене класса):
function injected($pid = 0)
{
static $instances = array();
if(array_key_exists($pid, $instances))
{
$instance = $instances[$pid];
}
else
{
$instance = $this->get('injected');
$instances[$pid] = $instance;
}
return $instance;
}
Главное сам принцип разделения.
Сам принцип разделения называется Separated Presentation. MVC называется конкретная реализация.
Поэтому не пишите в теме PHP информацию, подразумевая ASP, но не указывая этого явно
Я как-нибудь разберусь, что мне писать, спасибо.
MVC называется конкретная реализация.
Хм, у этой реализации у самой 100500 реализаций :)
Просто, говоря MVC, обычно и понимается Separated Presentation, кмк.
Я как-нибудь разберусь, что мне писать, спасибо.
Сорри.
В первоначальном варианте было с «пожалуйста». :)
Но браузер покрашился и коммент удалось не полностью воссоздать :)
Просто Вы внесли непонятки упоминанием фич ASP в контексте PHP без упоминания самого ASP. :)
Просто, говоря MVC, обычно и понимается Separated Presentation, кмк.
Вам кажется. Это понимание как минимум неточно, как максимум — безграмотно.
И ещё, дабы защитить свой проект от доступа к скриптам, в папки controller, model и. view надо положить .htacess с содержанием: Deny from all
Нет для этого Выделите паблик директорию, которая будет рутовой для вебсервера и что бы все файлы (внутренний код приложения) лежали выше нее. Это единственный нормальный вариант.
Вообще всё очень спорно и не понятно зачем оно на хабре.
Реврайты в .htaccess?! А если у меня nginx+fpm (вернее не если а только так). А если мне нужна иная структура например resources/{resource}/subresources. А еще разная обработка для get И post. Ну есть же концепция роутинга и без нее никуда.
Это понятно. Просто хотелось указать человеку на какие то конкретные вещи. Хоть на пару моментов.
К слову, автор, вот тут для фана ну и в обучающих целях писалось(так и не дописалось) так вот там буквально в нескольких функциях сделано то, что и у тебя но в разы гибче.
«вот это»(то что в статье) я бы не советовал, кмк.
Огромную роль в современном php комьюнити играет PSR и composer. Я очень советую воспользоваться ими. Хотя бы PSR-2 и PSR-4
Используя данный шаблон, вы сможете реализовать большинство задач, для веб приложений. И главное, любой другой программист, знакомый с MVC, сможет легко разобраться в вашем проекте.
Огонь! Невероятно! Но есть одна загвоздка… Вы в своей статье описали почти что классический MVP
1) стандарты и рекомендации — нет не слышал! — php-fig.org
2) роутинг прибит намертво через .htaccess — за это я готов руки оторвать
3) автолоад — что это?
4) переменные и даже классы из одной буквы — замечательно!
5) кастомный шаблонизатор — вообще мечта!
6) mysqli — хорошо хоть не mysql
7) конфиги бд через define — ня!
Для начинающего в 2005-2009 году который изучает php две недели — это проект еще нормален, но для статьи на хабре в 2017 году — это перебор.
Подобные статьи появляются на хабре минимум раз в квартал, странный троллинг...
Хоть какая-то структура, логика, фронт-контроллер базовый (index.php) и роутинг уровня кодеигнайтера
Хоть заюзал вполне адекватную либу для базы данных, хоть и написал сначало свой велосипед.
Ну хоть уровень выше чем уроки Попова :) Мелкие студии в начале 2000-х и хуже творили.
При этом я считаю свой ACL для laravel 5.2 убогим недоработанным костылесипедом, только потому что работает через middleware a не через guard который появился в 5.3 и пока не допилю его в своем приватном gitlab — публично его мне совесть не позволит выложить, хотя он уже используется в довольно крупном проекте в течении года и вполне себе работоспособен.
И тут я вижу от взрослого и вроде адекватного, владеющим английским человека статью на хабре про «ЭТО»
Как говорил мой бывший коллега-питонст, который улетел на работу в чехию:
Какая криворукая тварь это написала!
У меня не просто бомбит на этот код, меня полностью и окончательно разорвало!
Я джва года ждал такой пост.
Своё WEB-приложение, с MVC и реестром