MVC (Laravel) dove aggiungere la logica


137

Diciamo che ogni volta che eseguo un'operazione CRUD o modifico una relazione in un modo specifico, voglio fare anche qualcos'altro. Ad esempio, ogni volta che qualcuno pubblica un post, voglio anche salvare qualcosa in una tabella per l'analisi. Forse non è il miglior esempio, ma in generale c'è molta di questa funzionalità "raggruppata".

Normalmente vedo questo tipo di logica nei controller. Va tutto bene fino a quando non vuoi riprodurre questa funzionalità in molti posti. Quando inizi a entrare nei parziali, creando un'API e generando contenuti fittizi, diventa un problema mantenere le cose ASCIUTTE.

I modi che ho visto per gestirlo sono eventi, repository, librerie e aggiunta ai modelli. Ecco la mia comprensione di ciascuno:

Servizi: è qui che la maggior parte delle persone probabilmente inserisce questo codice. Il mio problema principale con i servizi è che a volte è difficile trovare funzionalità specifiche in loro e mi sento come se si dimenticassero quando le persone si concentrano sull'uso di Eloquent. Come faccio a sapere che devo chiamare un metodo publishPost()in una libreria quando posso semplicemente fare $post->is_published = 1?

L'unica condizione in cui vedo che funziona bene è se usi SOLO i servizi (e idealmente rendi Eloquent inaccessibile in qualche modo dai controller tutti insieme).

Alla fine sembra che questo creerebbe solo un mucchio di file extra non necessari se le tue richieste seguono generalmente la struttura del tuo modello.

Repository: da quello che ho capito, questo è fondamentalmente come un servizio, ma c'è un'interfaccia in modo da poter passare da un ORM al quale non ho bisogno.

Eventi: lo vedo come il sistema più elegante in un certo senso perché sai che i tuoi eventi modello saranno sempre chiamati su metodi Eloquent, quindi puoi scrivere i tuoi controller come faresti normalmente. Riesco a vederli diventare disordinati però e se qualcuno ha esempi di grandi progetti che utilizzano eventi per l'accoppiamento critico mi piacerebbe vederlo.

Modelli: tradizionalmente avrei classi che eseguivano CRUD e gestivano anche l'accoppiamento critico. Questo in realtà ha reso le cose facili perché sapevi che tutte le funzionalità di CRUD + erano presenti lì.

Semplice, ma nell'architettura MVC questo non è normalmente quello che vedo fatto. In un certo senso preferisco questo rispetto ai servizi poiché è un po 'più facile da trovare e ci sono meno file di cui tenere traccia. Può essere un po 'disorganizzato però. Mi piacerebbe sentire i fallimenti di questo metodo e perché la maggior parte delle persone non sembra farlo.

Quali sono i vantaggi / gli svantaggi di ciascun metodo? Mi sto perdendo qualcosa?


3
Puoi minimizzare la tua domanda?
L'Alfa,

3
Inoltre puoi controllare questo .
L'Alfa,

1
"Come faccio a sapere che devo chiamare un metodo publishingPost () in una libreria quando posso fare solo $ post-> is_published = 1?" Documentazione?
Ceejayoz,

una delle bellezze di eloquente e ORMS è più facile lavorare con loro senza molti documenti?
Sabrina Leggett,

1
Grazie per aver pubblicato questo Faccio fatica con gli stessi problemi, trovo il tuo post e rispondo incredibilmente utile. Alla fine ho deciso che Laravel non fornisce una buona architettura per tutto ciò che va oltre un sito Web Ruby-on-Rails veloce e sporco. Trates ovunque, difficoltà a trovare funzioni di classe e tonnellate di immondizia auto-magica ovunque. ORM non ha mai funzionato e se lo stai usando, dovresti probabilmente usare NoSQL.
Alex Barker,

Risposte:


171

Penso che tutti i modelli / architetture che presenti siano molto utili se segui il SOLID principi .

