Ogólne modele widoku?

Question

Zastanawiam się, czy dobrą praktyką jest zrobienie widoku, który przyjmuje ogólny model widoku?

Zastanawiam się nad tym, ponieważ ktoś wspomniał, że spodziewał się zrobić wiele kopii kodu, chyba że zaczął robić ogólny widok i ogólny model widoku.

Po prostu widoki byłyby jak zestaw kontrolek. Jeden widok może mieć 2 elementy sterujące (np. Pole tekstowe i przycisk opcji) inny widok może mieć 50 elementów sterujących.

Wszystkie będą miały ten sam wygląd i wygląd (po prostu zwiększa się liczba kontrolek). Zasadniczo myślał o tym, że model widoku przyjmuje obiekt (obiekt domeny) i sprawdza go na 50 polach oraz renderuje odpowiednie typy kontrolne.

Domyślam się, że szablon edycji może być użyty do określenia kontroli, ale nie jestem sprzedawany w ogólnym widoku modelu.

Lubię generyczne i potrafią robić bardzo potężne rzeczy, aw niektórych sytuacjach są dobre, ale nie jestem po prostu na tyle szalony i nie próbuję ich użyć.

Znajduję się przez większość czasu może zmniejszyć duplikat kodu, ale czasami sprawia, że ​​kod jest dużo bardziej skomplikowany. Oczywiście może to wynikać z tego, że wciąż jestem stosunkowo młodym programistą i może być on wciąż powyżej mojego poziomu umiejętności.

Kolejny problem, jaki mam z tym związany, to sądzę, że modele widoków powinny być możliwie płaskie i eksponować tylko dane, które będą używane, aby ludzie nie zaczęli używać właściwości, które nigdy nie powinny być widoczne w widoku. pierwsze miejsce.

Kolejny problem, jaki mam z tym, że może dalej działać, jeśli masz jakiś skomplikowany obiekt, który zawiera obiekty, które zawierają w sobie obiekty. To może potrwać długo.

Answer 1

Nie widzę niczego złego w generycznych ViewModels. Jest to dobry sposób na usunięcie duplikatów i utrzymanie kontroli podczas kompilacji, w przeciwieństwie do ViewBag.

Przykład:

Wyobraź masz zestaw klas wzorem dla Product, Category itp Każda klasa (ProductModel, CategoryModel) został skojarzony ekranu i edytor szablonu, który generuje odpowiedni widok.

Teraz chcesz zbudować zestaw stron do przeglądania i edycji.

zwykle utworzyć układ (strona wzorcowa w formularzach WWW), aby uczynić wspólną zawartość (nagłówek, stopkę, menu, etc.)

Następnie chciałbym tworzyć indywidualne, silnie wpisany widoki, które akceptują jako model ProductViewModel , CategoryViewModel, itp.

Teraz musimy zdefiniować te klasy modelu widoku. Każda klasa modelu widoku powinna przyjmować instancję ProductModel, CategoryModel itd. (Która zostanie przekazana do szablonu). Ale układ często wymaga dodatkowych danych (np. Wybrane menu, zalogowana nazwa użytkownika itp.).Moje rozwiązanie jest stworzenie rodzajowe ViewModel która zamyka ten duplikat danych do układu:

public class EntityViewModel<T> 
    where T : EntityModel 
{ 
    public T Entity { get; set; } 
    public string UserName { get; set; } 
    public string SelectedMenu { get; set; } 
} 

Następnie można łatwo utworzyć ProductViewModel : EntityViewModel<ProductModel>, który zawiera wszystko, co Układ potrzeba, aby uczynić stronę, a można dodać jakiś dodatkowy , dane specyficzne dla produktu.

Answer 2

Jeśli chodzi o ViewModels, zazwyczaj wszystkie moje modele ViewModels dziedziczą z BaseViewModel, który udostępnia metody pomocne w implementacji MVVM. Jeśli chcesz zobaczyć przykład, po prostu komentarz poniżej.

Answer 3

Osobiście unikam używania generycznych w widokowych modelach. Zgadzam się z większością z powodów, o których mowa przeciw nim, a szczególnie ten jeden:

Kolejny problem mam z nim jest myślę, że pogląd modele powinny być jak płaska jak to możliwe i tylko narazić dane czyli faktycznie będzie używany tak ludzie nie zacząć używać właściwości które nigdy nie powinny były w widoku w pierwsze miejsce

ideą widok modeli jest to, że muszą one być specjalnie przywiązany do wymogów dany pogląd, nie czyniąc ich ogólne (/ ogólne), ponieważ są to twoje modele domenowe. Preferuję duplikowanie kodu w modelach widokowych w porównaniu do posiadania ogólnego potwora ponownie użytego we wszystkich widokach i częściach.

Nawet w przypadkach, w których trzeba uzyskać generate dynamic forms and controls, nie trzeba używać ogólnych modeli widoku.

Tak więc, jeśli nie masz jakiegoś hiper-scenariusza (w tej chwili nie możesz o nim myśleć), prawdopodobnie dobrze jest unikać generycznych modeli widoku.

Nie wykluczaj ich całkowicie, jeśli uważasz, że istnieje sytuacja, w której ogólne modele widoku mogą być użyteczne, nie wahaj się przedstawić go tutaj, wyjaśniając scenariusz i pokazując cały kod abyśmy mogli to przedyskutować.

Answer 4

Naprawdę nie lubię umieszczać logiki biznesowej wewnątrz viewmodel. Myślę, że poza zwykłymi właściwościami i obsługą błędów wewnątrz konstruktora, nic nie powinno być w widoku modelu. Tworzy znacznie czystszy kod i możesz swobodniej tworzyć dodatki do modelu widoku. Jeśli masz dużo zduplikowanego kodu, możesz go wyizolować do oddzielnego widoku, a następnie zagnieździć go tam, gdzie jest potrzebny. W ten sposób masz tylko to, czego potrzebujesz na widoku.