Może jest na to jakiś pattern lub chociaż dobra praktyka.

Mamy grupę prostych operacji CRUD w oparciu o zestaw: kontroler na wszystkie akcje (index, create, update, delete), walidacja, widoki, warstwa biznesowa (zapytania do bazy). Do tego ewentualnie tłumaczenia do widoków ale to mniej istotne.
Te akcje mogą być wykonywane przez użytkowników np. nauczycieli na ich poziomie (czyli mogą dodać ucznia, zmienić dane klasy itp.).

Teraz chciałbym dodać takie same możliwości dyrektorowi, który ma osobny panel typu sekretariat.
Zastanawiam się jak to ugryźć aby uniknąć nadmiernej duplikacji kodu.
Między operacją dokonaną przez dyrektora, a nauczyciela są różnice np. przy dodawaniu ucznia nauczyciel nie wybiera do jakiej klasy bo tą ma przyisaną, a dyrektor musi wybrać z listy select klasę.
Ta różnica ma wpływ na widok, walidację, reszta jest praktycznie taka sama.

Póki co w Laravel mam wydzielone do osobnych klas walidację (choć muszę tutaj jeszcze dodać ten jeden warunek) oraz wydzieloną logikę biznesową do repozytorium/eloquent. Pozostaje duplikacja kodu w widokach i kontrolerach. Widoki nie wiem? Wydzielić form do osobnych widoków i includować? A logika kontrolerów? Jedyne co mi przychodzi do głowy to jakieś osobne klasy lub traits.

Jakieś Wasze doświadczenia?

Przecież nauczycieel i dyrektor ma dokładnie 99% tego samego. Jedyna różnica jak mówiłes to że dyrektor wybiera klasę. Więc wystarczy prosty warunek sprawdzający uprawnienia i wyświetla albo hidden z id klasy lub select z klasami. validacja zostaje ta sama, kontroler ten sam.

No chyba że czegoś nie zrozumiałem

Nauczyciel i dyrektor mają zupełnie osobne panele - powiedzmy class/* ma nauczyciel, a management/* ma dyrektor. Różni się więc routing i cała otoczka wizualnie (template), i w sumie teraz też właśnie przypomniałeś o uprawnieniach (policy) ale to akurat może być wydzielone do klasy php (Policy to weryfikacja czy jest nauczycielem tej konkretnej klasy i/lub dyrektorem).

- w kontrolerach to nie problem, bo kontrolery nie zawierają kodu poza np. $service->doSth(), jeśli masz kod w kontrolerach to powinieneś go przenieść do serwisów
- w widokach jak wyżej, kod przygotowujący zmienne do templatek łatwo wydzielić do serwisów

Potem w serwisach bardzo łatwo jest wydzielić/sparametryzować wspólne bloki kodu.

Tu właśnie jest moment, który kazał mi wszystko przemyśleć.
W starych aplikacjach pisanych np na CI moje kontrolery są mega przerośnięte i zawierają dużo logiki i tam mega mnie drażniło gdy przenosiłem funkcjonalność z jednego panelu do drugiego, takie kopiuj wklej ponad 100 linijek gdzie musiałem zmienić jedną czy dwie. Teraz to znacznie odchudziłem przenosząc część do repository/modelów (pobieranie i operacje na danych), Requestów (walidacja), Policies (autoryzacja) ale i tak część rzeczy musi być w kontrolerze albo przynajmniej tak mi się wydaje. Jakaś logika requestu, upload, przekazanie różnych zmiennych potrzebnych do widoku. Nie da się albo przynajmniej nie wiem jak jeszcze bardziej odchudzić kontroler. Czy dodać jeszcze jedną warstwę coś pomiędzy kontroler, a repository, czy pchać do Trait'sów. Zastanawiałem się czy też jest opcja na jakaś re-używalność kontrolera - powiedzmy cały 'CRUD kontroler' i kilka innych prostych metod (np. do ustawiania jakichś prostych flag) używany w dwóch różnych kontekstach. U góry w kontrolerze tylko jakiś property z definiujący kontekst i potem w konkretnych metodach czasem jakiś if. Nie wiem czy to gra warta świeczki.

Pierwsze próby za mną.

Póki co wygląda to fajnie:
- trzeba na pewno napisać osobny routing tak aby ścieżki w drugim panelu wskazywały na kontroler bazowy
- autoryzacja jeżeli Policy przewiduje obie role - nie ma tu problemu
- zapytanie dodające do bazy jeżeli jest zbieżne tu i tu to nie ma problemu, ale na pewno będzie konieczność przekazania parametru bo przykładowo jak nauczyciel tworzy klasę ma od razu być dodany do grona, a dyrektor nie więc pewne akcje będą się różnić
- trzeba routing troszkę dopasować po stronie kontrolerów i widoków bo przykładowo store() i update() zadziałają ale już jest problem z przekierowaniem z powrotem do odpowiedniego panelu, nie zawsze da się użyć back(). Gdzieś globalnie trzeba ustalić w którym panelu jesteśmy (ja to zrobiłem w takim kontrolerze, po którym dziedziczą pozostałe) + przekazać do widoków aby w formularzach i linkach podmienić ścieżki.

Tak więc nie obędzie się bez paru IFów ale póki co poszło bez dziedziczenia, osobnych widoków czy trait'sów.