Per dove aggiungere la logica, penso che sia importante fare riferimento al principio della responsabilità singola . Inoltre, la mia risposta considera che stai lavorando a un progetto medio / grande. Se si tratta di un progetto di lancio di qualcosa sulla pagina , dimentica questa risposta e aggiungi tutto a controller o modelli.

La risposta breve è: dove ha senso per te (con i servizi) .

La lunga risposta:

Controller : qual è la responsabilità dei controller? Certo, puoi mettere tutta la tua logica in un controller, ma è responsabilità del controller? Io non la penso così.

Per me, il controller deve ricevere una richiesta e restituire i dati e questo non è il posto dove mettere le convalide, chiamare i metodi db, ecc.

Modelli : è un buon posto per aggiungere logica come l'invio di un'e-mail di benvenuto quando un utente si registra o aggiorna il conteggio dei voti di un post? Cosa succede se è necessario inviare la stessa e-mail da un'altra posizione nel codice? Crei un metodo statico? Cosa succede se quelle e-mail richiedono informazioni da un altro modello?

Penso che il modello dovrebbe rappresentare un'entità. Con laravel, io uso solo la classe del modello di aggiungere cose come fillable, guarded, tablee le relazioni (questo è perché io uso il Pattern Repository, altrimenti il modello avrebbe anche il save, update, findmetodi, ecc).

Repository (Repository Pattern) : All'inizio ero molto confuso da questo. E, come te, ho pensato "bene, io uso MySQL e questo è tutto".

Tuttavia, ho bilanciato i pro contro i contro dell'uso del pattern repository e ora lo uso. Penso che ora , in questo preciso istante, avrò solo bisogno di usare MySQL. Ma, se tra tre anni avrò bisogno di passare a qualcosa come MongoDB, la maggior parte del lavoro sarà fatta. Tutto a scapito di un'interfaccia aggiuntiva e a $app->bind(«interface», «repository»).

Eventi ( modello osservatore ): gli eventi sono utili per cose che possono essere lanciate in qualsiasi classe in qualsiasi momento. Pensa, ad esempio, all'invio di notifiche a un utente. Quando necessario, si attiva l'evento per inviare una notifica a qualsiasi classe dell'applicazione. Quindi, puoi avere una classe come UserNotificationEventsquella che gestisce tutti gli eventi generati per le notifiche degli utenti.

Servizi : fino ad ora, puoi scegliere di aggiungere logica a controller o modelli. Per me ha senso aggiungere la logica in Servizi . Ammettiamolo, Servizi è un nome di fantasia per le classi. E puoi avere tutte le classi che ha senso per te nella tua domanda.

Prendi questo esempio: poco fa ho sviluppato qualcosa come i moduli di Google. Ho iniziato con un CustomFormServicee finito con CustomFormService, CustomFormRender, CustomFieldService, CustomFieldRender, CustomAnswerServicee CustomAnswerRender. Perché? Perché aveva senso per me. Se lavori con una squadra, dovresti mettere la tua logica dove ha senso per la squadra.

Il vantaggio di utilizzare i servizi rispetto ai controller / modelli è che non si è vincolati da un singolo controller o da un singolo modello. Puoi creare tutti i servizi necessari in base al design e alle esigenze della tua applicazione. Aggiungete a ciò il vantaggio di chiamare un servizio all'interno di qualsiasi classe della vostra applicazione.

Questo dura molto, ma vorrei mostrarti come ho strutturato la mia applicazione:

app/
    controllers/
    MyCompany/
        Composers/
        Exceptions/
        Models/
        Observers/
        Sanitizers/
        ServiceProviders/
        Services/
        Validators/
    views
    (...)

