Soru Laravel komutları ve işleri


Laravel 5.1'deki farklı komut benzeri sınıflar arasındaki farkın ne olduğunu merak ediyordum. Laravel 5.1'in aşağıdaki özelliklere sahip olduğunu söyleyebilirim:

  • Konsol komutları (artisan make:console)
  • Komutlar (artisan make:command)
    • İşleyicileri (artisan make::command --handler)
  • Meslekler (artisan make:job)

4,2'den 5,1'e kadar düz bir şekilde geldim, bu yüzden 4,2 ile 5,1 arasında ne olduğunu bilmiyorum, ama orta olana söylendi.sadece komutlar) temelde gerçekten kullanılmayacaklar - kuyruk işlerinin 5.0'da “komut” haline geldiği zamanlar, ama Laravel buna karşı karar verdikten sonra ve uyumluluk içindeydiler. Bununla birlikte, bu noktada% 100 değilim, bu yüzden açıklık takdir edilecektir.

Benim özel kullanım durumum, kendi kendine yetebilen bir 'runnable' görevini yerleştirmek istiyorum. Örneğin, belirli bir dizinden 5 günden daha eski dosyaları kaldıracak bir şey (ancak herhangi bir şey yapabilir).

İlk başta bu bir konsol komutu gibi geliyor - Ben onu çalıştırmak mümkün olmak istiyorum artisan, başlangıç ​​için. Ama aynı zamanda bir programda da isteyebilirim (harika, artisan schedule:run konsol komutlarını çalıştırır). Ama aynı zamanda koddan eşzamansız olarak yürütmek isteyebilirim. Konsol komutları çalıştırılabilir eşzamanlı ile Artisan::call()ama asenkronize için, bu (sanırım) kuyrukların geldiği yer, ve aniden bir iş olmak zorunda.

Tamam, işimiz var. Şimdi koddan bir kuyruğa ekleyebiliriz, ancak bunu bir esnaf komutu olarak (eşzamanlı olarak) nasıl uygularız? Sadece ince bir konsol komutu oluşturabilir ve DispatchesJobs Bunun için (ya da içindeki kodu), ve sonra işi gönderir? İşin her zaman bir sıraya girmesi mi yoksa bir işin eşzamanlı olarak yürütülmesini sağlayabilir miyiz (ve ideal olarak konsolun komutunun çıktısına çıktı mı?) Aynı soru bir program üzerinde çalışmak için de geçerli - bu konsolu oluşturmam gerekiyor mu? komutu verin ve programlayıcıya ekleyin veya zamanlayıcıyı doğrudan işi çalıştırmasını sağlayabilir miyim?

Son olarak, konsol komutları olmayan, ne de işleri olan 'komutlar' var. Daha önce söylediğim gibi, insanlar bana bunların (kinda) geri döndürülen bir Laravel 5.0 kod değişikliğinden sadece askıda olduğunu söylüyor. Ama artisan make komut hala onlar için mevcut değil, bu yüzden o ölü. Ayrıca, kendi kendine taşıma komutu ile anlaşma nedir (varsayılan, bir ile birlikte gelir handle yöntem) ve bir işleyici sınıfını 'gerektiren' artisan make:command --handler)? Bunları gerçekten nasıl yürütüyorsun? Elle ile (new App\Command\SomeCommand)->handle(); veya (new App\handlers\SomeCommandHandler)->handle(new App\Command\SomeCommand)ya da bilmediğim bir gizli sistem var mı (belki iş / kuyruk dağıtıcı kullanarak gönderilebilirler)? Ayrıca 'kuyruk' komutları da oluşturabilirsiniz. artisan make::command --queuedPeki, bunlar da nasıl farklı?

