O tym by nie dodawać devise do klasy User


#1

:smile:


#2

Ciekawe, praktykowałeś?


#3

Jestem zdecydowanie za :smile:

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.)


#4

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 :wink:


#5

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!