Uso ogni cartella per una funzione specifica. Ad esempio, la Validatorsdirectory contiene una BaseValidatorclasse responsabile dell'elaborazione della convalida, basata su $rulese $messagesdi validatori specifici (di solito una per ciascun modello). Potrei facilmente inserire questo codice all'interno di un servizio, ma per me ha senso avere una cartella specifica per questo anche se viene utilizzato solo all'interno del servizio (per ora).

Ti consiglio di leggere i seguenti articoli, in quanto potrebbero spiegarti un po 'meglio le cose:

Breaking the Mold di Dayle Rees (autore di CodeBright): è qui che ho messo tutto insieme, anche se ho cambiato alcune cose per soddisfare le mie esigenze.

Disaccoppiamento del codice in Laravel mediante i repository e i servizi di Chris Goosey: questo post spiega bene cos'è un servizio e il modello di repository e come si integrano.

I Laracasts hanno anche i repository semplificati e la responsabilità singola che sono buone risorse con esempi pratici (anche se devi pagare).


3
ottima spiegazione. Ecco un po 'dove mi trovo al momento - nel progetto attuale sto mettendo la mia logica di business in modelli e in realtà funziona molto bene. Abbiamo sicuramente bisogno di confondere un po 'SOLID, ma non ci ha ancora messo nei guai. È veloce, è un po 'sporco, ma finora il nostro progetto è molto mantenibile perché è così ASCIUTTO. Sto decisamente bene attenendomi a loro al momento perché fanno il loro lavoro, ma in qualsiasi progetto futuro probabilmente andrò con qualsiasi cosa sia standard, che sembra che i repository siano diventati.
Sabrina Leggett,

2
Sono contento che tu abbia trovato un modo per te sensato. Fai solo attenzione alle ipotesi che fai oggi . Ho lavorato su un progetto per 3+ anni e ho finito con controller e modelli con oltre 5000 righe di codice. Buona fortuna con il vostro progetto.
Luís Cruz,

anche un po 'sporco ma stavo pensando di usare i tratti per evitare che i modelli diventassero enormi. In questo modo posso separarli un po '
Sabrina Leggett,

Questo articolo si articola bene QUANDO ha senso usare i servizi. Nel tuo esempio di Modulo ha senso usare i servizi, ma spiega come lo fa, cioè quando la logica è direttamente correlata a un modello, la inserisce in quel modello. justinweiss.com/articles/where-do-you-put-your-code
Sabrina Leggett

Mi piace molto la spiegazione. Ho una domanda che ho: hai detto di non mettere la validazione nel controller, quindi dove pensi sia il posto migliore per fare la validazione? Molti suggeriscono di inserirlo nella classe Request estesa (e anche in quello che facciamo attualmente), ma cosa succede se non voglio solo convalidare su richiesta http, ma anche su comando artigianale, ecc., È davvero un buon posto?
Kingshark,

24

Volevo inviare una risposta alla mia domanda. Potrei parlarne per giorni, ma cercherò di pubblicarlo velocemente per essere sicuro di risolverlo.

Ho finito per utilizzare la struttura esistente fornita da Laravel, il che significa che ho conservato i miei file principalmente come Modello, Vista e Controller. Ho anche una cartella Librerie per componenti riutilizzabili che non sono in realtà modelli.

NON HO FATTO I MIEI MODELLI IN SERVIZI / BIBLIOTECHE . Tutti i motivi forniti non mi hanno convinto al 100% del vantaggio derivante dall'utilizzo dei servizi. Anche se potrei sbagliarmi, per quanto posso vedere, si traducono in tonnellate di file extra quasi vuoti che devo creare e alternare quando lavoro con i modelli e ridurre anche il vantaggio dell'uso eloquente (specialmente quando si tratta di RECUPERARE i modelli , ad es. usando impaginazione, ambiti, ecc.).

