Serwus!
Czy w porządku jest tworzenie osobnych viewmodelów dla każdej akcji (lub prawie każdej)? Np. ProductsIndexViewModel, ProductDetailsViewModel, ProductListViewModel, ProductManageViewModel itd?
Czy okej są metody serwisów, które jako typ zwracany mają tenże viewmodel?
public ProductListViewModel GetProductListViewModel(params)
{
/* operacje wypełniania danych */
return viewModel
}
Tak.
Czy w porządku jest tworzenie osobnych viewmodelów dla każdej akcji (lub prawie każdej)? Np. ProductsIndexViewModel, ProductDetailsViewModel, ProductListViewModel, ProductManageViewModel itd?
W teorii tak w praktyce nie, ponieważ jest to kosztowne, najczęściej możesz zwrócić po porstu DTO ablo Persistance jeśli jest typu POCO i to output.
Czy okej są metody serwisów, które jako typ zwracany mają tenże viewmodel?
public ProductListViewModel GetProductListViewModel(params)
{
/* operacje wypełniania danych */
return viewModel
}
Jeśli to serwis domenowy znajdujący się w warstwie domenowej(dllce) to nie, no chyba, że robisz jakieś fikuśne dependecy inversion ale to bez sensu.
Tak
To zależy ;)
W teorii tak w praktyce nie, ponieważ jest to kosztowne, najczęściej możesz zwrócić po porstu DTO ablo Persistance jeśli jest typu POCO i to output.
A potem się dziwią, że encje wyciekają
Somekind...!!, Wytłumacz mu czym się różni Encja od Persistence... :) Niektórzy mają gorze problemy, np. encje z bazy danych wyciekają im do logiki.... ;)
Smutny Programista napisał(a):
W teorii tak w praktyce nie, ponieważ jest to kosztowne, najczęściej możesz zwrócić po porstu DTO ablo Persistance jeśli jest typu POCO i to output.
Ale czemu jest kosztowne? Bo trzeba napisać kilka dodatkowych DTO?
Smutny Programista napisał(a):
Somekind...!!, Wytłumacz mu czym się różni Encja od Persistence... :) Niektórzy mają gorze problemy, np. encje z bazy danych wyciekają im do logiki.... ;)
No persitence model nie jest encją, ale viewmodelem też nie jest. Zwracanie persistence modeli do GUI nie ma sensu.
Zwracanie persistence modeli do GUI nie ma sensu.
Jeśli jest to persistence modeli typu POCO czyli bez żadnych atrybutów i tp.
To dlaczego nie ma to sensu. ?
Jeśli chce wybrać z bazy listę z 250 wierszami. To potem muszę to przemapować na DTO, a potem ViewModel i wykonać przy tym dwie niepotrzebne pętlę.
Tylko dlatego, że ktoś powiedział "Bo to jest dobra praktyka...."?
Ja robę generyczne DTO jako wpra na Presistence Model (typu POCO) jeśli chcę coś dodać np. metadane.
No chyba, że jest to referencja zwrotna przy asocjacji wiele do wielu ze względu na lazy loading w ORM, piszę DTO (Jeśli nie potrzebuje w tym case tej referencji).
W przeciwnym razie zwykle używam slecta operując na IQueryable lub innym mechaniżmie ORM. Zwracając persistence z nullem gdzie trzeba.
Ale czemu jest kosztowne? Bo trzeba napisać kilka dodatkowych DTO?
Na pewno nie jest to wielki koszt, ale jest to koszt nieuzasadniony, a takich kosztów należy unikać.
Ps. No, chyba że jest to koszt uzasadniony :)
Smutny Programista napisał(a):
Zwracanie persistence modeli do GUI nie ma sensu.
Jeśli jest to persistence modeli typu POCO czyli bez żadnych atrybutów i tp.
A co złego w atrybutach w persistence modelu? Moim zdaniem to odpowiednie miejsce na umieszczenie metadanych dla ORM. Bo do tego właśnie służą persistence modele - do wygenerowania struktury bazy danych przez ORM oraz do modyfikacji danych w bazie.
Jeśli chce wybrać z bazy listę z 250 wierszami. To potem muszę to przemapować na DTO, a potem ViewModel i wykonać przy tym dwie niepotrzebne pętlę.
Tylko dlatego, że ktoś powiedział "Bo to jest dobra praktyka...."?
No to już jest Twój pomysł. Ja nie rozumiem po co Ci tutaj jakieś DTO, a nie VM od razu.
No to już jest Twój pomysł. Ja nie rozumiem po co Ci tutaj jakieś DTO, a nie VM od razu.
A dlaczego VM a nie DTO? VM to kontrakt widoku najczęściej z aspektami które implementują dodatkowe zachowania widoku ale oczywiście nie tylko w taki sposób można je implementować.
Miejsce ViewModelu jest w warstwie perezentacji, w której jest zaimplementowany wzorzec projektowy prezentacji MVC najczęściej wymuszony przez framework prezentacji internetowej.
Według twojego toku myślenia mógłbyś w warstwie domenowej zaimplementować paginację no bo po co jakaś separacja albo od razu wrócić Jsona. ViewModel istnieje po to, żeby implementować zachowania lub typy, które nie wynikają z domeny a widoku.
A co złego w atrybutach w persistence modelu? Moim zdaniem to odpowiednie miejsce na umieszczenie metadanych dla ORM. Bo do tego właśnie służą persistence modele - do wygenerowania struktury bazy danych przez ORM oraz do modyfikacji danych w bazie.
Nie koniecznie. Hibernate został zaprojektowany z myślą o odwzorowaniu obiektów Domain Model(z niewiadomych pobudek :) ). Dlatego możesz ustawić jego mapowanie poza klasą, na którą mapujesz. Jeśli uważasz, na slect N+ to jaki jest problem, chodzi ci o to, że to proxy. Czy po prostu ten sufiks na końcu jest nie taki?
A jeśli chcesz użyć lazy loading w widoku np. po wciśnieciu jakiegoś buttona (z wykluczeniem aplikacji webowych, bo to bez sensu) to jak to zrobisz? Będziesz to implementował koło ORM'a?
Smutny Programista napisał(a):
A dlaczego VM a nie DTO? VM to kontrakt widoku najczęściej z aspektami które implementują dodatkowe zachowania widoku ale oczywiście nie tylko w taki sposób można je implementować.
Bo odzwierciedla to, co zostanie pokazane w widoku aplikacji, więc dla mnie to VM. Ale jak chcesz, to sobie to nazywaj DTO. Na pewno nie jest to PM, czyli nieobrobiona struktura tabel z bazy.
Miejsce ViewModelu jest w warstwie perezentacji, w której jest zaimplementowany wzorzec projektowy prezentacji MVC najczęściej wymuszony przez framework prezentacji internetowej.
No czyli to Ty chcesz, aby warstwa mająca dostęp do bazy odczytywała jakieś dane i zwracała je w postaci obiektów, które następnie dopiero będą mapowane na VM? Bo jak dla mnie to nie ma problemu w napisaniu sobie warstwy zwracającej viewmodele ze źródła danych i konsumowanej przez warstwę prezentacji. Bez zbędnego żonglowania obiektami. No, ale ja sobie lubię ułatwiać, a nie utrudniać.
Według twojego toku myślenia mógłbyś w warstwie domenowej zaimplementować paginację
Nie wiem czyj to tok myślenia, ale na pewno nie mój. Warstwa domenowa w ogóle nie ma żadnego związku z pobieraniem i wyświetlaniem danych.
ViewModel istnieje po to, żeby implementować zachowania lub typy, które nie wynikają z domeny a widoku.
Jakiej domeny? Przy pobieraniu danych? Jakie zachowania ma model służący do odczytu?
Nie koniecznie. Hibernate został zaprojektowany z myślą o odwzorowaniu obiektów Domain Model(z niewiadomych pobudek :) ). Dlatego możesz ustawić jego mapowanie poza klasą, na którą mapujesz.
Mogę też w XML. Ale z tego nie wynika, że dekorowanie atrybutami persistence modelu jest w jakikolwiek sposób złe.
Jeśli uważasz, na slect N+ to jaki jest problem, chodzi ci o to, że to proxy. Czy po prostu ten sufiks na końcu jest nie taki?
Nie mam zielonego pojęcia o czym piszesz.
A jeśli chcesz użyć lazy loading w widoku np. po wciśnieciu jakiegoś buttona (z wykluczeniem aplikacji webowych, bo to bez sensu) to jak to zrobisz? Będziesz to implementował koło ORM'a?
Nie wiem, encja na twarz i pchasz to nie jest coś, co praktykuję. Do odczytu zawsze stosuje dopasowane viewmodele, zawsze pobieram je jak najbliżej źródła danych się da, lazy loadingu do prezentacji danych nigdy nie używałem.
Bo odzwierciedla to, co zostanie pokazane w widoku aplikacji, więc dla mnie to VM. Ale jak chcesz, to sobie to nazywaj DTO. Na pewno nie jest to PM, czyli nieobrobiona struktura tabel z bazy.
Dobrze wiem co jest co to Ty nie odróżniasz DTO od VM we wzorcu MVVM, VM to pewnie też DTO...
czyli nieobrobiona struktura tabel z bazy.
A jak się obrabia strukturę tabeli z bazy,? A framework prezentacji nie może się zająć tą "obróbką" myślałem, że od tego on jest.?
Jak chcesz wyświetlić tabelkę na ekranie to niby jak to obrabiasz....? ;)
No czyli to Ty chcesz, aby warstwa mająca dostęp do bazy odczytywała jakieś dane i zwracała je w postaci obiektów, które następnie dopiero będą mapowane na VM? Bo jak dla mnie to nie ma problemu w napisaniu sobie warstwy zwracającej viewmodele ze źródła danych i konsumowanej przez warstwę prezentacji. Bez zbędnego żonglowania obiektami. No, ale ja sobie lubię ułatwiać, a nie utrudniać.
Pewnie rób sobie dodatkową warstwę ja mam od tego action filter który zajmuje się mapowaniem, a raczej budowaniem VM po typie wystarczy, że nadasz odpowiednią nazwę VM a on już wie co zrobić np. w przypadku kiedy chcę dodać Hateoas'a na out. No i kto tu mówi o utrudnianiu sobie, życia.? Ty przez ten czas zrobiłeś drugą warstwę i do każdej metody w serwisach wklepałeś automapera o tym Hateoasie nie wspomnę nawet....
Nie wiem czyj to tok myślenia, ale na pewno nie mój. Warstwa domenowa w ogóle nie ma żadnego związku z pobieraniem i wyświetlaniem danych.
A to ciekawe, to gdzie trzymasz serwis który pobiera i przysyła te twoje ViewModle ;)
Jakiej domeny? Przy pobieraniu danych? Jakie zachowania ma model służący do odczytu?
Nie mam zielonego pojęcia o czym piszesz.
Nie wiem, encja na twarz i pchasz to nie jest coś, co praktykuję. Do odczytu zawsze stosuje dopasowane viewmodele, zawsze pobieram je jak najbliżej źródła danych się da, lazy loadingu do prezentacji danych nigdy nie używałem.
To takie pragmatyczne... ;)
Zabawnie się tego słucha, zwłaścza że VM i DTO to wzorce dystrybucji a wy obydwaj używacie toge tak naprawdę jako struktury dla mapowania ORM'a.
Zamiast tworzyć zbędne klasy, które nic nie wnoszą powinniście wpakować to, co chcecie przenieść do innej warstwy w
IDictionary<string, object>();
I już bez zbędnych klas
Smutny Programista napisał(a):
Dobrze wiem co jest co to Ty nie odróżniasz DTO od VM we wzorcu MVVM, VM to pewnie też DTO...
Nic o MVVM nie pisałem. ViewModel nie implikuje stosowania MVVM.
A jak się obrabia strukturę tabeli z bazy,?
Podstawowymi działaniami algebry relacji: selekcją, projekcją i połączeniami.
A framework prezentacji nie może się zająć tą "obróbką" myślałem, że od tego on jest.?
No można wyciągać całą bazę do pamięci, a potem wybierać te dane, które są potrzebne. Na tym m.in. właśnie wzorzec "encja na twarz i pchasz".
Pewnie rób sobie dodatkową warstwę ja mam od tego action filter który zajmuje się mapowaniem, a raczej budowaniem VM po typie wystarczy, że nadasz odpowiednią nazwę VM a on już wie co zrobić np. w przypadku kiedy chcę dodać Hateoas'a na out. No i kto tu mówi o utrudnianiu sobie, życia.? Ty przez ten czas zrobiłeś drugą warstwę i do każdej metody w serwisach wklepałeś automapera o tym Hateoasie nie wspomnę nawet....
Action filter budujący obiekty? Czyli aplikacja nie działa bez warstwy webowej? O jak słodko! :D
A masz może jeszcze model binder, który wstawia request HTTP od razu do bazy? :D
W moim podejściu ORM pobiera z bazy dane i tworzy z nich bezpośrednio odpowiednie viewmodele. Nie potrzeba tu żadnego automappera i nawet nie chcę wiedzieć skąd Ci się uroił.
To takie pragmatyczne... ;)
Owszem, SRP jest bardzo pragmatyczną zasadą i znacznie ułatwia niestrzelanie sobie w stopę.
Czarny Rycerz napisał(a):
Zabawnie się tego słucha, zwłaścza że VM i DTO to wzorce dystrybucji a wy obydwaj używacie toge tak naprawdę jako struktury dla mapowania ORM'a.
Zabawne jest to, że piszesz do samego siebie w trzeciej osobie i na dodatek "myślisz", że jak wejdziesz przez tora, to ja nie będę wiedział, że Ty to Ty.
Nie wiem po co robisz z siebie debila, ale jeszcze raz coś napiszesz z tora na tym forum, to będzie Twój ostatni post.
W moim podejściu ORM pobiera z bazy dane i tworzy z nich bezpośrednio odpowiednie viewmodele. Nie potrzeba tu żadnego automappera i nawet nie chcę wiedzieć skąd Ci się uroił.
Super widzę. że już jesteś na tym poziomie, że piszesz własne transformery do NH, WOW...
Dlaczego usunąłeś mój post przecież nikogo w nim nie obrażałem. Co cię w nim tak bolało?