![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 43 Pomógł: 0 Dołączył: 2.09.2012 Ostrzeżenie: (0%) ![]() ![]() |
Czy istnieje jakieś przeciwskazanie, aby klasę User rejestrować jako service? Chodzi o to, że ustawiam w niej role użytkownika na podstawie różnych parametrów i niewielkich algroytmów. Dotychczas były to parametry zapisywane w bazie, w tabeli User, natomiast teraz chcę nadać rolę na podstawie parametru zapisywanego w configu, a żeby się do niego dostać, potrzebowałbym wstrzyknąć - sam jeszcze nie wiem co, ale choćby np. cały container. Ale czy to jest zalecane rozwiązanie?
|
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) ![]() ![]() |
Cytat Myślałem, że skoro w dokumentacji jest: - zauważ, że musi być ta metoda, bo wymusza to interfejs.Natomiast ten fragment kodu jest owszem, niefortunny - bo nawet jeśli coś hardkodujemy to powinniśmy to chociaż okomentować. Można tak zrobić, jeśli każdy User ma mieć zawsze jedną i tą samą rolę - po co wtedy zapisywać to w bazie? Robi się wtedy stałą typu "USER_DEFAULT_ROLE" (albo "FIXED_ROLE") a metoda getRole zwraca tą stałą. Jeśli natomiast rola ma się dla użytkownika zmieniać, to chyba oczywiste, że powinieneś ją przechowywać w bazie danych. Natomiast jeśli potrzebujesz obiektu, który zawiera dane nie tylko z bazy oraz nie jest odwzwierciedleniem rekordu z tabeli bazodanowej to nie może to być encja - jednak w praktyce różnie bywa i nierzadko programiści wp.... do encji co popadnie. O tym co powinno być w encji a co nie decyduje zdrowy rozsądek - zazwyczaj drobna logika jest dopuszczalna (np. implementacja metody getFullName, która zwraca name + lastname lub inne takie). Jednak trzeba pamiętać, że "czystej" encji oczekuje wiele komponentów (formularze, walidatory, menedżer encji etc.) i majstrując przy niej możesz wywalić pół aplikacji (IMG:style_emoticons/default/Lkingsmiley.png) |
|
|
![]() ![]() |
![]() |
Aktualny czas: 10.10.2025 - 16:34 |