MVC (Laravel), де додати логіку

Скажімо, щоразу, коли я роблю операцію CRUD або змінюю відносини певним чином, я також хочу зробити щось інше. Наприклад, щоразу, коли хтось публікує публікацію, я також хочу щось зберегти в таблиці для аналізу. Можливо, не найкращий приклад, але в цілому є багато цього "згрупованого" функціоналу.

Зазвичай я бачу такий тип логіки, що передається в контролери. Це все чудово, як денді, поки ви не захочете відтворити цю функціональність у багатьох місцях. Коли ви починаєте вступати в партії, створюючи API та генеруючи фіктивний вміст, це стає проблемою із збереженням ДУХОМ

Я бачив способи управління цим подіями, сховищами, бібліотеками та додаванням до моделей. Ось моє розуміння кожного:

Послуги: саме тут, мабуть, більшість людей поставили цей код. Моя головна проблема сервісів полягає в тому, що іноді важко знайти в них конкретну функціональність, і я відчуваю, що про них забувають, коли люди зосереджені на використанні красномовства. Як я можу знати, що мені потрібно викликати метод publishPost()у бібліотеці, коли я просто можу це зробити $post->is_published = 1?

Єдиною умовою, за якою я добре працюю, є те, що ви ТИЛЬКО використовуєте сервіси (і в ідеалі робите красномовний доступним якось з контролерів разом).

Зрештою, здається, що це просто створить купу зайвих непотрібних файлів, якщо ваші запити, як правило, відповідають вашій структурі моделі.

Сховища: з того, що я розумію, це в основному як сервіс, але є інтерфейс, щоб ви могли перемикатися між ORM, які мені не потрібні.

Події: Я вважаю це найелегантнішою системою в певному сенсі, тому що ви знаєте, що події вашої моделі завжди називатимуться красномовними методами, тому ви можете записувати свої контролери так, як зазвичай. Я бачу, як вони стають безладними, і якщо хтось має приклади великих проектів, що використовують події для критичного зв'язку, я б хотів це побачити.

Моделі: Традиційно в мене були б класи, які виконували CRUD, а також обробляли критичні зв'язки. Це насправді полегшило роботу, оскільки ви знали всю функціональність навколо CRUD + все, що потрібно було зробити з нею.

Просто, але в архітектурі MVC це, як правило, не те, що я вважаю зробленим. У певному сенсі я віддаю перевагу цьому над сервісами, оскільки їх трохи простіше знайти, і файлів менше, щоб їх слідкувати. Хоча це може бути дезорганізовано. Я хотів би почути недоліки цього методу, і чому більшість людей, схоже, не роблять цього.

Які переваги / недоліки кожного методу? Я щось пропускаю?

Я думаю, що всі представлені вами структури / архітектури є дуже корисними, дотримуючись принципів SOLID .

Для того, де додати логіку, я думаю, що важливо звернутися до Єдиного принципу відповідальності . Також моя відповідь вважає, що ви працюєте над середнім / великим проектом. Якщо це проект « щось на сторінку », забудьте цю відповідь і додайте все до контролерів чи моделей.

Коротка відповідь: Де це має сенс для вас (з послугами) .

Довга відповідь:

Контролери : Яка відповідальність контролерів? Звичайно, ви можете помістити всю свою логіку в контролер, але це відповідальність контролера? Я не думаю, що так.

Для мене контролер повинен отримати запит і повернути дані, і це не місце для встановлення перевірок, виклику методів db тощо.

Моделі : це хороше місце, щоб додати логіку, як надіслати привітання електронною поштою, коли користувач зареєструє або оновить підрахунок голосів публікації? Що робити, якщо вам потрібно надіслати той самий електронний лист з іншого місця вашого коду? Чи створюєте ви статичний метод? Що робити, якщо ці електронні листи потребують інформації іншої моделі?

Я думаю, що модель повинна представляти сутність. З Laravel, я використовую тільки клас моделі , щоб додати такі речі , як fillable, guarded, tableі відносини (це тому , що я використовую Repository Pattern, в іншому випадку модель буде також мати save, update, find, і т.д. методи).

Сховища (шаблон сховища) : На початку мене це дуже збентежило. І, як і ви, я подумав, "добре, я використовую MySQL і це все".

Однак я збалансував плюси та мінуси використання шаблону репозиторію, і тепер я його використовую. Я думаю, що зараз , саме в цей момент, мені потрібно буде лише використовувати MySQL. Але, якщо через три роки мені потрібно змінити щось на зразок MongoDB, більшість робіт зроблено. Все за рахунок додаткового інтерфейсу та a $app->bind(«interface», «repository»).

Події ( шаблон спостерігача ): події корисні для речей, які можна кинути в будь-який клас у будь-який час. Подумайте, наприклад, про надсилання сповіщень користувачеві. Коли вам потрібно, ви запускаєте подію, щоб надіслати повідомлення в будь-який клас вашої заявки. Тоді ви можете мати такий клас, UserNotificationEventsякий обробляє всі ваші звільнені події для сповіщень користувачів.

