Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
Гнусно воспользуюсь авторской возможностью оставить первый комментарий и попрошу инвайт на Автокадабру. danneutron@gmail.com. Предварительное спасибо.
Вот только не понятно, почему все подзапросы, судя по схеме, предлагается делать из контроллеров. Помоему самый смак как раз в том, что можно из вьюшки вызвать фрагмент страницы с баннерами, не засоряя каждый контроллер логикой связанной с ротацией. Или еще какие-то повторяющиеся, требующие своего контроллера, блоки страницы.
Неужели запрос к другому серверу будет быстрее, чем вызов внутри запущенного приложения? Если узкое место — это база данных сообщений, то можно перенести только базу и перенастроить модель.
Насколько я понял, изначально был вызов к локальному сервису. Просто после оптимизации обращения ушли на соседний сервер, а затраты на соединение остались без изменений.
Я тоже так понял. Только или пример неудачный или я не вижу смысла в такой оптимизации. Делать последовательные вызовы к другим серверам будет намного накладней, чем локальный код. В большинстве случаев оптимизации требует именно база данных, а это происходит другими способами. Если вам нужно оптимизировать именно код, то скорее всего вы одна из ста компаний мира с многомиллионной аудиторией, и вы не используете Kohana.
А если уж оптимизировать таким образом, то чтобы избежать задержек, вызовы к серверу сообщений делать аяксом на клиенте.
А если уж оптимизировать таким образом, то чтобы избежать задержек, вызовы к серверу сообщений делать аяксом на клиенте.
Безусловно, преждевременна оптимизация — зло. Несмотря на это я, к примеру, при разработке каждого проекта планирую его масштабирумость. И пусть генерация обычной страницы из-за внутренних подзапросов будет на 0,2 секунды больше, зато перенос части данных или логики за пределы приложения будет безболезненным и практически не повлияет на быстродействие.
Как я понял схема такая: два контроллера занимают по 50% cpu и не успевают обрабатывать запросы (БД пускай уже на другом хосте), переносим один контроллер на другой хост и отдаем весь цпу первому.
Оказывается, первый же написанный мной веб-фреймворк, по нелепой случайности обладал чудо-свойством масштабируемости, и всё за счёт возможности вызывать один контроллер из другого! Поразительно.
Если бы вы внимательно прочитали статью, вы бы увидели, что HMVC — это не «возможность вызывать один контроллер из другого». Точнее, это лишь малая его часть. Вызвать один контроллер из другого дело нехитрое и ничем не отличается от обычного создания экземпляра класса:
Вся прелесть HMVC как раз в том, что тут создаются полноценные запросы к каким-либо частям приложения, вероятно даже внешнего, которое никак не зависит от вызывающего, и поэтому (если говорить в контексте данной статьи) может быть в частности перенесено на другой сервер, что сильно упрощает горизонтальное масштабирования приложения
$controller = new Controller;
$controller->action();
Вся прелесть HMVC как раз в том, что тут создаются полноценные запросы к каким-либо частям приложения, вероятно даже внешнего, которое никак не зависит от вызывающего, и поэтому (если говорить в контексте данной статьи) может быть в частности перенесено на другой сервер, что сильно упрощает горизонтальное масштабирования приложения
Большое спасибо за материал — понятно и просто. И перевод хороший :)
Хоть пока что сижу на CodeIniter ( в котором тоже можно прикрутить HMVC), но я так и н понял — почему я не могу штатными средствами, без применения иерархичности триад MVC масштабировать свое приложение горизонтально?
Ведь вызвать другой контроллер можно из любой точки приложения вышеприведенным примером:
Разъясните, пожалуйста — хочу понять разницу.
Хоть пока что сижу на CodeIniter ( в котором тоже можно прикрутить HMVC), но я так и н понял — почему я не могу штатными средствами, без применения иерархичности триад MVC масштабировать свое приложение горизонтально?
Ведь вызвать другой контроллер можно из любой точки приложения вышеприведенным примером:
$controller = new Controller;
$controller->action();
Разъясните, пожалуйста — хочу понять разницу.
Вообще-то не я автор перевода, но раз уж вы адресовали вопрос мне — попробую ответить :)
Если сказать проще, то основной запрос работает с одними параметрами ($_GET, $_POST), а подзапрос с другими. При этом обращение к параметрам идёт не напрямую, а с помощью специальных методов, например вместо $_POST['param'] нужно писать $this->request->post('param');
Плюс возможность сделать запрос на сторонний сервер (хотя по большей части это просто обёртка над CURLом или HTTP-классами)
Ведь вызвать другой контроллер можно из любой точки приложения вышеприведенным примеромНесомненно, это можно сделать. Однако, это не всегда возможно, потому что парадигма HMVC предполагает изоляцию параметров запроса, чего невозможно добиться «обычными» средствами.
Если сказать проще, то основной запрос работает с одними параметрами ($_GET, $_POST), а подзапрос с другими. При этом обращение к параметрам идёт не напрямую, а с помощью специальных методов, например вместо $_POST['param'] нужно писать $this->request->post('param');
Плюс возможность сделать запрос на сторонний сервер (хотя по большей части это просто обёртка над CURLом или HTTP-классами)
Спасибо. Так вот использование того же curl'а полностью может заменить HMVC? (да, это некошерно, но вопрос о возможности).
Можете привести пример приложения, когда штатными стредствами HMC-парадигмы нельзя обойтись, а нужно использовать иерархическую ее структуру?
Можете привести пример приложения, когда штатными стредствами HMC-парадигмы нельзя обойтись, а нужно использовать иерархическую ее структуру?
В части внешних запросов да, может полностью заменить. Но внутри приложения — нет. Во-первых, не будете же вы curl'ом обращаться из приложения к самому себе, когда грубо говоря можно просто подключить файл через require. А во-вторых, вы тогда не сможете отличить начальный запрос от текущего (внутреннего) запроса, разве что по IP-адресу, но это костыли. Тем более, что «нормальный» HMVC умеет работать как с текущим запросом, так и с начальным.
Можете привести пример приложения, когда штатными стредствами HMC-парадигмы нельзя обойтись, а нужно использовать иерархическую ее структуру?Нет, не могу :) Если не учитывать вышесказанное, то HMVC — это просто ещё один способ повторного использования кода и его можно реализовать другими способами
В общей сложности понятно. На счет curl'а — конечно костыли — вообще никому не советую заменять одно другим (ну разве уж в очень исключительных случаях).
В общем случае пытаюсь провести параллель между KO3 и CI21 (+HMVC). Пока не вижу особых преимуществ в пользу первой, основывающих сделать переход на нее.
Спасибо.
В общем случае пытаюсь провести параллель между KO3 и CI21 (+HMVC). Пока не вижу особых преимуществ в пользу первой, основывающих сделать переход на нее.
Спасибо.
С вашего позволения немного пооффтоплю: я на Кохану ушёл с CI ещё задолго до появления в ней HMVC и совсем по другим причинам. О чём не жалею
Извольте тогда спросить — по каких? (Исключая то, что доступно в CI)
За CI 2.x не скажу, так как вообще с ним не знаком. В то время когда я поменял его на Kohana были версии CI 1.6, Kohana 2.2. Что меня привлекло тогда:
— PHP5 (против PHP4 у CI)
— это был форк CI, что означало с одной стороны простоту перехода, а с другой — новые фичи (бóльшая гибкость, проще расширяемость и т.д.)
KO3 — это уже отдельный разговор, но по моим субъективным ощущениям переход KO2 → KO3, это всё равно что пересесть с мопеда на мотоцикл
— PHP5 (против PHP4 у CI)
— это был форк CI, что означало с одной стороны простоту перехода, а с другой — новые фичи (бóльшая гибкость, проще расширяемость и т.д.)
KO3 — это уже отдельный разговор, но по моим субъективным ощущениям переход KO2 → KO3, это всё равно что пересесть с мопеда на мотоцикл
Кроме HMVC, ORM, изменений i18n и другой разрабатываемой команды что то отличает 2 от 3?
А то сейчас CI2 дальше ушел, чем тогдашняя KO2.2
А то сейчас CI2 дальше ушел, чем тогдашняя KO2.2
C недавнего применяю HMVC в CodeIgniter. Каждая такая триада — это отдельный независимый модуль. Есть часть стадартных модулей, которые можно использовать в последующих проектах + специфический функционал под конкретную задачу…
Достаточно подробно, спасибо за перевод.
Спасибо за интересный перевод отличной статьи. Не поленились даже картинки перевести :)
От себя могу добавить, что полная поддержка HMVC (внешние запросы и передача отдельных данных (POST, GET) другому запросу) появилась в версии 3.1, которая сейчас находится в стадии RC2 и должна в скором времени увидеть свет
От себя могу добавить, что полная поддержка HMVC (внешние запросы и передача отдельных данных (POST, GET) другому запросу) появилась в версии 3.1, которая сейчас находится в стадии RC2 и должна в скором времени увидеть свет
Простите за непонимание, но можете на этом примере показать как будет осуществляться разграничение прав в разных Триадах одновременно?
Не знаю как в Kohana, но можно ли например шарить Модели между триадами, чтобы например модель User, Page были доступны всем триадам?
Конкретная модель (как экземпляр класса) не будет доступна, потому что триады независимы друг от друга. Однако данные, из которых наша модель строится могут быть доступны, поэтому сформировать эту модель внутри отдельно взятой триады можно.
Жаль, в CodeIgniter если положить модель в общую папку app/models то эта модель будет доступна любому модулю (триаде) из папки models
А если ложить модели уже в папки самих модулей, триад, например modules/news/model/usermodel.php
то эта модель может быть доступна например из Модуля (триады) контроллера Articles например так
$this->news->usermodel->…
В реальных проектах всё равно без зависимостей не обойтись или DI использовать или просто контроллировать их.
А если ложить модели уже в папки самих модулей, триад, например modules/news/model/usermodel.php
то эта модель может быть доступна например из Модуля (триады) контроллера Articles например так
$this->news->usermodel->…
В реальных проектах всё равно без зависимостей не обойтись или DI использовать или просто контроллировать их.
Подождите. Физически модель (в виде файла) легко может быть доступна, если система работает в рамках одного физического сервера. Говоря о недоступности модели как экземпляра класса, я имел ввиду недоступность той самой модели, именно того экземпляра. Под моделью мы понимаем не только набор методов в файле, а также еще и данные, которые в этой модели инкапсулированы.
Словом, модель легко может быть доступна, но смысл в максимальной изоляции. Если же изоляция неизбежна, то триада А, делая запрос к триаде Б, может передать ей необходимые данные для формирования этой самой модели самостоятельно. Потому что сама триада А для получения этой модели обращалась к модели В :)
Словом, модель легко может быть доступна, но смысл в максимальной изоляции. Если же изоляция неизбежна, то триада А, делая запрос к триаде Б, может передать ей необходимые данные для формирования этой самой модели самостоятельно. Потому что сама триада А для получения этой модели обращалась к модели В :)
Поправка: Потому что сама триада А для получения этой модели обращалась к триаде В :)
Похоже не совсем донес мысль, не в физическом плане, а разумеется результаты выполнения, инкапсулированные данные модели одной триады, доступны ли они контроллеру из другой триады?
Например, есть модуль
News
у него контроллер News и модель NewsModel
и модуль Users
у него контроллер Users и модель Users
можно ли из контроллера News вызвать модель Users чтобы получить например список всех пользователей кто связан с новостью например чтобы это потом отобразить во вью самой новости?
Например, есть модуль
News
у него контроллер News и модель NewsModel
и модуль Users
у него контроллер Users и модель Users
можно ли из контроллера News вызвать модель Users чтобы получить например список всех пользователей кто связан с новостью например чтобы это потом отобразить во вью самой новости?
Так в этом и смысл!
Мы делаем запрос из News в Users и говорим: эй, Users, дружище, дай-ка нам список всех пользователей, которые связаны со статьей N.
Вы саму суть раскрыли и затронули :) В этом и суть: список пользователей формируется не внтури News, а запрашивается извне, из модуля Users. Причем Users не знает зачем эти данные нужны, он их просто выбирает и отдает. А News уже использует.
Мы делаем запрос из News в Users и говорим: эй, Users, дружище, дай-ка нам список всех пользователей, которые связаны со статьей N.
Вы саму суть раскрыли и затронули :) В этом и суть: список пользователей формируется не внтури News, а запрашивается извне, из модуля Users. Причем Users не знает зачем эти данные нужны, он их просто выбирает и отдает. А News уже использует.
А теперь представьте, что у нас есть сервер, на котором хранятся только пользователи, а также есть другой, на котором хранятся только новости. Для быстродействия.
А третий сервер у нас фронтенд, который оба вышеуказанных теребит и выдает новости вместе с пользователями по запросу :)
Красота!
А третий сервер у нас фронтенд, который оба вышеуказанных теребит и выдает новости вместе с пользователями по запросу :)
Красота!
Вся нагрузка при описанной архитектуре остается на сервере приложений, который обрабатывает входящие запросы. Так как ответы сервисов будут теперь генерироваться дольше, за счет выноса оных на отдельные сервера, это несомненно создаст дополнительную нагрузку на основной сервер. Решением в таком случае было бы использовать какой-нибудь «железный» контент-свитчер, перенаправляющий запросы на разные сервера приложений. С таким подходом, использовать HMVC не обязательно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабирование веб-приложений с помощью HMVC