Metto la logica di business nei MODELLI e accedo eloquente direttamente dai miei controller. Uso una serie di approcci per assicurarmi che la logica aziendale non venga ignorata:

  • Accessori e mutatori: Laravel ha ottimi accessori e mutatori. Se voglio eseguire un'azione ogni volta che un post viene spostato dalla bozza alla pubblicazione, posso chiamarlo creando set di funzioniIsPublishedAttribute e includendo la logica lì dentro
  • Sostituzione di Crea / Aggiorna ecc.: Puoi sempre sostituire i metodi eloquenti nei tuoi modelli per includere funzionalità personalizzate. In questo modo puoi chiamare la funzionalità su qualsiasi operazione CRUD. Modifica: penso che ci sia un bug con l'override create nelle nuove versioni di Laravel (quindi uso gli eventi ora registrati all'avvio)
  • Convalida: aggancio la mia convalida allo stesso modo, ad es. Eseguirò la convalida sovrascrivendo le funzioni CRUD e anche gli accessori / i mutatori, se necessario. Vedi Esensi o dwightwatson / validating per maggiori informazioni.
  • Metodi magici: utilizzo i metodi __get e __set dei miei modelli per agganciarmi alla funzionalità dove appropriato
  • Estensione di eloquente: se esiste un'azione che desideri intraprendere su tutti gli aggiornamenti / crea, puoi persino estendere eloquente e applicarlo a più modelli.
  • Eventi: questo è un posto semplice e generalmente concordato per fare anche questo. Il più grande svantaggio degli eventi penso sia che le eccezioni siano difficili da rintracciare (potrebbe non essere il nuovo caso con il nuovo sistema di eventi di Laravel). Mi piace anche raggruppare i miei eventi in base a ciò che fanno anziché quando vengono chiamati ... ad esempio, avere un abbonato MailSender che ascolta gli eventi che inviano posta.
  • Aggiunta di eventi Pivot / BelongsToMany: una delle cose con cui ho lottato più a lungo è stato il modo di associare il comportamento alla modifica delle relazioni appartiene a molti. Ad esempio, eseguendo un'azione ogni volta che un utente si unisce a un gruppo. Ho quasi finito di lucidare una libreria personalizzata per questo. Non l'ho ancora pubblicato ma è funzionale! Proverò a pubblicare un link presto. EDIT Ho finito per trasformare tutti i miei perni in modelli normali e la mia vita è stata molto più semplice ...

Affrontare le preoccupazioni delle persone con l'uso dei modelli:

  • Organizzazione: Sì, se includi più logica nei modelli, possono essere più lunghi, ma in generale ho scoperto che il 75% dei miei modelli è ancora piuttosto piccolo. Se ho scelto di organizzare quelli più grandi, posso farlo usando i tratti (ad esempio, creare una cartella per il modello con alcuni altri file come PostScopes, PostAccessors, PostValidation, ecc., Se necessario). So che questo non è necessariamente ciò che serve ai tratti, ma questo sistema funziona senza problemi.

Nota aggiuntiva: mi sento come avvolgere i tuoi modelli nei servizi è come avere un coltellino svizzero, con molti strumenti e costruirvi un altro coltello che praticamente fa la stessa cosa? Sì, a volte potresti voler isolare una lama o assicurarti che due lame siano usate insieme ... ma in genere ci sono altri modi per farlo ...

QUANDO USARE I SERVIZI : Questo articolo illustra molto bene GRANDI esempi su quando utilizzare i servizi ( suggerimento: non è molto frequente ). Dice fondamentalmente che quando il tuo oggetto usa più modelli o modelli in strane parti del loro ciclo di vita ha senso. http://www.justinweiss.com/articles/where-do-you-put-your-code/


2
Pensieri interessanti e validi. Ma sono curioso: come testate la vostra logica aziendale se è legata a modelli collegati a Eloquent, che è legata al database?
JustAMartin,

code.tutsplus.com/tutorials/… oppure puoi usare eventi come ho detto se vuoi approfondire ulteriormente
Sabrina Leggett

