Должна ли логика обработки STRIPE быть в контроллере Laravel или в валидаторе?
Я новичок в laravel. У меня есть такой контроллер ProductController
public function buy(Request $request, User $user) {
\Stripe\Stripe::setApiKey("sk_test_xxxxxxxxxxxxxxxxxxxxxxxx");
$token = $_POST['stripeToken'];
$charge = \Stripe\Charge::create([
'amount' => 100,
'currency' => 'aud',
'description' => 'Example charge',
'source' => $token,
]);
if ($charge->status === "succeeded") {
//-- Processing... --//
}
Я хотел бы спросить, какой стиль дизайна более подходящий, можно ли поместить часть STTRIE в другие места, например, в валидатор. Если да, то сделать правило и запрос, чем проверять в валидаторе?
Может кто подскажет, как использовать правило в запросе?
вы проверяете полосу $charge или ваш $request?
Ответы 2
Создание начисления Stripe не является запросом проверки. Это API-вызов Stripe. Таким образом, он определенно не должен оставаться в валидаторе.
У вас может быть эта логика в контроллере для небольших приложений, но для средних / крупных приложений с абстракцией (например, если вы хотите иметь возможность позже изменить поставщика платежей с Stripe на Braintree), она должна быть в классе обслуживания. .
Кроме того, никогда не используйте $_POST напрямую. Вместо этого используйте $request->input. Как правило, если у вас есть 2 способа сделать что-то в коде, всегда используйте способ, реализующий библиотеки более высокого уровня (библиотеки> затем фреймворк> затем ядро PHP).
Чтобы написать валидацию с помощью Laravel 5.5+
public function buy(Request $request, User $user)
{
// first define your rules
$rules = [
'amount' => 'required|numeric'
];
$validatedData = $request->validate($rules);
// The purchase is valid...
}
Для Laravel 5.0 - 5.4:
public function buy(Request $request, User $user)
{
// first define your rules
$rules = [
'amount' => 'required|numeric'
];
$validatedData = $this->validate($rules);
// The purchase is valid...
}
На мой взгляд, типичные обязанности контролера:
- Принять заявку
- Вернуть ответ
Я думаю, что, вероятно, будет хорошо иметь одну условную или проверочную проверку.
Спасибо @adam. Я предпочитаю разделить логику по разным местам, чтобы контроллер не выглядел слишком запутанным. Первоначально я думал, что настрою правило STRIPE, а затем использую его в запросе laravel.
Скорее всего, ни одно из этих мест не является лучшим местом для этого. Бизнес-логика должна жить в моделях или классах обслуживания.