Sanırım sorum şu şekilde kaynıyor:

  • Gerçek nedir (semantik ve hepsi arasındaki fonksiyonel fark?
  • Onları 'çalıştırmak' için doğru yolu nedir?
  • Hangi şekilde olursa olsun, kendimce uygun olması gereken, genellikle bağımsız bir kodun çalışması için en iyisi hangisidir?

Kuyrukları nasıl kullanacağına ve konsol komutları oluşturmaya ilişkin belgelerinde bilgi buldum, ancak bunları ne zaman kullanacağınız konusunda tam olarak bir şey ya da komut sınıfları ve işleyicilerinde gerçekten bir şey olmadı.


İlgili ama tam olarak aynı değil (ayrıca, cevapsız): Laravel 5.1 komutları ve işleri


21
2017-08-19 12:11


Menşei




Cevaplar:


Bu "nesneleri" şöyle görüyorum: (Yan projelerden birinden kod örnekleri ekledim)

Konsol

Komut satırından yürütmek istediğim şeyler (Örneğinizde "x'ten büyük dosyaları sil" ile belirttiğiniz gibi). Ama mesele şu ki, iş mantığını komuta.

Örnek: Bir konsol komutu ile görüntüleri Imgur'dan almak için bir komut yakar. Sınıf FetchImages görüntüleri getirmenin gerçek iş mantığını içerir.

komuta

Gerçek mantığı içeren sınıf. Ayrıca bu komutu uygulamanızdan da çağırabilirsiniz. app()->make(Command::class)->handle().

Örnek: Örnek 1'de belirtilen komut. Gerçek API'nın Imgur'a çağrı yaptığı ve döndürülen verileri işleyen mantığı içerir.

Meslekler

Bu uygulamayı Laravel 5.0 ile yaptım jobs o zamanlar bir şey değildi. Fakat görebildiğim gibi, İşler, komutlar gibidir, ancak sıraya girerler ve gönderilebilirler. (Bu örneklerde görmüş olabileceğiniz gibi, bu komutlar söz konusu Arayüzleri uygular. SelfHandling ve ShouldBeQueued).


Kendimi deneyimli bir Laravel Geliştirici olarak görüyorum ancak bu değişiklikler Commands ve Jobs anlamak oldukça zor.

DÜZENLE: Laravel Dokümanlarından:

Uygulama / Komutlar dizini, uygulamaya / İşler olarak yeniden adlandırıldı. Ancak, tüm komutlarınızı yeni konuma taşımanız gerekmez ve make: komutunu ve işleyicisini kullanmaya devam edebilirsiniz: sınıflarınızı oluşturmak için Artisan komutları komutunu kullanın.

Benzer şekilde, app / İşleyicileri dizini app / Dinleyiciler olarak yeniden adlandırıldı ve şimdi sadece olay dinleyicileri içeriyor. Ancak, varolan komut ve olay işleyicilerinizi taşımak veya yeniden adlandırmanız gerekmez ve olay işleyicileri oluşturmak için işleyici: olay komutunu kullanmaya devam edebilirsiniz.

Laravel 5.0 klasör yapısı için geriye dönük uyumluluk sağlayarak, uygulamalarınızı Laravel 5.1'e yükseltebilir ve sizin ya da ekibiniz için uygun olduğunda olaylarınızı ve komutlarınızı yeni konumlarına yavaşça yükseltebilirsiniz.


16
2017-08-24 09:20





Konsol Komutları

Laravel bir süredir konsol "komutları" aldı. Temelde değişmezler ve her zaman olduğu gibi çalışırlar. Basit olarak, komut satırı için rotaların karşılığıdırlar - uygulamaya giriş noktası. Hiçbir şekilde alakalı değiller ...

Komuta Otobüsü

Laravel 5.0 bir uygulama başlattı Command Bus desen - Komut Veri Yolu Komutları. (Bunların, CLI Komutları ile aralarındaki karışıklık nedeniyle İşler olarak yeniden adlandırıldıklarına inanıyorum).

İki bölüm olarak bir komut veriyolu - çalıştırılacak bir komutu temsil eden bir nesne, gereksinim duyduğu tüm veriler (iş) ve komutu (işleyici) yürütecek bir sınıf.

İşleyici

Laravel'de, bir işi kendi kendine idare etmek için ilan edebilirsiniz - yani, bir ele alma yönteminin kendisi vardır.

Bir komut işleyicisini kaydetmek istiyorsanız, bir servis sağlayıcıda aşağıdakileri arayabilirsiniz:

app('Illuminate\Bus\Dispatcher')->maps(['Job' => 'Handler']);

Job iş için sınıf adı ve Handler işleyicinin sınıf adıdır.

Laravel 5.0'daki işleyiciler dizini, bu ilişkileri örtük olarak açıklamanın bir yoluydu (ör. EmailCommand komutlar klasöründe bir EmailCommandHandler işleyicileri klasöründe).

Komuta Gönderme

Bir komutu göndermek için aşağıdakileri kullanabilirsiniz.

app('Illuminate\Bus\Dispatcher')->dispatch(new EmailPersonCommand('email@you.com', $otherdata));

Kuyruklar

İşler, varsayılan olarak, çağrıldıklarında (veya gönderildiklerinde) çalışır. Onları ayarlayarak ShouldQueue gönderildiklerinde onları her zaman bir kuyruğa gönderir.

Bazen eşzamanlı olarak ve başka zaman uyumsuz olarak çalıştırmak istiyorsanız, arayabilirsin $dispatcher->dispatchToQueue($job) sıraya alınmasını istediğinizde. Bir geçtiğinizde, içten gelen her şey budur. ShouldQueue iş için ->dispatch().

düzenleme: Kuyrukta (veya değil)

Dağıtıcıya daha yeni baktım. dispatch yöntem, komutun bir olup olmadığını denetler. ShouldQueueve ya dispatchToQueue veya dispatchNow. Bunun yerine doğrudan bu yöntemlerden birini arayabilirsiniz. dispatch Komutunuzla varsayılan davranışı geçersiz kılmak istersiniz.

Dolayısıyla, sizin durumunuzda, işinizin "varsayılan" davranışının ne olduğuna bağlı olarak (yani normalde sıraya konulacak mı?) - sahip olmak ShouldQueue, ve kullan dispatchNow CLI Komutunda. - yok ShouldQueue, ve kullan dispatchToQueue Bunu kodunuzda çağırırsınız.

Onun sesinden, eskiyi yapardım.


26
2017-08-24 09:35



Bu yüzden kuyruğa alınabilecek ancak sıraya alınabilecek bir iş yazmazsam, ShouldQueue arayüzü, işimi yapacağım gibi her zaman sıra ben olmasam bile her zaman Bu ne? Ama ben kutu hala olmayan bir işi kuyruğa almak ShouldQueue, sağ? - alexrussell
@alexrussell - cevabımı biraz daha araştırdıktan sonra düzenledim. - stef
A-ha bu mantıklı. Görevlilere kendim baktım ve buldum dispatchNow gerçekten benim konsol komutumda kullanıyorum ama bu davranışı tersine çevirebileceğimin farkında değildim. Bunun için teşekkürler, çok yardımcı oldu. - alexrussell
FYI @ stefanzweifel'in cevabını, sorulan soruya daha yakın bir şekilde cevapladığını kabul ettim (hepsi ve 5.0 / 5.1 ile olan anlaşma nedir), ayrıca Slack'de onunla biraz tartışmaya devam ettim ve biraz daha açıklığa kavuştum (veya En azından biraz "evet çok kafa karıştırıcı, sadece siz değil!"). Ancak, burada 5.0 komut veriyolu hakkında açıkladığınız açıklama benim özel durumum için gerçekten yardımcı oldu ve eğer ikisini de kabul edebilirsem! - alexrussell
ha - evet. asıl sorudan biraz saptırıldım! :) yardımcı olduğuma sevindim! - stef


