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.
0
1
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.
1
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.
4
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)
3
DTO to nie VM, nie musi być płaskie.
0
@somekind: moglbys podac jakis przyklad pokazujacy, ze viewmodele powinny byc plaskie?
1
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.
1
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.