MVC (Laravel) dove aggiungere la logica

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?

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).

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/

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

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.