Jaki jest „cykl życia strony” strony ASP.NET MVC w porównaniu z formularzami sieciowymi ASP.NET?

Jaki jest „cykl życia strony” strony ASP.NET MVC w porównaniu z formularzami sieciowymi ASP.NET?

Próbuję lepiej zrozumieć to „proste” pytanie, aby określić, czy istniejące strony, które mam w (bardzo) prostej witrynie, można łatwo przekonwertować z ASP.NET WebForms.

Poszukuję albo „konwersji” poniższego procesu, albo alternatywnego cyklu życia.

Co obecnie robię:

(tak, wiem, że każdy, kto jest w stanie odpowiedzieć na moje pytanie, już to wszystko wie - po prostu próbuję porównać `` cykl życia '', więc pomyślałem, że zacznę od wypełnienia tego, co wszyscy już wiemy)

Renderowanie strony:

• Mam stronę wzorcową, która zawiera mój podstawowy szablon
• Mam strony zawartości, które dają mi nazwane regiony ze strony wzorcowej, w której umieszczam zawartość.
• W module obsługi zdarzeń dla każdej strony treści ładuję dane z bazy danych (głównie tylko do odczytu).
• Wiążę te dane z kontrolkami ASP.NET reprezentującymi siatki, listy rozwijane lub repeatery. Wszystkie te dane „żyją” wewnątrz wygenerowanego kodu HTML. Część z nich trafia do ViewState (ale nie będę się w to zbytnio zajmować!)
• Ustawiam właściwości lub wiążę dane z określonymi elementami, takimi jak kontrolki Image lub TextBox na stronie.
• Strona zostanie wysłana do klienta renderowana jako kod HTML bez możliwości ponownego użycia.
• Staram się unikać używania ViewState innego niż to, czego strona potrzebuje jako minimum.

Po stronie klienta (bez korzystania z ASP.NET AJAX):

• Mogę użyć JQuery i kilku nieprzyjemnych sztuczek, aby znaleźć kontrolki na stronie i wykonać na nich operacje.
• Jeśli użytkownik wybierze z listy rozwijanej - generowane jest ogłaszanie zwrotne, które wyzwala zdarzenie C # w moim codebehind. To zdarzenie może przejść do bazy danych, ale cokolwiek zrobi, całkowicie nowo wygenerowana strona HTML kończy się wysyłaniem z powrotem do klienta.
• Mogę użyć Page.Session do przechowywania par klucza i wartości, których będę potrzebował później ponownie

Jak więc w przypadku MVC zmienia się ten „cykl życia”?

Spróbuję skomentować każdy z wymienionych przez Ciebie punktów:

Twoje strony wzorcowe nadal istnieją w MVC i służą do zapewniania spójnego układu witryny. niewiele tam nowego.

Twoje strony z treścią staną się widokami w świecie MVC. Nadal zapewniają te same obszary zawartości na stronach wzorcowych.

Obsługa zdarzeń formularzy internetowych nie powinna być używana w MVC, zamiast tego klasy kontrolera i ich metody akcji zajmą się ładowaniem danych do „modelu”, który jest przekazywany do widoku.

Chociaż powiązanie danych w stylu formularza internetowego jest możliwe w MVC, uważam, że nie jest to optymalne rozwiązanie. Lepiej jest umieścić dane w klasie modelu i zdecydowanie wpisać widok, aby mieć bezpośredni dostęp do tego modelu. Następnie wystarczy użyć <%= ViewData.Model.SomeProperty %>składni, aby uzyskać dostęp do danych i wyświetlić je w żądanych lokalizacjach. Jeśli chodzi o stan widzenia, radzę zapomnieć, że w ogóle istnieje.

Pamiętaj, że jedną z zalet korzystania z MVC jest to, że masz kontrolę nad kodem HTML, który wysyłasz do klienta. Przyjmij tę moc i spróbuj znaleźć rozwiązania, które pozwolą ci zachować tę kontrolę. Formanty formularzy internetowych próbują ukryć przed Tobą kod HTML i utrudniają dostosowywanie go w razie potrzeby.

Gorąco polecam JQuery lub jedną z innych podobnie potężnych bibliotek javascript. Ale naucz się ich używać, aby uzyskać bezpośredni dostęp do HTML DOM i uniknąć problemów związanych z manipulowaniem identyfikatorem w kontrolkach formularzy internetowych.

Możesz użyć jquery, aby podłączyć się do listy rozwijanej po stronie klienta i przesłać żądania standardowe lub w stylu Ajax. Żądanie to może zwrócić nowe strony, przekierowania, fragmenty html, a nawet dane JSON, których można użyć do zaktualizowania istniejącej strony.

W razie potrzeby można użyć sesji asp.net.