Послуги : Дотепер у вас є вибір додати логіку до контролерів або моделей. Для мене є сенс додати логіку до Сервісів . Подивимося, Служби - це фантазія для занять. І ви можете мати стільки занять, скільки це має сенс для вас в рамках вашої заяви.

Візьмемо цей приклад. Нещодавно я розробив щось на кшталт Google Forms. Я почав з CustomFormServiceі в кінцевому підсумку з CustomFormService, CustomFormRender, CustomFieldService, CustomFieldRender, CustomAnswerServiceі CustomAnswerRender. Чому? Бо це мало сенс для мене. Якщо ви працюєте з командою, ви повинні поставити свою логіку там, де це має сенс для команди.

Перевага використання сервісів проти контролерів / моделей полягає в тому, що вас не обмежує один контролер або одна модель. Ви можете створити стільки сервісів, скільки потрібно, спираючись на дизайн та потреби вашої програми. Додайте до цього перевагу виклику Служби в будь-якому класі вашої заявки.

Це триває багато часу, але я хотів би показати вам, як я структурував свою програму:

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

Я використовую кожну папку для певної функції. Наприклад, Validatorsкаталог містить BaseValidatorклас , відповідальний за обробку перевірки, на основі $rulesі $messagesконкретних валідатори (зазвичай по одному для кожної моделі). Я міг би так само легко ввести цей код у Сервісі, але для мене є сенс мати певну папку для цього, навіть якщо він використовується лише в межах сервісу (поки що).

Я рекомендую вам прочитати наступні статті, оскільки вони можуть вам трохи краще пояснити:

Розбиття цвілі від Дейлі Різа (автор CodeBright): саме тут я все це склав, хоча я змінив декілька речей, щоб відповідати моїм потребам.

Розв’язка коду в Laravel за допомогою репозиторіїв та служб від Chris Goosey: Цей пост добре пояснює, що таке сервіс та шаблон сховища та як вони поєднуються разом.

У Laracasts також є спрощена та одинарна відповідальність за сховищами, які є хорошими ресурсами з практичних прикладів (навіть якщо вам доведеться платити).

Я хотів опублікувати відповідь на власне запитання. Я міг би про це говорити цілими днями, але я спробую швидко опублікувати це повідомлення, щоб переконатися, що я отримав це.

Я в кінцевому рахунку використовував існуючу структуру, яку надає Laravel, це означає, що я зберігав свої файли насамперед як модель, перегляд та контролер. У мене також є папка «Бібліотеки» для багаторазових компонентів, які насправді не є моделями.

Я НЕ ПОВЕРНУвав МОЇ МОДЕЛІ В ПОСЛУГАХ / БІБЛІОТЕКАХ . Всі наведені причини не на 100% переконали мене в перевазі використання послуг. Хоча я можу помилятися, наскільки я бачу, що вони просто призводять до безлічі зайвих майже порожніх файлів, які мені потрібно створити і перемикатися між роботами з моделями, а також дійсно зменшують переваги використання красномовних (особливо якщо мова йде про РЕТРЕВІННІ моделі) , наприклад, використовуючи пагинацію, області застосування тощо).

Я вкладаю ділову логіку в МОДЕЛІ і красномовно звертаюся безпосередньо до своїх контролерів. Я використовую ряд підходів, щоб переконатися, що бізнес-логіка не обійде стороною:

• Аксесуари та мутатори: Laravel має чудові аксесуари та мутатори. Якщо я хочу виконати дію кожного разу, коли повідомлення переміщується з чернетки на опубліковану, я можу викликати це, створивши функцію setIsPublishedAttribute і включивши туди логіку
• Переосмислення створення / оновлення тощо: Ви завжди можете переосмислювати красномовні методи у своїх моделях, щоб включити власну функціональність. Таким чином ви можете зателефонувати за функціональністю для будь-якої операції CRUD. Редагувати: Я думаю, що в нових версіях Laravel є помилка з переосмисленням (тому я використовую події, зареєстровані в завантажувальній системі)
• Валідація: Я підключаю свою перевірку аналогічно, наприклад, я запускаю валідацію, переосмислюючи функції CRUD, а також при потребі аксесуарів / мутаторів. Додаткову інформацію див. У розділі Esensi або dwightwatson / validation.
• Чарівні методи: Я використовую методи __get і __set моїх моделей, щоб підключити функціонал, де це доречно
• Розширення красномовного: Якщо є якесь дію, яке ви хочете здійснити над усім оновленням / створенням, ви можете навіть розширити красномовно і застосувати його до кількох моделей.
• Події: Це прямий рух і, як правило, узгоджене місце для цього. Найбільшим недоліком подій, на мою думку, є те, що винятків важко відстежити (можливо, це не новий випадок із новою системою подій Laravel). Мені також подобається групувати свої події за тим, що вони роблять, а не коли вони викликаються ... наприклад, мають абонента MailSender, який слухає події, які надсилають пошту.
• Додавання зведених / належних подій ToMany: Однією з речей, з якими я боровся довше, було те, як прив’язати поведінку до модифікації відносин pripadaхToMany. Наприклад, виконуючи дію кожного разу, коли користувач приєднується до групи. Я майже закінчив шліфування спеціальної бібліотеки для цього. Я його ще не опублікував, але він функціональний! Спробуємо опублікувати посилання найближчим часом. EDIT Я в кінцевому підсумку зробив усі свої повороти в звичайні моделі, і моє життя було набагато простішим ...