1
@JustAMartin sei sicuro di non poter usare solo il database nei test unitari? Qual è la ragione per non farlo? Molte persone concordano sul fatto che spesso va bene usare il database nei test unitari. (incluso Martin Fowler, martinfowler.com/bliki/UnitTest.html : "Non considero l'uso dei doppi per risorse esterne come una regola assoluta. Se parlare con la risorsa è abbastanza stabile e abbastanza veloce per te, non c'è motivo di non farlo nei test unitari ")
Alex P.

@ AlexP11223 Sì, ha senso. Ho cercato di integrare SQLite come database di test e, in generale, è andato bene, sebbene SQLite abbia alcune serie limitazioni che devono essere prese in considerazione nelle migrazioni di Laravel e nelle query personalizzate (se presenti). Naturalmente, quelli non sono rigorosamente test unitari ma test funzionali, ma è ancora più efficiente in questo modo. Tuttavia, se si desidera testare il proprio modello in completo isolamento (come test unitario rigoroso), potrebbe richiedere una notevole quantità di codice aggiuntivo (simulazioni, ecc.).
JustAMartin,

22

Quello che utilizzo per creare la logica tra controller e modelli è creare un livello di servizio . Fondamentalmente, questo è il mio flusso per qualsiasi azione all'interno della mia app:

  1. Il controller ottiene l'azione richiesta dall'utente, invia parametri e delega tutto a una classe di servizio.
  2. La classe di servizio esegue tutta la logica correlata all'operazione: convalida dell'input, registrazione degli eventi, operazioni del database, ecc ...
  3. Il modello contiene informazioni su campi, trasformazione dei dati e definizioni delle convalide degli attributi.

Ecco come lo faccio:

Questo è il metodo di un controller per creare qualcosa:

public function processCreateCongregation()
{
    // Get input data.
    $congregation                 = new Congregation;
    $congregation->name           = Input::get('name');
    $congregation->address        = Input::get('address');
    $congregation->pm_day_of_week = Input::get('pm_day_of_week');
    $pmHours                      = Input::get('pm_datetime_hours');
    $pmMinutes                    = Input::get('pm_datetime_minutes');
    $congregation->pm_datetime    = Carbon::createFromTime($pmHours, $pmMinutes, 0);

    // Delegates actual operation to service.
    try
    {
        CongregationService::createCongregation($congregation);
        $this->success(trans('messages.congregationCreated'));
        return Redirect::route('congregations.list');
    }
    catch (ValidationException $e)
    {
        // Catch validation errors thrown by service operation.
        return Redirect::route('congregations.create')
            ->withInput(Input::all())
            ->withErrors($e->getValidator());
    }
    catch (Exception $e)
    {
        // Catch any unexpected exception.
        return $this->unexpected($e);
    }
}

Questa è la classe di servizio che esegue la logica correlata all'operazione:

public static function createCongregation(Congregation $congregation)
{
    // Log the operation.
    Log::info('Create congregation.', compact('congregation'));

    // Validate data.
    $validator = $congregation->getValidator();

    if ($validator->fails())
    {
        throw new ValidationException($validator);
    }

    // Save to the database.
    $congregation->created_by = Auth::user()->id;
    $congregation->updated_by = Auth::user()->id;

    $congregation->save();
}

E questo è il mio modello:

class Congregation extends Eloquent
{
    protected $table = 'congregations';

    public function getValidator()
    {
        $data = array(
            'name' => $this->name,
            'address' => $this->address,
            'pm_day_of_week' => $this->pm_day_of_week,
            'pm_datetime' => $this->pm_datetime,
        );

        $rules = array(
            'name' => ['required', 'unique:congregations'],
            'address' => ['required'],
            'pm_day_of_week' => ['required', 'integer', 'between:0,6'],
            'pm_datetime' => ['required', 'regex:/([01]?[0-9]|2[0-3]):[0-5]?[0-9]:[0-5][0-9]/'],
        );

        return Validator::make($data, $rules);
    }

