Cześć
Mam ciekawą sytuację. Mam DTO który jest stworzony pod GETa i zamiera pola powiedzmy X,Y,Z. Teraz w przypadku PUTa chce zaktualizować A,B,C, natomiast w przypadku POSTa chce pola z GETa i PUTa + dodatkowe pola. Czy w takim przypadku stworzyć jedno DTO czy też stworzyć trzy DTO? Czy może tutaj też działa zasada w stylu Interface segregation principle?
0
8
Jeśli chcesz tworzyć jedno uniwersalne DTO co do pola zgodne z Encją to już lepiej w ogóle nie tworzyć DTO tylko używać wszędzie Encji.
IHMO tworzenie DTO ma sens jeśli różni się od Encji, inaczej to jest korpo-sztuka dla korpo-sztuki
TL;DR
Lepiej utworzyć trzy DTO, tak by każde miało tylko te pola które są potrzebne i w w żadnym nie nadużywać nulli
2
Ja bym nawet tego DTO fizycznie nie nazywał tylko np. CosTamQuery i CreateCosTamCommand. W przypadku modyfikacji dedykowany obiekt zawierający tylko istotne pola, np. WithdrawMoneyCommand.
2
Na pewno nie jedno, skoro mają różne pole. Co najwyżej mogą dziedzić wspólne pola z jakiegoś bazowego dto.
0
- Uzasadnienie powyżej.
W końcu 3 to magiczna liczba. ;-)
1
ornek napisał(a):
Cześć
Mam ciekawą sytuację. Mam DTO który jest stworzony pod GETa i zamiera pola powiedzmy X,Y,Z. Teraz w przypadku PUTa chce zaktualizować A,B,C, natomiast w przypadku POSTa chce pola z GETa i PUTa + dodatkowe pola. Czy w takim przypadku stworzyć jedno DTO czy też stworzyć trzy DTO? Czy może tutaj też działa zasada w stylu Interface segregation principle?
Tu nie chodzi o ISP ale o SRP. Każda klasa powinna mieć jeden powód do zmiany, a więc zmiana struktury zapisu nie może zmieniać struktury odczytu.