Załóżmy, że w jakimś QuestionDto
chcę przesłać informacje o, powiedzmy, autorze (id, name). Czy lepiej dodać do tego DTO właściwości AuthorId
i AuthorName
, czy może lepiej utworzyć specjalnie jakieś XXXAuthorInfo
i umieścić je w oryginalnym DTO? Różnie ludzie piszą na ten temat.
Ja robię to najprościej jak się da, jeżeli mapowanie ze złożonej struktury jest łatwiejsze, to tak robię. Trudność może być przy przesyłaniu po sieci, wtedy warto powalczyć o rozmiar.
Ja wolę grupować w przypadku powielających się struktur. Jeżeli różne dane wyjściowe/wejściowe mają np. Address
, to łatwiej to ogarnąć. Co do przykładu postawionego w pytaniu, to nie wiem, ale może być na siłę. Zależy pewnie, co tam jeszcze siedzi w tym QuestionDto
.
U mnie poniekąd muszą byc poskładane z mniejszych - drzewko. Tylko wtedy da się uniknąąc tony argumentów dla konstruktora.
(wiem, że jest inne wyjście, ale ono jest obrzydliwe)
DTO to nie VM, nie musi być płaskie.
@somekind: moglbys podac jakis przyklad pokazujacy, ze viewmodele powinny byc plaskie?
Tak jak napisałem w komentarzu, z różnymi GUI widgetami (zwłaszcza z gridami) łatwiej się binduje płaskie modele. Tyle wiem z własnego doświadczenia, zarówno na desktopie jak i webie. Gdybym miał teraz robić jakieś GUI, to też poszedłbym tą drogą.
Ale nie będę się kłócił, jeśli komuś hierarchiczne viewmodele coś dają, to mi nie przeszkadza.
Jeśli będziesz tworzyć VM, wtedy kiedy są potrzebne, czyli kiedy musisz dodać faktycznie jakąś wartość, która wynika bezpośrednio z mechaniki widoku, praktycznie zawsze będzie to płaskie VM.