Widoki... dynamiczne? generyczne?... w ASP.NET MVC

Męczy mnie powielanie kodu i pisanie oddzielnych widoków dla każdego ViewModelu w ASP.NET MVC, tym bardziej że większość z nich służy do obsługi operacji CRUD. Chciałbym stworzyć np. jeden widok List, do którego przekazać można każdy ViewModel spełniający takie czy owakie warunki. Odwołując się za każdym razem do tego samego widoku chciałbym wypluwać na ekran tabele produktów, zgłoszeń, zakupów, klientów, transakcji - w zależności od kaprysu i potrzeby chwili. ViewModele o różnych typach i nazwach właściwości, a widok List tylko jeden jedyny.

Jestem przekonany, że jest to możliwe, inaczej świat nie miałby sensu. Mogę prosić o jakieś wskazówki jak zabrać się do rzeczy?

Wydziel część wspólną do jakiegoś partial view i wywołuj go tam gdzie chcesz takową listę wyświetlić.

No potrzebujesz po prostu umieć wygenerować na podstawie ViewModelu grida (czyli najpierw musisz wiedzieć jakiego grida chcesz, bo biblioteczek JS do tego jest sporo), a z drugiej strony musisz ten ViewModel przekształcić jakoś na obiekt reprezentujący dane w bazie, co raczej wymaga użycia biblioteki mapującej i też dynamicznego jej skonfigurowania. Na koniec pozostaje dynamicznie składać zapytania ORMa. Potrzebujesz zatem jakiejś warstwy abstrakcji umożliwiającej przesłanie z widoku do kodu pobierającego dane, informacji o ustawieniach filtrowania, sortowania, liczby pozycji na stronę w gridzie, itd. Zapis, edycja i usuwanie w porównaniu z pobieraniem danych będą całkiem proste - po prostu mapujesz ViewModel na model ORMa, a ten go zapisuje/usuwa.

Możesz też użyć czegoś w miarę gotowego: https://github.com/dwdkls/pizzamvc

Super, właśnie takiej wskazówki oczekiwałem, dzięki!

W pewnym momencie jak narośnie ci w pizdu logiki okaże się, że stworzyłeś własny framework do budowania widoku XD i utrzymywanie tego to będzie masakra z generycznością trzeba uważać ;p

@Schadoow: no, ale to jasne, że do tego trzeba frameworka. Ale jak widać na podlinkowanym przykładzie, to nie jest rocket science. Przy wielu powtarzalnych operacjach crudowych, to się opłaci.

@somekind: bardziej mi chodziło, że zbyt przesadzona generyczność powoduje więcej problemów niż pożytku. Bo w pewnym momencie rozwoju aplikacji(pare lat) dochodzi się do wniosku, że nie da się tam już palca włożyć i projekt przepisywany jest na nowo. Właśnie aktualnie jestem w takim projekcie XD. A z tym własnym frameworkiem to chodziło mi o kolejna warstwę abstrakcji na framework, którego używasz.

@Schadoow: znam takie frameworki, też zdarzało mi się pracować w projektach bazujących na takich cudakach. Tylko to jest problem wyłącznie głupoty i przerośniętego ego ich twórców, którym się wydaje, że stworzą uniwersalny framework do wszystkiego, w którym wszystko będzie konfigurowalne i nie trzeba już będzie pisać normalnego kodu tylko konfigurować.
Niestety, udaje im się tylko ostatnie, bo kod w takich projektach jest daleki od normalnego. ;)

Dobry framework musi trzymać się dwóch zasad:

1. SRP w skali definiowania wymagań - framework ma robić jedną rzecz (np. CRUDa), a nie wszystko (raporty, konfigurację, bezpieczeństwo, i cokolwiek tam jeszcze w aplikacji może być potrzebne);
2. Nie ukrywać tego, z czego sam korzysta. ORM, IoC, mapowanie, logowanie, obsługa weba, plików, cokolwiek - to musi być nadal dostępne dla programisty, w razie jakby w aplikacji trzeba zrobić coś, czego twórca frameworka nie przewidział albo nie wspiera.

Niestety wielu twórców się tego nie trzyma i tworzy takie potworki, których utrzymanie później jest koszmarem, bo niczego się nie da zrobić zgodnie z zasadami technologii, wszystko wymaga hackowania frameworka.