Macie jakieś sprawdzone sposoby jak nazywać obiekty DTO? Np. mamy klasę Invoice, która odzwierciedla w 100% tabelę z bazy danych. Następnie serwis filtruje kolekcje tych klas na podstawie jakichś warunków i zwraca obiekt DTO, a API wystawia go na zewnątrz. Teraz pytanie: taki obiekt w zależności od kontekstu potrzebuje tylko część pól z klasy Invoice , ale nieraz potrzebuje także dane z innej klasy. Czy macie jakieś konwencje jak nazywać takie obiekty które są okrojoną wersją jednego obiektu lub zlepkiem danych z dwóch lub więcej obiektów? Czy nazywacie go zgodnie z jakimś kontekstem ? Taki kontekst dosyć trudno określić a z kolei nie podoba mi się jak ktoś nazywa takie obiekty np. InvoiceInfo, InvoiceWithData, InvoiceData, InvoiceBasicContent. To powoduje śmietnik i takie nazwy nic nie mówią. Mało tego zdarza się że klasa InvoiceDTO ma mniej danych niż InvoiceBasicContent. Jak zrobić to dobrze?
0
2
Jak wywołuję operację X, to mam XDTO. Mało oryginalne, ale przynajmniej unikam konfliktów nazw i pakietów, bezsensownych nazw niezwiązanych merytorycznie z operacją, a do tego łatwo potem znaleźć ten typ..
0
@Afish: dopisywanie na końcu nazwy klasy DTO sufiksu DTO jest dla mnie tak oczywiste, że już bardziej być nie może.
...Bo po co zaciemniać sobie spektrum skoro DTO to DTO i nic innego?
0
Nie mam tu jakiejś wielkiej konsekwencji, ale w sumie nigdy nie nazywam klas EtwasEtwasDTO. Zaczynam design od frontu (API) i to tzw. DTOsy są moimi pierwszymi klasami,
mają nazwy obiektów domenowych, ale czasem też od operacji (zależy).
Natomiast te perzystentne to dziwadła i dostają przyrostki (BlaBlaData , BlaBlaRecord).