Беда в том, что программист может застрять на первом уровне и иметь культ карго. :)
Ибо никакого обучения и осмысления нету. Обычное кодирование, как макака. :)
На предложение подумать своей головой, в ответ агрессия. :)
Процитирую:
До того, как вы начнете на практике применять паттерны ООП, и не поймете их минусы и плюсы, я советую не читать книг по паттернам, и не использовать фреймворки, иначе случится паттерн головного мозга, и паттерны будут применяться не по назначению, а просто потому, что вы их знаете, вы будете лепить их к месту и не к месту.
Вам не кажется, что те, кто начинал на голом языке, имеют больший профессионализм?
если у вас кучу компонентов связывает одна шина, вы получаете систему с высокой связанностью.
А на фреймворках компоненты как взаимодействуют друг с другом? :)
Service Container — это та самая единая шина. :)
У меня единая шина событий.
А компоненты одного пространства имен свободно вызывают зависимости, но их не много.
Фреймворки нужны всем.
Тогда так:
«Мейстримовые фреймворки не всем нужны» :)
Клей, мосты между компонентами, адаптеры, загрузка конфигураций и базовая структура. Это не много кода обычно.
Так я и говорю, что это не много. :)
Это можно и самому реализовать, как нужно. :)
И в итоге люди исповедующие нормальные подходы остаются в меньшинстве. А поскольку они в меньшинстве то все надеятся на мудрость толпы и т.д.
Если вы дадите разработчику голый PHP выйдет скорее всего хуже. Ну то есть тут проблема не в том что люди не умеют пользоваться фреймворками, а в целом не умеют или не хотят думать что они делают.
Выходит парадокс :)
Для того, чтобы нормально пользоваться фреймворком, нужно быть хорошим программистом.
Но хороший программист может обойтись и без фреймворка.
А плохие программисты не могут нормально пользоваться фреймворком.
Но без фреймворка будет еще хуже. :)
ЦА фреймворков — плохие программисты? :)
Культ карго, эффект Даннинга-Крюгера и т.п.
А, ну это да. Странно только, что он так сильно распространен среди программистов или «программистов» :)
Они просто переименовали вещи и отгородились от общей концепции.
Ерунда какая-то :)
Как правило они состоят из набора готовых самодостаточных компонентов. Обычно есть стандартная сборка этих компонентов которая и именуется фреймворком.
1. Только не все умеют эту сборку готовить :)
2. А что должно быть во фреймворке, если выбросить все компоненты?
И это обычно означает что есть не пачка модулей независимых а каша в которой просто очень хорошо ориентируется ее автор.
Хм, но общение может быть организовано посредством какой-то шины :)
Очень часто когда люди кричат «фреймворки не нужны»
Правильней «фреймворки не всем нужны» :)
Но многие начинают впадать в крайности
Об этом и речь, что не нужно впадаться в крайности. :)
Что еще скажу: если человек понимает, что он делает, и знает где что лежит, то плевать, что кто-то считает, что он делает неправильно. :)
Хотя в крайности тут тоже впадать не нужно.
Я вот раньше писал плохо отформатированный код :) Но мне он был понятен :) А сейчас самому противно смотреть на такой код. :)
Неужели в мире вэба свет окончательно сошелся на фреймворках
Не везде, но фреймворки доминируют.
Разработчики то ли обленились, то ли отупели, то ли тупыми и были, то ли не хотят брать на себя ответственность. :) Бла-бла-бла.
Много свежей крови, которая кроме фреймворков ничего не умеет.
Поколение программистов, не умеющих программировать на языке, на котором написан фреймворк :)
а в воркфлоу фреймворка как заинжектить динамику не знают, привыкли к «магии»
В вебе контроллер практически всегда вызывает рендеринг вида явно (я не говорю, что это правильно). :)
А вот вид практически никогда не лезет в модель сам.
Но обычно, под MVC все таки подразумевают вариант с Активной Моделью.
Хм, а в вебе обычно пассивные модели. :) Страничка отдалась и все. Ничего в ней больше не меняется. :)
Независимость Модели является главным в MVC.
Независимость приветствуется везде… :)
Вся бизнес логика приложения, то есть большая часть кода, сосредотачивается в Контроллере и это при том что как раз Контроллер является самой зависимой частью в MVC – в общем случае он зависит и от Модели и от Вида.
Почему же?
Есть API — используйте его.
Хотите, поместите некоторую логику в модель — и так само используйте API.
Зависимости от M нету, так как M — пустая.
Как вообще может быть зависимость от V?
Отсюда и появился термин ТТУК — толстый тупой уродливый контроллер
Другой вариант — толстая тупая уродливая модель. :)
в Контроллер помимо всей бизнес-логики приложения помещается также еще и логика управления пользовательским интерфейсом
Что это вообще такое? :)
Дело в том, что в объектно-ориентированном приложении нет данных, а есть множество объектов и каждый из них содержит какие-то данные и методы работы с ними.
Прекращайте дрочить на ООП.
MVC возможно не только на ООП головного мозга.
Данных нету. Вокруг сферические объекты. Буквы — это тоже объекты.
Второй подход гораздо ближе к первоисточникам.
Та плевать, что было в первоисточниках.
Иногда появляются уникумы, которые говорят, что ООП — на самом деле это не то, что называют ООП сейчас, а обмен сообщениями.
Мартин Фаулер абсолютно прав, когда говорит что MVC это не паттерн
Та это вам все адекватные люди говорят. Но вы же кастрюли на голову оденете и как носороги упираетесь.
«1» Отделение модели предметной области (бизнес логики) приложения от пользовательского интерфейса
В называемом вами классическом это тоже есть.
«2» Независимость Модели и синхронизация пользовательских интерфейсов за счет шаблона Наблюдатель
К вебу имеет слабое отношение…
Очень часто (особенно когда дело касается простых виджетов) оно вообще не делается и используется «упрощенный MVC»
И выходит черти что. Каша из php и html.
То, что Модель реализует шаблон Наблюдатель явно указывает на то, что Модель это именно один объект.
В один класс пихать методы для работы с БД и бизнес-логику? Перемога.
И логика вывихнутая.
Использование наблюдателя никак не говорит, что один объект.
если внесем какие угодно изменения в бизнес логику приложения, но при этом оставим неизменным интерфейс-фасад, то ни Вид, ни Контроллер это никак не затронет.
Хм.
Предположим, что у нас нет фасада.
Глупо же было из-за изменения движка базы менять шаблоны? :)
Причем шлюз этот «вместо того чтобы обеспечивать общий единый для всех API, предоставляет различные API для каждого клиента
Это же так классно поддерживать несколько API :)
Автор подчеркивает, что Модели это не данные, а исключительно интерфейсы/объекты-посредники/фильтры
Вообще-то да.
обеспечивающие удобный доступ к данным, которые могут находится где угодно – на разных машинах, в разных форматах
Программисты на фреймворках понимают это так, что модели остаются ходилками в БД, поверх которых навешали мусора. :)
Типичные ошибки: копирование доменных данных в модели GUI-компонент
Хм.
Но если мы имеем дело с объектами, то они передаются по ссылке.
А как же как быть, когда нам нужны данные из 2 моделей?
А нагружать этой логикой V не хочется. Проще эти данные объединить в С.
Но в контексте шаблонов и схем Модель это прежде всего интерфейс и реализующий его объект-посредник (фасад, адаптер, прокси) обеспечивающие удобный и безопасный доступ к доменным данным, которые могут находится где угодно.
+100500
Но пропагандисты фреймворков ведут людей по быстрому пути :)
Поэтому, если есть те, кому интересно и «не надоело», то пишите и я выложу вторую часть полностью посвященную именно этой теме.
Конечно же, выкладывайте.
В общем первая часть статьи (первая часть того, что выложено, а не вся статья) — ничего нового. Такие самые заблуждение, как и везде, в частности и на хабре.
А вторая часть — грамотная.
MVC — это всего лишь разделение кода на уровни.
Разделять нужно с умом. А не делать так, как пишут идиоты в интернете.
Есть необходимость — вынесли что-то в отдельный класс, нету — не вынесли.
Дополню:
Если логика примитивная и нужна только одному контроллеру, то ее все же можно оставить и в контроллере.
Но не в виде ни под каким предлогом.
Что думают хабровчане? :)
Беда в том, что программист может застрять на первом уровне и иметь культ карго. :)
Ибо никакого обучения и осмысления нету. Обычное кодирование, как макака. :)
На предложение подумать своей головой, в ответ агрессия. :)
Процитирую:
Вам не кажется, что те, кто начинал на голом языке, имеют больший профессионализм?
А на фреймворках компоненты как взаимодействуют друг с другом? :)
Service Container — это та самая единая шина. :)
У меня единая шина событий.
А компоненты одного пространства имен свободно вызывают зависимости, но их не много.
Тогда так:
«Мейстримовые фреймворки не всем нужны» :)
Так я и говорю, что это не много. :)
Это можно и самому реализовать, как нужно. :)
Но большинство пишет на фреймворках… :)
Вон из профессии.
Плевать.
Когда будут использовать нормально, тогда и поговорим. :)
Прекращайте троллинг.
Выходит парадокс :)
Для того, чтобы нормально пользоваться фреймворком, нужно быть хорошим программистом.
Но хороший программист может обойтись и без фреймворка.
А плохие программисты не могут нормально пользоваться фреймворком.
Но без фреймворка будет еще хуже. :)
ЦА фреймворков — плохие программисты? :)
А, ну это да. Странно только, что он так сильно распространен среди программистов или «программистов» :)
Ерунда какая-то :)
1. Только не все умеют эту сборку готовить :)
2. А что должно быть во фреймворке, если выбросить все компоненты?
Хм, но общение может быть организовано посредством какой-то шины :)
Правильней «фреймворки не всем нужны» :)
Об этом и речь, что не нужно впадаться в крайности. :)
Что еще скажу: если человек понимает, что он делает, и знает где что лежит, то плевать, что кто-то считает, что он делает неправильно. :)
Хотя в крайности тут тоже впадать не нужно.
Я вот раньше писал плохо отформатированный код :) Но мне он был понятен :) А сейчас самому противно смотреть на такой код. :)
Карл, а где я такое говорил?.. :)
Согласен.
Вот только пользоваться фреймворками люди не умеют.
Вы же сами это говорили. :)
Да и MVC унылый на фреймворках, как показала статья и комменты. :)
Есть понятие unix-way.
Фреймворк — это швейцарский нож, которым никто не умеет пользоваться :)
Это разве нормально, что программист на фреймворке языка не знает языка и не умеет программировать? :)
Хотя да, разные программисты нужны. :)
Не везде, но фреймворки доминируют.
Разработчики то ли обленились, то ли отупели, то ли тупыми и были, то ли не хотят брать на себя ответственность. :) Бла-бла-бла.
Много свежей крови, которая кроме фреймворков ничего не умеет.
Поколение программистов, не умеющих программировать на языке, на котором написан фреймворк :)
Но фреймворки тоже толком не умеют. :)
Ну такое.
Давайте, вахтеры, минусуйте. :)
Да, без разницы на чем.
Только пропагандисты фреймворков предлагают быстрый путь вместо правильного. :)
Ну тогда в шаблонизаторе будете в базу лазить. :)
Это уже будет не совсем шаблонизатор. :)
Хотя я не против вызова из шаблона других виджетов / контроллеров / шаблонов.
Только это только вызов, без логики обработки данных.
Это ж другое.
Такая логика уместна в шаблоне. :)
+1
Тут преждевременная оптимизация не нужна. :)
Вы молодец. :)
Если бы все были такими, то и статьи не было бы. :)
Самое непосредственное.
Почти вся разработка сейчас или на фреймворках, или на CMS.
Та пишите.
Получите то, от чего начали:
Мешанина php и html. :)
Но спасибо хоть ответили, а не как некоторые :)
В вебе контроллер практически всегда вызывает рендеринг вида явно (я не говорю, что это правильно). :)
А вот вид практически никогда не лезет в модель сам.
Хм, а в вебе обычно пассивные модели. :) Страничка отдалась и все. Ничего в ней больше не меняется. :)
Независимость приветствуется везде… :)
Почему же?
Есть API — используйте его.
Хотите, поместите некоторую логику в модель — и так само используйте API.
Зависимости от M нету, так как M — пустая.
Как вообще может быть зависимость от V?
Другой вариант — толстая тупая уродливая модель. :)
Что это вообще такое? :)
Прекращайте дрочить на ООП.
MVC возможно не только на ООП головного мозга.
Данных нету. Вокруг сферические объекты. Буквы — это тоже объекты.
Та плевать, что было в первоисточниках.
Иногда появляются уникумы, которые говорят, что ООП — на самом деле это не то, что называют ООП сейчас, а обмен сообщениями.
Та это вам все адекватные люди говорят. Но вы же кастрюли на голову оденете и как носороги упираетесь.
В называемом вами классическом это тоже есть.
К вебу имеет слабое отношение…
И выходит черти что. Каша из php и html.
В один класс пихать методы для работы с БД и бизнес-логику? Перемога.
И логика вывихнутая.
Использование наблюдателя никак не говорит, что один объект.
Хм.
Предположим, что у нас нет фасада.
Глупо же было из-за изменения движка базы менять шаблоны? :)
Это же так классно поддерживать несколько API :)
Вообще-то да.
Программисты на фреймворках понимают это так, что модели остаются ходилками в БД, поверх которых навешали мусора. :)
Хм.
Но если мы имеем дело с объектами, то они передаются по ссылке.
А как же как быть, когда нам нужны данные из 2 моделей?
А нагружать этой логикой V не хочется. Проще эти данные объединить в С.
+100500
Но пропагандисты фреймворков ведут людей по быстрому пути :)
Конечно же, выкладывайте.
В общем первая часть статьи (первая часть того, что выложено, а не вся статья) — ничего нового. Такие самые заблуждение, как и везде, в частности и на хабре.
А вторая часть — грамотная.
MVC — это всего лишь разделение кода на уровни.
Разделять нужно с умом. А не делать так, как пишут идиоты в интернете.
Есть необходимость — вынесли что-то в отдельный класс, нету — не вынесли.
Дополню:
Если логика примитивная и нужна только одному контроллеру, то ее все же можно оставить и в контроллере.
Но не в виде ни под каким предлогом.
Это как?
Может V и M?
Только я сомневаюсь, что болезнь лечится :) Больные считают себя здоровыми.