Разве плохо использовать публичную статическую функцию в контроллерах laravel?
В моей модели продукта у меня есть функция, которая выглядит следующим образом:
public static function setEndDate($time)
{
if ($time == 2)
{
return Carbon::now()->addMonths(2)->toDateTimeString();
}
else
{
return Carbon::now()->addDays($time)->toDateTimeString();
}
}
И тогда в моем контроллере я использую эту функцию следующим образом:
//Validation etc..
$time = Input::get('end_date'); //To transform end-time
$newProduct = new Product();
$newProduct->some_value = Input::get('some_value');
$newProduct->some_value = Input::get('some_value');$newProduct->end_date = Product::setEndDate($time); //Using my static function like thisnewProduct->save();
Разве плохо использовать статические функции, как указано выше?
Вопрос сам по себе довольно основанный на мнении. Я не скажу, что в вашей модели обязательно есть такие методы, хотя я также не рекомендую делать это. (Для получения дополнительной информации об этом проверьте @ Колин Шон ответ)
В любом случае, Eloquent предлагает более подходящее решение для вашей конкретной проблемы: Мутаторы!
Это своего рода «методы установки», в которых вы можете изменить или мутировать значение, которое будет присвоено свойству. Вот пример:
public function setEndDateAttribute($time){
if ($time == 2)
{
$this->attributes['end_date'] = Carbon::now()->addMonths(2)->toDateTimeString();
}
else
{
$this->attributes['end_date'] = Carbon::now()->addDays($time)->toDateTimeString();
}
}
И вы используете это так:
$newProduct->end_date = $time;
Нет ничего, что по своей природе сломалось бы при создании статических методов, но, как и во всей документации, это не рекомендуется. Зачем?
Статическое состояние вездесуще и полностью разрушает тестируемость, так как вы не можете просто сбросить состояние. Кроме того, все может повлиять на состояние таким образом, что другие аспекты кода не могут предсказать, что может привести к непредсказуемому поведению.
Laravel 4 предотвращает это, используя статичные «фасады». Эти фасады являются «синтаксическим сокращением для разрешения IoC». Они обеспечивают как синтаксический сахар, так и предотвращают тесно связанный код.
Классы, которые разрешены фасадами, могут быть изменены и позволяют вам вводить макет системы или что угодно.