Obiektowa rejestracja i logowanie

Question

Zastanawiam się jak powinna wyglądać obiektowa rejestracja i logowanie, czy to powinno być obsługiwane przez dwie klasy czy jedną.

Jeśli jedną , to jak przekazywać wszystkie wprowadzone dane do klasy, ustawiać je seterami?

Jak tworzyć Trajty, czy one wszystkie powinny być w jednym pliku, czy każdy w osobnym?

 

Jeśli ktoś zna jakiś sensowny przykład takiej obiektowej rejestracji, logowania, to bardzo poproszę o link.

Answer 1

Tak po prawdzie tu będzie kilka klas. Tak na szybko IMO:

• kontroler do obsługi żądania HTTP,
• walidator danych,
• encja prezentująca użytkownika,
• klasa do obsługi zapisu do bazy danych (lub ogólnie warstwa obsługi bazy danych),
• klasa usługi zawierająca logikę związaną z rejestracją (czyli w dużej mierze komponująca działanie z wyżej wymienionych warstw).

Dla logowania będzie to wyglądać analogicznie.

Oczywiście w mniejszych projektach można to uprościć (np. walidator wbudować w encję albo zrobić "tradycyjne" MVC i całą logikę wrzucić do modelu).

Można spojrzeć np. jak robi to FoS – ale to już przypadek trochę ekstremalny ;)

Comments

walidator wbudować w encję

Ja z własnego doświadczenia powiem, że zamiast iść w tę stronę to raczej zrobiłbym zupełnie oddzielne endpointy walidacyjne. Mogą to być endpointy dla pojedynczych elementów (np. walidacja telefonu, walidacja istnienia usera w bazie itp.) i jakieś endpointy grupujące, to już zależy od potrzeby.

Takie podejście pozwala na wykorzystanie mikrousługi walidacyjnej w prosty sposób zarówno w API jak i na froncie (robiąc strzały gdy dane pole powinno mieć bardziej skomplikowaną walidację) i dodatkowo daje otwartą drogę do trzymania ujednoliconej walidacji gdy za chwilę coś innego będzie chciało z tego skorzystać.

Dla przykładu - teraz mówimy o rejestracji, więc może będziemy chcieli zrobić jakaś walidację pola e-mail (na razie nie istotne w ogóle jak działa ta walidacja). Za chwilę gdzieś na stronie dojdzie nam jakiś formularz, może jakieś zamawianie i bam, znowu pewnie e-mail. Za chwilę biznes przyjdzie znowu z pomysłem neweslettera i bum, kolejna walidacja e-maila... kilka elementów, które można by obsłużyć pięknie jedną mikrousługą walidatora i jednym endpointem :)

Ja bym racze był zwolennikiem myślenia perspektywicznie, co naprawdę bardzo ułatawia... i co najważniejsze, daje porządek gdy nad projektem pracuje kilka osób - nie wyobrażam sobie, aby każdy ficzer tworzył sobie wlasną klasę walidacyjną :)

---

Ok, zgadzam się… tylko po co od razu robić z walidatora mikrousługę? ;) Walidator wydzielony do osobnej klasy i następnie wstrzykiwany przez DI w pełni wystarczy dla sporej liczby (jak nie większości) projektów. Trzymanie walidatora jako osobnej mikrousługi to raczej już pomysł dla naprawdę sporych projektów, gdzie całość jest kompozycją niezależnych usług. Przy bardziej monolitycznym podejściu IMO to przerost formy nad treścią.

---

oki fakt, przy małych projektach może nie jest to potrzebne (ale przy większych już można dostrzec zalety takiego podejścia, jak chociażby wydzielenie konkretnych mikrousług do utrzymania przez konkretne zespoły, łatwiejszy dewelopment, PR wpływające na niezależne fragmenty itp., moim zdaniem są widoczne zalety takiej architektury ale to jak zwykle bywa zdanie subiektywne i opinii jest wiele:)

Robienie monolitów ma jednak jedną istotną wadę, a mianowicie z moich doświadczeń wynika, że znacznie łatwiej wdrażać i ewentualnie wycofywać zmiany wersji mikrousług niż monolitów - a mam obecnie styczność i z jednym i z drugim rozwiązaniem. Nie warto bać się "rozdrabniania" projektu bo przy wielu sytuacjach taka architektura naprawdę daje wiele plusów.

I nie mówiąc już o kwestiach mega ważnych jak np. skalowalność... tutaj chyba nie powiesz mi,że monolit ma szansę wygrać ze światem mikrousług :)

---

I nie mówiąc już o kwestiach mega ważnych jak np. skalowalność... tutaj chyba nie powiesz mi,że monolit ma szansę wygrać ze światem mikrousług :)

Ile projektów potrzebuje skalowalności na tym poziomie? Normalny projekt prawdopodobnie nie dobije do takiej skali, żeby odczuć faktyczną różnicę.

Mikrousługi faktycznie mają sens, gdy nad projektem pracuje grupa ludzi. Jak pracujesz samodzielnie, to po prostu dokładasz sobie więcej pracy. Trzeba zadbać o sensowną izolację każdej mikrousługi (Docker?), o sensowną komunikację między nimi (REST API jest dobrym punktem wyjścia, ale sensowniej zaaplikować jakieś MQ), o obsługę błędów i automatyczny restart padającej usługi… Jak się nie ogarnia tematyki administracji tego typu rzeczy, to jest to porywanie się z motyką na słońce.