Jakie podejście stosować przy przesyłaniu danych zalogowanego użytkownika do widoku

Sytuacja wygląda następująco: mam sobie encję User, która zawiera podstawowe dane służące do uwierzytelnienia (email, hasło, zbiór ról). W aplikacji każdy użytkownik posiada jakieś dodatkowe informacje takie jak: nick. miejsce zamieszkania, punkty itp. Po zalogowaniu, chciałbym przesłać te dane do widoku w celu ich wyświetlenia. W tej chwili do głowy przychodzą mi 2 podejścia:

1. Tworzę drugą encję (UserProfile) w relacji 1 do 1 z User, tworzę pole UserProfile userProfile w klasie User.

2. Wszystkie dane umieszczam w klasie User, korzystam z DTO żeby nie przesyłać danych związanych z samym kontem. W zasadzie nie zdarzyło mi się korzystać z DTO i nie wiem czy to w ogóle ma sens. Czy takie przykład zastosowania DTO jest dobry/poprawny?

Używasz może hibernate?

@whusp: DTO to nic innego jak Data Transfer Object, czyli struktura do przesyłania danych w językach struktur jako takich (w sensie C) pozbawionych. To czy będziesz używać User, czy UserProfile nie ma większego znaczenia z tego punktu widzenia. Istotne jest to jakie dane chcesz przesłać. Na pewno nie całego Usera, w którym mogą być dane w rodzaju hasło.

Utwórz sobie klasę, która zawiera tylko niezbędne dane i to pchnij do UI

morgutrin napisał(a):

Używasz może hibernate?

Tak używam hibernate. Pomysł nr 1 bazuje na samej strukturze bazy danych a całe mapowanie "robi się samo".

Czyli rozumiem, że nie do końca rozumiem zastosowanie dto. Może ktoś podać jakiś prosty przykład zastosowania dto w aplikacji pisanej w springu?

@whusp: hibernate nie ma nic do tego. Serio. Choć można go do pewnego stopnia wykorzystać. Przykład prosty:

// encja hibernate
class UserEntity{
    String login;
    String password;
}

//DTO

class UserDto{
    String login;

    UserDto(UserEntity){
      // Przpisanie pól
    }
}

I to jest najprostszy zestaw. Innym podejściem są adnotacji, które pozwalają na przerzucenie informacji co ma trafić do DTO na springa, ale możesz wpaść w annotation hell gdy użyjesz ich bezpośrednio na encji.

@Koziołek Właśnie o coś takiego chodziło mi w tym punkcie nr 2 - wszystkie informacje w jednej klasie, które potem są "ucinane" przy mapowaniu User na UserDto. To teraz powstaje pytanie, które podejście jest lepsze ;p

Drugie, bo wystawiasz na świt tylko te dane, które są tam potrzebne.

@Koziołek w pierwszym też przesyłam tylko potrzebne dane, ale tworzę przy okazji dodatkową tabelę i relację 1 do 1...

@whusp: a co będzie jak będziesz chciał zmienić dane przesyłane? Będziesz rył całą aplikację jak dzika świnia ściółkę by truflę znaleźć? To co widzisz na UI nie ma znaczenie z punktu widzenia bazy danych i na odwrót, to jak UI obsługuje dane nie powinno wpływać na bazę.

Cały temat właśnie po to był założony, ale nie do końca chyba rozumiesz o co mi chodzi, bo też nie wiem "co UI ma do bazy danych". Chodziło o to, że z jednej strony mogę stworzyć dodatkową relację i tabelę i nie musieć się martwić żadnym mapowaniem (zwalam robotę na Hibernate'a) albo nawrzucać wszystko do jednej tabeli (ilość kolum będzie wtedy dosyć duża) i ręcznie mapować obiekt na dto przed wysłaniem do widoku. Zazwyczaj korzystałem ze sposobu nr 1, ale ostatnio coraz częściej trafiam na dto, więc szukam rady kogoś doświadczonego w tym temacie. A może oba rozwiązania są beznadziejne i w praktyce robi się to inaczej?

@whusp: to kolejna ciekawostka. Nie musisz nic mapować ręcznie. Możesz użyć operatora new w zapytaniu HQL:

@NamedQueries({
	@NamedQuery(
	name = "userUi",
	query = "Select new UserUI(u.userName, u.userEmail) from User u WHERE u.id=:userId"
	)
})
@Entity
@Table(name = "Users")
public class User {

I wtedy wystarczy tylko napisać konstruktor przyjmujący wszystkie pola, których chcesz użyć.