"Oszczędzaj kod w kontrolerach, kosztem modeli" - to raczej nie jest GoodPractice...

[PrzemekTkaczyk]

Od tego są np repozytoria. Później się widzi ogromne klasy Modeli..

[DominikStyp]

No niestety sporo złych porad:

• "Komentuj swój kod wszędzie" totalnie niezgodne z Martinem, na którego się powołujesz (twórca zasad SOLID), który wręcz twierdzi że nie należy komentować, a zamiast tego tworzyć metody które same opisują się nazwą
• wszystkie metody typu public w przykładach to też bardzo zła praktyka, publiczne powinny być tylko te co faktycznie są używane na zewn. klasy
• "Używaj krótszej oraz czytelniejszej składni wszędzie gdzie to możliwe" to też nie zawsze jest dobre, dla przykładu to:

is_null($object->relation) ? null : $object->relation->id  |  optional($object->relation)->id

nie jest null-safe, i lepiej użyć dłuższej ale bezpieczniejszej składni:

$object = (object)['something'];
// OK
$x = empty($object->relation) ? null : $object->relation->id;

// ERROR gdy ->relation nie jest ustawione
$y = optional($object->relation)->id;

• kreowanie atrybutów w modelu do formatowania czegokolwiek:

public function getSomeDateAttribute($date)
{
    return $date->format('m-d');
}

to raczej jest bez sensu bo właśnie łamie SOLID, jak już to lepiej zastosować zewn. klasę formatującą i przenieść tam logikę w postaci:

Carbon::createFromFormat('Y-d-m H-i', $object->ordered_at)->format('m-d')

niestety mam nieprzyjemność pracowania z takim legacy kodem gdzie developerzy szli na łatwiznę robiąc atrybuty do wszystkiego, czym się to kończy można się łatwo domyślić jak model nagle zaczyna mieć ponad 1000 linii kodu.

Reszta w zasadzie OK, choć jak patrzę na konkatenację zamiast interpolacji, to trochę mam niesmak i raczej bym nie podawał czegoś takiego jako przykład dobrej praktyki:

public function getFullNameLong()
{
    return 'Mr. ' . $this->first_name . ' ' . $this->middle_name . ' ' . $this->last_name;
}