Oliver Nybroe napisał pociąg request do Laravela (8.59.0), który pozwala programistom wymagać ustawienia map morph, zamiast domyślnego używania w pełni kwalifikowanych nazw klas.
Korzystając z metody enforceMorphMap zamiast tradycyjnej metody morphMap, Laravel zapewni, że wszystkie przemiany zostaną zmapowane do aliasu i zgłosi ClassMorphViolationException wyjątek, jeśli nie jest zmapowany.
// If any other models are morphed but not mapped, Laravel
// will throw a `ClassMorphViolationException` exception.
Relation::enforceMorphMap([
'user' => User::class,
]);Możesz wymusić mapowanie morph za pomocą pojedynczego wywołania pokazanego powyżej lub możesz użyć samodzielnej metody requireMorphMap w klasie Relation:
// Turn morph map enforcement on (new in 8.59.0).
Relation::requireMorphMap();
// And then map your morphs in the standard way.
Relation::morphMap([
'user' => User::class,
]);Tło mapy morficznej
Podczas tworzenia relacji polimorficznych w Laravel, domyślnym zachowaniem zawsze było przechowywanie nazwy klasy powiązanego modelu w bazie danych. Z Dokumentacja Laravela:
Domyślnie Laravel użyje w pełni kwalifikowanej nazwy klasy do przechowywania „typu” powiązanego modelu.Na przykład, biorąc pod uwagę powyższy przykład relacji jeden-do-wielu, w którym model komentarza może należeć do modelu posta lub wideo, domyślnym
commentable_typebędzieApp\Models\Post lubApp\Models\Video, odpowiednio.
Stosowanie tej metody domyślnej oznacza, że Twoja baza danych zostanie wypełniona nazwami klas Twoich modeli, co ściśle łączy dane w Twojej bazie danych z nazwami Twoich klas.
Laravel zawsze dawał nam możliwość oddzielenia nazwy klasy od bazy danych przez rejestracja MorphMap, która zapewnia alias dla klasy, łamiąc to powiązanie:
// Store `user` in the database, instead of `App\User`
Relation::morphMap([
'user' => User::class,
]);Chociaż to zachowanie jest dostępne od jakiegoś czasu, nigdy nie było możliwe ścisłe jego wymaganie.
Zalety map Morph
Zaletą posiadania mapy morph jest przede wszystkim oddzielenie logiki aplikacji od przechowywanych danych. Przechowywanie nazw klas w bazie danych może prowadzić do szkodliwych, trudnych do debugowania błędów.
Jeśli zmienisz nazwę jednej z przemienionych klas, wszystkie odniesienia w Twojej bazie danych nie będą już zgodne z Twoją aplikacją. Ta podstępna część dotyczy tego, że prawdopodobnie nic nie zawiedzie podczas tworzenia lub testowania! O ile Twój zestaw testów w jakiś sposób nie wypełni Twojej bazy danych nazwą poprzedniej klasy, wszystkie Twoje testy będą zielone.Dopiero po wdrożeniu w środowisku produkcyjnym wystąpi niezgodność klas i danych.
Powyższy scenariusz można rozwiązać, pisząc migrację w celu aktualizacji przechowywanych danych, ale nie ma gwarancji, że Ty (lub następna osoba lub następna) będziecie pamiętać, że jest to konieczne.
Zamiast polegać na pamięci instytucjonalnej Twojej firmy, mapy morfacji niszczą skojarzenie i uwalniają Cię od potencjalnego błędu.
Korzyści z egzekwowania mapy morficznej
W ten sam sposób, w jaki mapy morph uwalniają cię od konieczności pamiętania o aktualizacji przechowywanych danych podczas refaktoryzacji klasy, wymaganie mapy morph uwalnia cię od konieczności pamiętania o zarejestrowaniu klasy na pierwszym miejscu.
Relation::morphMap([
'image' => Image::class,
'post' => Post::class,
]);-
image- from the morph map -
post- from the morph map -
App\Video- from the Laravel default implementation
// All future morphs *must* be mapped!
Relation::enforceMorphMap([
'image' => Image::class,
'post' => Post::class,
]);