    public function getDates()
    {
        return array_merge_recursive(parent::getDates(), array(
            'pm_datetime',
            'cbs_datetime',
        ));
    }
}

Per ulteriori informazioni su questo modo utilizzo per organizzare il mio codice per un'app Laravel: https://github.com/rmariuzzo/Pitimi


Sembra che i servizi siano quelli che ho definito librerie nel mio post. Penso che sia meglio dei repository se non hai bisogno di usare più ORMS, ma il problema è che devi migrare l'intero progetto (che non hai a che fare con gli eventi), e sembra in un certo senso finisce per rispecchiare la struttura del Modello in modo da avere tutti questi file extra. Perché non includerlo nei modelli? Almeno in questo modo non hai i file extra.
Sabrina Leggett,

Questa è una domanda interessante @SabrinaGelbart, mi è stato insegnato a lasciare che i modelli rappresentino le entità del database e non mantenere alcuna logica. Questo è il motivo per cui ho creato quei file extra chiamati servizi: per contenere tutta la logica e tutte le operazioni extra. Non sono sicuro di quale sia il significato completo degli eventi descritti in precedenza, ma penso che con i servizi e utilizzando gli eventi di Laravel possiamo creare tutti i metodi di servizi per generare eventi all'inizio e alla fine. In questo modo qualsiasi evento può essere completamente separato dalla logica. Cosa ne pensi?
Rubens Mariuzzo,

Mi è stato insegnato che anche sui modelli ... sarebbe bello avere una buona spiegazione del perché (forse problemi di dipendenza)?
Sabrina Leggett,

Mi piace questo approccio! Ho cercato su Internet per farmi un'idea di come dovrei gestire la logica del modello, ho esaminato i repository ma sembrava troppo complicato e inutile per un po 'di utilizzo. I servizi sono una buona idea. La mia domanda è dopo aver creato una cartella di servizi nella cartella dell'app, devi includerla in bootstrap / start.php o in qualsiasi altro punto per l'avvio perché ho guardato oltre il tuo git non riesci a trovarlo? @RubensMariuzzo. Diventa automaticamente disponibile attraverso l'app? così possiamo semplicemente usare CongregationService :: getCongregations (); ??
Oguzhan,

1
Se tutto ciò che stai facendo è un $congregation->save();allora forse non avresti bisogno dei repository. Tuttavia, è possibile che le esigenze di accesso ai dati aumentino nel tempo. Potresti iniziare ad avere necessità per $congregation->destroyByUser()o $congregationUsers->findByName($arrayOfSelectedFields);così via. Perché non disaccoppiare i servizi dalle esigenze di accesso ai dati. Lascia che il resto della tua app funzioni con oggetti / array restituiti dai repository e gestisci semplicemente manipolazione / formattazione / ecc ... I tuoi repository cresceranno (ma li divideranno in file diversi, alla fine la complessità di un progetto deve risiedere da qualche parte).
prograhammer

12

Secondo me, Laravel ha già molte opzioni per archiviare la tua logica aziendale.

Risposta breve:

  • Utilizzare gli Requestoggetti laravel per convalidare automaticamente l'input, quindi conservare i dati nella richiesta (creare il modello). Poiché tutti gli input degli utenti sono direttamente disponibili nella richiesta, credo che sia logico eseguire questa operazione qui.
  • Utilizzare gli Joboggetti laravel per eseguire attività che richiedono singoli componenti, quindi semplicemente inviarli. Penso che Jobincludano le classi di servizio. Eseguono un'attività, come la logica aziendale.

Risposta lunga (er):

Usa repository quando richiesto: i repository sono destinati a essere sovraesposti e, il più delle volte, vengono semplicemente utilizzati come accessormodello per il modello. Sento che hanno sicuramente un certo uso, ma a meno che tu non stia sviluppando una massiccia applicazione che richiede quella quantità di flessibilità per poter abbandonare del tutto il laravel, stare lontano dai repository. Ti ringrazierai più tardi e il tuo codice sarà molto più semplice.

