Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
>нет способа изолировать engine от запросов из внешеного мира (каждый может сделать запрос к FooController напрямую);
ИМХО это плюс.
ИМХО это плюс.
Если выгрузить приложение на нормальный сервер, то по идее в логах будет 127.0.0.1 только для внутреннего вызова, так можно и фильтровать логи и защитить от внешних вызовов. Но вообще что-то мне идея реализации HMVC через полноценные HTTP запросы не очень нравится, даже если необходим доступ к отдельным триадам извне.
Тогда не получится разбить приложение на несколько машин, для масштабирования, например.
Чтобы часть запроса исполнялась на одном сервере, а часть на другом? Насколько это востребовано?
А насколько было востребовано ООП, когда оно не было популярным? HMVC — это новая парадигма и она требует другой подход к проектированию.
Я HMVC рассматриваю прежде всего как средство логической декомпозиции, но не физической.
Ты сейчас суть вопроса затронул! Rails, внутренние http-запросы — это все конкретная реализация. Одна из — не более. Можно использовать что угодно.
Но конкретно в данной реализации важно, что в каждом MVC-компоненте мы работаем с обычным rails-приложением, в котором явно выражен каждый из этих M V C.
Но конкретно в данной реализации важно, что в каждом MVC-компоненте мы работаем с обычным rails-приложением, в котором явно выражен каждый из этих M V C.
Почему просто из HomeController не вызывать FooController, не теряя явного выражения M, V и С, но теряя накладные расходы на HTTP?
Теоретически можно создать GoogleController, который крутится на сервере гугла, и отвечает на поисковые запросы.
Понятно, что это будет медленно, зато возможно.
Если речь идёт о крупном приложении вроде Github, появляется возможность контроллер blog вывести на другую машину (хотя это итак можно средствами того же nginx, но не суть), разгрузив приложение.
И обращаться к нему можно как «blog#index», (локально) или «5.5.5.5/blog/index», и суть по идее не меняется.
Понятно, что это будет медленно, зато возможно.
Если речь идёт о крупном приложении вроде Github, появляется возможность контроллер blog вывести на другую машину (хотя это итак можно средствами того же nginx, но не суть), разгрузив приложение.
И обращаться к нему можно как «blog#index», (локально) или «5.5.5.5/blog/index», и суть по идее не меняется.
А как это можно сделать?
Не очень силён в рельсах и в исходники лень лезть, предполагаю что
не сработает. По аналогии с другими фреймворками могу предположить, что достаточно будет (не минимально достаточно, но сработает без задействования сетевого уровня) формирование фейкового запроса ActionDispatch::Request и его обработка. То есть почти как у вас, но без сети. Обычно такие запросы формируются для функционального тестирования
Может ещё какого оверхида можно избежать, не запуская полный цикл обработки запроса, начиная с роутинга.
foo = FooController.new
foo_response = foo.bar
text = response.bodyне сработает. По аналогии с другими фреймворками могу предположить, что достаточно будет (не минимально достаточно, но сработает без задействования сетевого уровня) формирование фейкового запроса ActionDispatch::Request и его обработка. То есть почти как у вас, но без сети. Обычно такие запросы формируются для функционального тестирования
Может ещё какого оверхида можно избежать, не запуская полный цикл обработки запроса, начиная с роутинга.
Если в
вместо
Впрочем я не фанат HMVC, я думаю старый добрый подход с сегрегацией на сервисы и созданием API более перспективным, не последнюю роль играет вопрос прозрачности таких систем.
Как по мне HMVC сродни goto.
http = EM::HttpRequest.new("http://localhost:3000/foo/bar?text=#{params[:a]}").getвместо
localhost:3000 поставить балансировщик я думаю проблем с масштабированием не будет.Впрочем я не фанат HMVC, я думаю старый добрый подход с сегрегацией на сервисы и созданием API более перспективным, не последнюю роль играет вопрос прозрачности таких систем.
Как по мне HMVC сродни goto.
Хотите полноценное HMVC в Rails, используйте Cells.
А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
Дело времени. В других решениях реализовано и так и так одним и тем же способом. Разумеется, внутренние вызовы делаются не через HTTP. Вот пример христоматийный (это руби, но не суть)
// Internal request example
$internal_request = Request::factory('controller/action/param')
->execute();
// External request example
$external_request = Request::factory('http://www.ibuildings.com/controller/action/param')
->execute();
</code>
В Rails кстати из за REST может частичное HMVC из-коробки получиться, если обращаться к /posts/add.json через POST или PUT, используя обёртку. Для получения данных /posts.json через GET. Не, ну может быть я чего-то не понимаю, но если у вас возникает необходимость вызывать собственное приложение через внешний HTTP-вызов, чтобы получить кусочек html или некую структуру данных, то это epic fail в архитектуре и «HMVC» призывается лишь с целью отвлечь внимание от проблемы.
Да, задачи должны быть другого характера. Компоненты HMVC — это веб-сервисы. И решать они должны соответствующие задачи. Это уже вопрос декомпозиции. В ООП тоже можно смешное применение классам найти.
Похоже мы говорим о разных вещах…
HMVC, в моем представлении, — это возможность из одного контроллера (или из его представления) вызвать другой контроллер и получить в качестве результата его представление, т.е. в любом случае либо кусочек html, либо plain text, либо некую структуру данных (не важно в xml, json, etc.), чего уж тут смешного… Это помогает решить проблему с чистотой MVC, когда представления состоят из разнородных блоков.
А вопросы коммуникации веб-сервисов, на мой взгляд, никакого отношения к HMVC не имеют.
HMVC, в моем представлении, — это возможность из одного контроллера (или из его представления) вызвать другой контроллер и получить в качестве результата его представление, т.е. в любом случае либо кусочек html, либо plain text, либо некую структуру данных (не важно в xml, json, etc.), чего уж тут смешного… Это помогает решить проблему с чистотой MVC, когда представления состоят из разнородных блоков.
А вопросы коммуникации веб-сервисов, на мой взгляд, никакого отношения к HMVC не имеют.
Я говорю об обоих вещах. Для меня HMVC это возможность вызывать другой контроллер (как правило, именно из представления). Для моих задач это в подавляющем большинстве случаев означает синхронно вызвать другой контроллер в том же приложении (процессе/потоке) на том же сервисе. Хорошо, если фреймворк обеспечит прозрачную возможность так же вызывать произвольный веб-сервис без необходимости писать для него обёртку, плохо если ради такой возможности (а то и без неё) мой же контроллер доступный в том же процессе будет вызываться через полноценный HTTP-запрос.
Для того, чтобы синхронно вызвать другой контроллер в том же приложении (процессе/потоке) из представления другого контроллера Cells подходит идеально.
Теперь по поводу произвольности вызываемого контроллера…
На мой взгляд, разрешение вызова контроллера из представления — это серьёзное архитектурное решение и если фреймворк сам принимает это решение, разрешая подобный доступ к любому контроллеру, то это очень плохо. Только разработчик должен решать какие действия каких контроллеров можно так дёргать, что не отменяет возможности дёргать их и через обычный HTTP-запрос при желании.
Что касается веб-сервисов, то, на мой взгляд, они должны возвращать клиентскому коду только данные и ничего кроме данных. Для использования таких сервисов собственного сочинения отлично подходит ActiveResource, но это уже к вопросу о разнесении частей приложения по разным серверам…
Скажем прямо, подобный приём масштабирования действительно нужен крайне редко и, как правило, для узкоспециальных вещей. Потребности в неком универсальном решении для произвольного контроллера такие задачи не имеют.
Теперь по поводу произвольности вызываемого контроллера…
На мой взгляд, разрешение вызова контроллера из представления — это серьёзное архитектурное решение и если фреймворк сам принимает это решение, разрешая подобный доступ к любому контроллеру, то это очень плохо. Только разработчик должен решать какие действия каких контроллеров можно так дёргать, что не отменяет возможности дёргать их и через обычный HTTP-запрос при желании.
Что касается веб-сервисов, то, на мой взгляд, они должны возвращать клиентскому коду только данные и ничего кроме данных. Для использования таких сервисов собственного сочинения отлично подходит ActiveResource, но это уже к вопросу о разнесении частей приложения по разным серверам…
Скажем прямо, подобный приём масштабирования действительно нужен крайне редко и, как правило, для узкоспециальных вещей. Потребности в неком универсальном решении для произвольного контроллера такие задачи не имеют.
Возможно да, имеет смысл разработчику явно указывать что такой-то контроллер можно вызывать из представлений напрямую и накладывать на них какие-то ограничения, поскольку, например, не очень понятно что делать, если, например, контроллер результат выполнения которого должен по идее отображаться в сайдбаре, вернет внешний редирект. С другой стороны, если контроллер доступен по HTTP, то ничто нам не помешает внедрить его в тот же сайдбар с помощью фреймов или XHR, то есть ограничения превращаются в профанацию.
Ну во-первых, с помощью Cells можно делать в том числе и контроллеры недоступные через HTTP. Другими словами можно просто не подключать к ним роутинг.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.
>> Хотите полноценное HMVC в Rails, используйте Cells.
В Cells каждый компонент не является полноценным MVC.
>> А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
Это всего лишь реализация, я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами, как, например, в functional тестах
В Cells каждый компонент не является полноценным MVC.
>> А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
Это всего лишь реализация, я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами, как, например, в functional тестах
> В Cells каждый компонент не является полноценным MVC.
С чего вдруг? Cells-контроллеры наследуют AbstractController::Base из Rails, имеют доступ к моделям и могут рендерить любые views. Абсолютно полноценный MVC.
> я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами
как, например, в Cells!
С чего вдруг? Cells-контроллеры наследуют AbstractController::Base из Rails, имеют доступ к моделям и могут рендерить любые views. Абсолютно полноценный MVC.
> я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами
как, например, в Cells!
Rails engines могут вложенными, они существуют в отдельных namespace'ах. Но подсмотреть, как реализован request в cells — думаю, будет полезно.
Ну причём здесь Rails Engines? Они придуманы для повторного использования изолированных кусков приложения, а не для HMVC.
Те же namespace там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.
Те же namespace там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.
Я нарушить изоляци не хочу, я как раз считаю, что следует разработать механизм, который запретит всем обращаться ко всем.
Сейчас это можно сделать только административно: договориться не нарушать несвязность компонентов.
Для чего разрабатывались engines сейчас не так важно. Важно, что есть еще один способ, как их использовать.
Сейчас это можно сделать только административно: договориться не нарушать несвязность компонентов.
Для чего разрабатывались engines сейчас не так важно. Важно, что есть еще один способ, как их использовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как реализовать паттерн HMVC в Rails