1 Like
Ciekawe, praktykowałeś?
Jestem zdecydowanie za
Zwykle (nie we wszystkich projektach) tworzenie osobnej klasy autentykacji jest dobrym wyjściem. Ma to też duże + jeżeli w przyszłości zdecydujemy się na inne formy autentykacji (SSO, etc.)
Natrafiłem na tę prezentację przez Twittera parę dni temu i od razu mnie urzekła. Sam zwykle pchałem devise do modelu User, ale poza autentykacją niczym się ten model nie zajmował. “Logiczny” użytkownik był w UserProfile albo Member. Natomiast stosowałem to wyłącznie na podstawie przeczucia, a zawsze lepiej, kiedy ktoś uargumentuje, że moja intuicja była słuszna 
Ja stosuje troche inne podejscie.
Obiekt User jest jedynie obiektem sprzezonym z devise + zawiera w sobie relacje i walidacje pol. Cala reszte przerzucam do klas/uslug zajmujacych sie konkretnymi problemami.
Oczywiscie masz racje jesli chodzi o problem testowania - natomiast moje rozwiazanie na pewno pozwala mi na rozdzielenie odpowiedzialnosci - jedna odpowiedzialnosc jedna klasa.
Twoje podejscie zastosowalem raz - gdy faktycznie dostep do systemu mogl byc z wielu niezaleznych zrodel (wewnetrzna platforma crm) - wtedy wydzielilem calkowicie modul autentykacji i praw dostepu.
Dziekuje za ciekawy wpis!