> просто яп который является веб-приложнием и который является посредником.
нет, это просто web-приложение. Оно самодостаточное. То что оно юзает базу данных - вы можете не использовать ее, это деталь реализации, совершенно второстепенная штука.
Алексей Скляр: и не надо человеку сейчас грузиться тонсостями сетевых стэков и сетевого взаимодействия. Достаточно поднять встроенный в PHP сервачек и баловаться в свое удовольствие. Заодно человек не будет приучиваться к апачу с его htaccess.
Sanes: менеджеры которым заняться начем или руководители которым скучно? При таком менеджменте явно надо бежать без оглядки. Что до тренингов - они так же разные бывают. Те на которых я был обычно как раз таки несколько другие идеи преподносили.
nepster09: вы сейчас говорите о паттерне "абстрактная фабрика", который "создает объекты разных типов под входящие данные". Тут речь совсем о другом. Дискуссия окончена.
Sanes: ну это приятная бюрократия. Тут нет отчетности (всей отчетностью занимаются различные трекеры которые действуют прозрачно), только общение. А записывают больше для себя чем для других.
Sanes: а внутри команды бюрократии нет. Есть слаки, ишус трекеры. Достаточно просто все решения записывать в комментах к ишусам. Ну и опять же BDD, мокапы, прототипы.
BDD, мокапы, прототипы. Пока нет ГОСТовых ТЗ все это спокойно заменяет документацию по проекту. Ну и все договоренности по email хотя-бы для отчетности.
Ну и опять же, автора другое интересует - как наладить работу команды, а не как общаться с клиентами.
вот только не забывайте о такой мелочи - что это PHP. То есть для процессора нагрузки как бы нет, но мы этим запросом полностью блокируем весь воркер аж на 15 секунд. В итоге загрузка процессора будет слишком низкой.
staffID: повторюсь - вы говорите что используете supervidord. А стало быть оно само запускается. В крайнем случае есть в npm пакет под названием forever - тот же supervisord только на js и менее функциональный.
candybooberr: на вашем этапе скорее всего почти все инструменты будут новыми. Веселье заключается в том, что... почти все похоже. Скажем вы можете выбирать реакт или ангуляр или эмбер, но все это приблизительно похоже. Или там джанго и RoR - принципы у них так же похожи, и идеи они друг у друга активно тырят.
То есть на вашем этапе я бы сосредоточился на поднятии своего уровня в том что вы уже знаете, а так же добавлял бы новое только тогда, когда от этого будет профит (например научитесь писать тесты, чем раньше вы это сделаете - тем проще вам будет и вы станете более ценным кадром на рынке труда. А еще к вам просто может подойти коллега и сказать "с завтра переходим на то-то то-то" и как бы уже надо разбираться).
представление в лучае PHP - это HTTP. Контроллер - это место формирование представления (шаблонизация, сериализация и т.д.). Так же контроллер конвертирует представление (HTTP запрос) в вызов методов вашего приложения.
Контроллер может состоять из цепочки контроллеров (фронт контроллер, мидлвэры и уже потом "контроллер") - это эдакий слой адаптеров.
Что из этого следует? "представление" никуда лесть не должно. Все что нужно должно быть получено в контроллере еще до того как начнется формирование представления.
Пока писал вам мысль тут проскочила... Если рассматривать зависимости между элементами MVC можно заметить интересные вещи... Например наше View не зависит напрямую от модели, между view и model чисто observable-отношения. То есть по хорошему вьюшка подписывается на события модели, но не взаимодействует напрямую с ней. По событиям нам приходят уже готовые данные... Вьюшке нужно только поменять их представление и отобразить пользователю.
Точно так же контроллер напрямую не завязан на view, он только ловит события. А это значит что мы можем спокойно менять view и это не потребует особых изменений в контроллере.
Единственные ребята у которых есть прямое взаимодействие - это контроллер и модель.. Контроллер зависит от модели, но не наоборот.
Так же, в отличии от MVVM или MVP, где модель четко описывается как модель предметной области, во всех прочитанных мною документах о MVC "модель" рассматривается как тупое хранилище состояния. Словом... надо будет перечитать еще разок... может еще чего интересного придет в голову... пока сложно сформулировать мысль. Ну и извините за непоследовательность, я уже порядком текста накропал - жалко)
а что такое "одно представление данных"?
У любых данных есть представление. В приложении данные на самом низком уровне представлены в виде примитивных типов (строки, числа, массивы, ну вы поняли).
Однако это не достаточно хорошо позволяет нам строить декомпозицию системы, изолируя отдельные правила, а так же не позволяет нам удобно работать с этими данными. Например возьмем даты. Даты можно представить в виде целого числа (unix timestamp) а можно в виде строки... Но как правило строки нам почти никогда не удобны (только для отладки) а числа удобны далеко не всегда. Да и потом, в поведении которое работает с датами нужно как-то ограничить что может приходить на вход.
Вот мы и вводим свои типы данных, которые построены внутри используя примитивные типы, но являются уже чуть большим. Скажем мы можем сформировать дату из строки, и внутри будет поведение (фабрика какая-нибудь) которая будет ограничивать нас в том, что считается датой. Да и сами эти типы данных будут иметь дополнительное поведение для более удобной работы. Но этот объект все еще состоит внутри только из примитивов. Давайте пойдем дальше.
Допустим у нас в системе много работы с диапозонами дат. Выгодно ввести один тип данных, который будет характеризовать диапозоны. Это будет так же какой-то новый объект, который на вход будет принимать даты, и имеет внутри какое-то поведение, какую-то внутреннюю логику.
До ООП все эти типы представлялись в виде структур данных, и по сути это являлось именно информационной моделью системы. То как данные в ней представлены (то о чем вы говорили). Назовем это состоянием. Так же рядом лежали функции, которые с этой информационной моделью работали (поведение, или модель бизнес логики).
С введением ООП ситуация стала немного интереснее. Объекты объеденили состояние и поведение, позволяя нам инкапсулировать побочные эффекты при работе с состоянием. По сути мы "прячем" внутрненнее устройство объектов и то, в каком виде внутри представлены данные.
Создав объект даты, мы понятия не имеем как состояние хранится внутри. Это просто отдельный компонент системы который о системе ничего не знает, да ему и не нужно. Его зона ответственности - хранение дат и удобная с ними работа. Мы ничерта не знаем о способе хранения состояния объекта даты. Мы можем просить объект предоставить нам свое состояние, но нам вернутся данные в том представлении, которое удобно в контексте использования. Например мы можем забрать дату в виде строки, но оно явно внутри не как строка лежит. Мы можем забрать timestamp но 100% уверенности что оно внутри именно в этом формате лежит у нас нет. Все детали реализации сокрыты с наших глаз.
Как пример, в одном из моих проектов есть объект FlightRequest, который описывает состояние заказа вертолета. И я могу спросить этот объект "getStatus" и вернется мне строка, хотя внури этой строки нет, внутри хранится коллекция действий оператора над этим объектом, на основании чего я вывожу статус. Ранее там действительно хранилась строка, но воизбежание конфликтов со стороны действий нескольких операторов, пришлось поменять информационную модель этого объекта.
Если мы продолжим подниматься по дереву декомпозиции вверх, мы найдем вершины этого "графа" объектов. Это самые высокоуровневые компоненты системы. Это может быть как один объект (в случае если система относительно простая) либо несколько объектов, которые ничего не знают друг о друге и выполняют каждый свою часть работы. Например один высокоуровневый объект отвечает за управление каталогом товаров, а другой - управление пользователями системы, третий - агрегация отчетов о продажах.
Мы можем говорить об этих объектах как о под-системах, каждый из которых максимально изолирован друг от друга, каждый из которых обладает низкой связанностью и высоким зацеплением.
И вот это я называю "приложением". Возможно немного попахивает наркоманией, но мне так проще. Разумеется я делаю декомпозицию системы не снизу вверх, а наоборот, сначала выделяя высокоуровневые компоненты и т.д. и потом уже иду вниз. На каком-то уровне они начинают работать с общим ядром, но ядро не вкурсе этого, как и другие компоненты понятия не имеют что с ядром предметной области работает кто-то еще.
Ведь есть же ещё ViewModel, которые снесут мозг тем кто не сможет с этим шагом разобраться.
MVC - автивная вьюшка (то есть не тупой кусок HTML, как вы верно подметили, а полноценный пласт кода, иногда более сложный чем логика которой он служит), то есть оно наполняет себя состоянием самостоятельно. Контроллер только обрабатывает события отправляеыме редакторами (элементы view) и преобразует асинхронные действия пользователей над адктивным вью в синхронные вызовы методов модели с просьбами обновить свое состояние. Данные в этом случае ходят строго по кругу.
MVVM - пассивная вьюшка (тупой кусок HTML, декларативное представление), которое полностью управляется ViewModel. Именно последнее наполняет вьюшку состоянием, используя биндинги. Так же используя биндинги происхоит реакция на действия пользователей и "преобразование асинхронных действий пользователя в синхронные сообщения к модели". Медиатором там выступает биндер, который связывает данные из view model и view.
MVP - пассивная вьюшка... собственно то же что MVVM только без биндингов, все на старых добрых событиях. Из интересных особенностей - презентера создает именно view... Не знаю почему но это показалось мне интересным и это резко меняет то, как мы можем организовывать эти компоненты.
MVA - очень похоже на MVVM, за исключением того, что нет биндингов, а один ViewModel заменяет цепочка адаптеров. Адаптер может быть как один, так и целая иерархия. Это позволяет реюзать код при формировании вью.
И что у этого всего общего? В основном то что модель присутствует везде. Это та "верхушка" (одна из) графа объектов, представляюего приложение. Именно она и только она является ответственной за изменение своего внуреннего состояния.
Из интересных различий - Контроллер в MVC не должен иметь состояния. View наоборот имеет состояние. В MVVM и MVP view состояния не имеет, это просто пассивное представление.
Но самая большая разница - это зависимости между объектами в этих конфигурациях.
copal: компонент - это довольно абстрактный термин. Он просто описывае составную часть чего-то большего. Точно так же как мы можем рассматривать кристал алмаза как объект, состоящий из отдельных компонентов кристалической решетки, которые образованы трехмерными структурами атомов углерода, которые в свою очередь состоят из электронного облака и ядра, которое в свою очередь... что-то понесло меня.
Короче соль в декомпозиции системы на компоненты, каждый из которых выполняет свою роль. Скажем "компоненты" реакта лет 10 назад называли бы виджетами, а еще лет за 10 до - контролами.
я когда говорю о MVC имею в виду элементы граффического интерфейса. Больше ни на что MVC в моем понимании не влияет и именно для этого оно было изначально придумано - уменьшение связанности между приложением и граффическим интерфейсом. Приложение имеет одно представление данных, одну модель, а граффический интерфейс отображает ментальную модель пользователя.
Компоненты реакта - это активное view, которое реализовано как чистая функция. Модель приложения на вход - ментальная модель на выход.
По сути MVC это частный случай принципа разделения ответственности и не более. И важно понимать зачем это надо, а не как это реализуется в частном случае.
А статью я планирую перевести, как по мне это будет продуктивнее все же чем "еще одна статья о MVC", как вы верно подметили.
Андрей: многопоточность, это когда у нас в рамках одного процесса работает несколько потоков. То есть несколько инструкций могут выполняться одновременно.
> просто яп который является веб-приложнием и который является посредником.
нет, это просто web-приложение. Оно самодостаточное. То что оно юзает базу данных - вы можете не использовать ее, это деталь реализации, совершенно второстепенная штука.