Tworzenie DTO - jedno czy wiele?

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?

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

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.

Na pewno nie jedno, skoro mają różne pole. Co najwyżej mogą dziedzić wspólne pola z jakiegoś bazowego dto.

1. Uzasadnienie powyżej.
   W końcu 3 to magiczna liczba. ;-)

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.