Sadece gerçek cevaplara bir ek.

Laravel'de İşler> = 5.1, Laravel 5.0'daki Komutlar Veri Yolu.

Bu karışıklık nedeniyle sadece bir ad değişikliği Console\Commands (komutlar konsoldan çalıştırılır) ve Command Bus (ihtiva eden Commands) Uygulama Görevleri için.

Şaşırmamalısınız:

  • Command Bus : "uygulamanızın görevlerini kapsüllemek" için kullanılır (laravel 5.0 doc'dan). Jobs
  • Console\Commands : "Artisan [...] Laravel ile birlikte verilen komut satırı arabirimi" (laravel 5.1 docs) için kullanılır.

1
2018-02-17 09:41



Sadece 5.1'in hem komutlara hem de işlere sahip olması garip görünüyor ve iki ayrı şey olarak çalışıyorlar. - alexrussell
Cevabımı daha hassas bir şekilde güncelledim Command Bus ! = Console Commands - Ifnot
Sory @Ifnot, şimdi tüm durumu anlıyorum - bu sadece komutların işlere nasıl “yeniden adlandırıldığını”, ancak Laravel çerçeve koduyla yeniden adlandırılmadığını görmek çok ilginç: 5.1, konsol komutlarını evet ama daha sonra her ikisi de komutlar (otobüste olduğu gibi) ve işler ('yeni' komutlarda olduğu gibi). Basit bir yeniden adlandırmanın, 5.1'in hem komutlara hem de işlere sahip olmadığını düşünürdünüz. Her neyse, anladım ki BC nedenleriyle - Taylor 5,1'e kolayca yükseltilebilmesini istiyordu, bu yüzden komuta veriyolunu olduğu gibi bıraktı, ancak emirlerin ardılı olarak işleri tanıttı. Bu yüzden her ikisi de mevcut. - alexrussell
@alexrussell Evet, Command Bus BC'den kaçınmak için 5.0'dan 5.1'e kadar uyumlu kalın, ancak artık Jobs mekanizmayı değiştirmelidir. - Ifnot
Gerçekten de - ilk kafa karışıklığımın, komutların zanaatkârlaştırılmış olarak işaretlenmediği ve işlerin 5.1'de emirleri üstlendiğini gösteren herhangi bir belge bulunmadığı gerçeğinden geldiğini düşünüyorum. - alexrussell