Неужели Mojolicious и Moose играют вместе?

Question

Я работаю над приложением Mojo, и я хотел бы иметь возможность использовать некоторые роли Лоу, чтобы облегчить мою жизнь.

В CPAN я вижу MojoX::Moose::Controller, который имеет очень простые внутренние элементы. Я больше не вижу, чтобы использовать Муса с Моджо. Любые потенциальные проблемы, о которых я должен знать, или это просто плавное плавание?

Answer 1

По моему опыту, они отлично работают вместе. Я успешно создал Mojolicious приложения с Moose (и Moo также должен работать нормально.)

Moose может расширить базовый класс Mojolicious, а затем вы можете делать все, что угодно. Вот пример:

package MyApp { 
    use Moose; 
    extends 'Mojolicious'; 
    with 'MyApp::Role::Whatever'; 

    sub startup { 
     my $self = shift; 
     my $r = $self->routes; 
     $r->get('/')->to('foo#default'); 
    } 
} 

package MyApp::Foo { 
    use Moose; 
    extends 'Mojolicious::Controller'; 

    sub default { 
     my $self = shift; 
     $self->render(text => "Helloooooo!!"); 
    } 
} 

Answer 2

Они определенно играют хорошо. Я создал API, который работает на кластере из 20 серверов. Это приложение mojo, которое также использует классы лося, которые потребляют несколько ролей.

Подход, который я принял, - это правильно наложить приложение, вплоть до уровня хранилища. В этом отношении mojo действительно нужен только на верхних уровнях стека. Вначале я создаю объект запроса на лоси, который затем толкается вниз по стеку. Внизу вниз создается объект ответа на основе лося, который передает ответ обратно на верхние уровни стека. Наконец mojo берет на себя и обрабатывает окончательный ответ json.

Мы подталкиваем много производственного трафика через стек, и он блестяще работает. Единственное, что я сделал, это убедиться, что я использую XS-версии модулей, где это возможно, поскольку это повышает производительность стека.

Answer 3

С тех пор, как я изначально задал этот вопрос, мы перевели код Mojo + Moose в производство. Есть некоторые предостережения, которые я поделюсь здесь. Этот ответ на самом деле был написан Флорианом Рагвицем. Я отправляю от его имени.

Mojolicious и Moose могут хорошо играть вместе, но необходимо соблюдать осторожность, чтобы все хорошо работало, и есть некоторые оговорки.

Важно, чтобы конструктор Moose использовался для создания новых объектов. Использование MooseX::NonMoose - это простой способ обеспечить это. Без звонка в Moose во время построения объекта многие функции Moose, такие как BUILDARGS, BUILD, Проверка ограничений типа атрибута и жадные сборки не будут работать.

MooseX::NonMoose также делегируют к первоначальному Mojolicious::Controller конструктор, который имеет поведение только благословляя аргументы конструктора при условии ссылки на хэш. Это может привести к некоторым нечетным результатам.

Например:

package MyController; 

use Moose; 
use MooseX::NonMoose; 

extends 'Mojolicious::Controller'; 

has foo => (init_arg => 'bar'); 

Позже ...

MyController->new(bar => 42) # bless { foo => 42, bar => 42 }, 'MyController' 

Обратите внимание, как в результате благословенный ссылка хэш содержит ключи foo и bar, а не просто bar, как можно было бы ожидать из обычного класса Муз. Этот обычно не является проблемой, если вы не собираетесь использовать слоты объектов с с тем же именем, что и init_arg другого атрибута.

Существуют также ограничения на то, какие расширения Moose могут использоваться. Mojo требует экземпляров на основе хэша, поэтому вы не сможете использовать какие-либо мета-экземпляры, не содержащие хеша Moose, например MooseX::GlobRef и MooseX::ArrayRef. MooseX::StrictConstructor также не будет работать в этой среде, поскольку Moose не может определить, какие аргументы конструктора были , предназначенные для использования конструктором Mojo.

В целом, сочетающий в себе Mojolicious и Moose должны работать очень хорошо на практике, как долго, как вы знаете о маленьких предостережений и ОК с не будучи в состоянии использовать определенные Moose расширений.