Chiediti se c'è la possibilità che stai per modificare i framework PHP o un tipo di database che laravel non supporta.

Se la tua risposta è "Probabilmente no", non implementare il modello di repository.

Oltre a quanto sopra, per favore non schiaffeggiare uno schema sopra un superbo ORM come Eloquent. Stai solo aggiungendo complessità che non è richiesta e non ti gioverà affatto.

Utilizza i servizi con parsimonia: le classi di servizio per me sono solo un luogo in cui archiviare la logica aziendale per eseguire un'attività specifica con le relative dipendenze. Laravel li ha pronti all'uso, chiamati 'Jobs', e hanno molta più flessibilità di una classe di servizio personalizzata.

Sento che Laravel ha una soluzione completa per il MVCproblema logico. È solo una questione o organizzazione.

Esempio:

Richiesta :

namespace App\Http\Requests;

use App\Post;
use App\Jobs\PostNotifier;
use App\Events\PostWasCreated;
use App\Http\Requests\Request;

class PostRequest extends Request
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'title'       => 'required',
            'description' => 'required'
        ];
    }

    /**
     * Save the post.
     *
     * @param Post $post
     *
     * @return bool
     */
    public function persist(Post $post)
    {
        if (!$post->exists) {
            // If the post doesn't exist, we'll assign the
            // post as created by the current user.
            $post->user_id = auth()->id();
        }

        $post->title = $this->title;
        $post->description = $this->description;

        // Perform other tasks, maybe fire an event, dispatch a job.

        if ($post->save()) {
            // Maybe we'll fire an event here that we can catch somewhere else that
            // needs to know when a post was created.
            event(new PostWasCreated($post));

            // Maybe we'll notify some users of the new post as well.
            dispatch(new PostNotifier($post));

            return true;
        }

        return false;
    }
}

Controller :

namespace App\Http\Controllers;

use App\Post;
use App\Http\Requests\PostRequest;

class PostController extends Controller
{

   /**
    * Creates a new post.
    *
    * @return string
    */
    public function store(PostRequest $request)
    {
        if ($request->persist(new Post())) {
            flash()->success('Successfully created new post!');
        } else {
            flash()->error('There was an issue creating a post. Please try again.');
        }

        return redirect()->back();
    }

   /**
    * Updates a post.
    *
    * @return string
    */
    public function update(PostRequest $request, $id)
    {
        $post = Post::findOrFail($id);

        if ($request->persist($post)) {
            flash()->success('Successfully updated post!');
        } else {
            flash()->error('There was an issue updating this post. Please try again.');
        }

        return redirect()->back();
    }
}

Nell'esempio precedente, l'input della richiesta viene automaticamente convalidato e tutto ciò che dobbiamo fare è chiamare il metodo persist e passare un nuovo post. Penso che la leggibilità e la manutenibilità debbano sempre superare modelli di progettazione complessi e non necessari.

È quindi possibile utilizzare lo stesso metodo persistente anche per l'aggiornamento dei post, poiché possiamo verificare se il post esiste già ed eseguire la logica alternata quando necessario.


ma - i lavori "supposti" non devono essere messi in coda? A volte probabilmente vogliamo che sia in coda, ma non sempre. Perché non usare i comandi invece? Cosa succede se si desidera scrivere una logica aziendale che può essere eseguita come comando o evento o in coda?
Sabrina Leggett,

1
I lavori non devono essere messi in coda. Lo si specifica implementando l'interfaccia sul lavoro ShouldQueuefornito da Laravel. Se si desidera scrivere la logica aziendale in un comando o evento, eseguire semplicemente il lavoro all'interno di tali eventi / comandi. I lavori di Laravels sono estremamente flessibili, ma alla fine sono solo semplici classi di servizio.
Steve Bauman,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.