Вирішення проблем людей із використанням моделей:

• Організація: Так, якщо ви включаєте більше логіки в моделі, вони можуть бути довшими, але загалом я виявив, що 75% моїх моделей все ще досить маленькі. Якщо я вирішив організувати більш великі, я можу це зробити за допомогою ознак (наприклад, створити папку для моделі з деякими іншими файлами, такими як PostScopes, PostAccessors, PostValidation тощо), якщо потрібно. Я знаю, що це не обов'язково, для чого є риси, але ця система працює без проблем.

Додаткова примітка: Я відчуваю, що загортати ваші моделі в послуги - це як мати швейцарський армійський ніж, з великою кількістю інструментів, а також створити навколо нього ще один ніж, який в основному робить те саме? Так, іноді вам може захотітися зняти лезо або переконатися, що два леза використовуються разом ... але зазвичай є інші способи зробити це ...

КОЛИ ВИКОРИСТОВУВАТИ ПОСЛУГИ : Ця стаття дуже добре подає ВЕЛИКІ приклади, коли користуватися послугами ( підказка: це не дуже часто ). Він каже, що в основному, коли ваш об'єкт використовує кілька моделей або моделей на дивних частинах їх життєвого циклу, це має сенс. http://www.justinweiss.com/articles/where-do-you-put-your-code/

Те, що я використовую для створення логіки між контролерами та моделями, - це створити сервісний рівень . В основному, це мій потік для будь-яких дій у моєму додатку:

1. Контролер отримує запитувані дії користувача та надсилає параметри та делегує все службовому класу.
2. Клас обслуговування виконує всю логіку, пов'язану з операцією: перевірка вводу даних, реєстрація подій, операції з базою даних тощо ...
3. Модель містить інформацію про поля, перетворення даних та визначення перевірок атрибутів.

Ось як я це роблю:

Це метод контролера для створення чогось:

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);
    }
}

Це клас обслуговування, який виконує логіку, пов'язану з операцією:

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();
}

І це моя модель:

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',
        ));
    }
}

Для отримання додаткової інформації про цей спосіб я використовую для організації свого коду для програми Laravel: https://github.com/rmariuzzo/Pitimi

На мою думку, у Laravel вже є багато варіантів для зберігання вашої бізнес-логіки.

Коротка відповідь:

• Використовуйте Requestоб'єкти laravel для автоматичної перевірки ваших даних, а потім зберігайте дані у запиті (створіть модель). Оскільки всі дані користувачів є безпосередньо доступними у запиті, я вважаю, що це має сенс виконати тут.
• Використовуйте Jobоб'єкти laravel для виконання завдань, які потребують окремих компонентів, а потім просто відправте їх. Я думаю Job, що охоплюють сервісні класи. Вони виконують завдання, такі як бізнес-логіка.

Довга відповідь:

Використовуйте сховища, коли потрібно: сховища повинні бути переблоковані, і більшість часу просто використовуються як accessorмодель для моделі. Я відчуваю, що вони, безумовно, мають певне використання, але якщо ви не розробляєте масштабну програму, яка потребує такої гнучкості, щоб ви змогли повністю відкинути laravel, тримайтеся подалі від сховищ. Пізніше ви подякуєте собі, і ваш код буде набагато прямо вперед.

Запитайте себе, чи є можливість, щоб ви змінили рамки PHP або тип бази даних, який laravel не підтримує.

Якщо ваша відповідь - "Мабуть, ні", тоді не застосовуйте схему сховища.

На додаток до вище, будь ласка, не ляпайте візерунком поверх чудового ORM типу Красномовний. Ви просто додаєте складності, які не потрібні, і це вам не принесе користі.

Економно використовуйте Послуги: Класи обслуговування для мене - це лише місце для зберігання бізнес-логіки для виконання конкретного завдання з урахуванням його залежностей. У Laravel вони є поза межами вікна, які називаються "Робота", і вони мають набагато більшу гнучкість, ніж спеціальний клас обслуговування.

Я відчуваю, що у Ларавеля є чітко вирішене MVCлогічне завдання. Це просто питання чи організація.

Приклад:

Запит :

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;
    }
}

Контролер :

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();
    }
}

У наведеному вище прикладі введення запиту автоматично перевіряється, і все, що нам потрібно зробити, - це зателефонувати за методом зберігання та передати нову публікацію. Я думаю, що читабельність та ремонтопридатність завжди повинні створювати складні та непотрібні моделі дизайну.

Потім ви можете використовувати той самий постійний метод також для оновлення дописів, оскільки ми можемо перевірити, чи існує публікація чи ні, і виконувати чергування логіки при необхідності.