Czy webformy ASP.NET zostały przetoczone pod dywan, aby zrobić miejsce dla mvc?

Question

Przeczytałem cały marketing mówiący o tym, jak mvc i formularze internetowe są komplementarne itp.

Jednak wydaje się, że wszystkie blogi mówią o mvc, a jedynymi nowościami są mVC.

Czy Microsoft zamierza kontynuować POPRAWY formularzy internetowych jako obywatele pierwszej klasy, czy będzie to po prostu obsługiwana technologia, która z biegiem czasu przeniesie wszystkie swoje prawdziwe wysiłki, programistów i zasoby do MVC?

Czy w najbliższym czasie pojawią się jakieś nowe dowody na nowe ekscytujące ulepszenia?

Answer 1

Byłem na konferencji (Remix 08), a Scott Gu powiedział, że na pewno będą kontynuować wspieranie obu metod i że MVC nie jest odpowiednie dla każdej aplikacji. Scott powiedział, że było kilka nadchodzących ulepszeń dla modelu formularzy internetowych (chociaż nie mówili, co to było).

Model formularzy internetowych nie zniknie, ponieważ:
Model formularzy internetowych jest lepszy w przypadku niektórych typów aplikacji, np. małe aplikacje, wymagające długich procesów, które wykorzystują wyświetlanie stanu użytecznego
Wiele aplikacji korzysta z niej
wiele komponentów innych firm opracowanych dla niej
realizacja ASP.net nie jest jeszcze dojrzały (choć wydaje się dość dobrze do tej pory)

Microsoft prawdopodobnie ogłosi pewną liczbę nowych funkcji w PDC za kilka tygodni.

Answer 2

Microsoft wreszcie pogodzi się z jednym podstawowym faktem rozwoju. Nie możesz dostarczyć ostatecznego rozwiązania żadnego problemu. Właśnie dlatego MVC jest rozwijany, a Scott Guthrie wyraźnie stwierdza, że ​​MVC jest przeznaczone dla większych, bardziej korporacyjnych stron. Formularze internetowe będą nadal istniały i będą rozwijane jako proste, oparte na RAD podejście do tworzenia stron internetowych.

Jeśli cofniesz się o krok i przejrzysz wszystkie ostatnie ulepszenia i dodatki do stosu Microsoftu, możesz dość łatwo je zaklasyfikować pomiędzy tymi dwiema klasami. Np

• dostępu do danych: LINQ-SQL vs EntityFramework
• Remoting: WCF vs WebServices
• LiveID
: LiveID (WWW) uwierzytelnianie vs uwierzytelniania RPS
• ...

Mam tylko nadzieję, że Microsoft rozjaśni to rozróżnienie w czasie, ponieważ wydaje się, że wśród deweloperów panuje wiele nieporozumień co do tego, jakie narzędzie wybrać do danego zadania.

Podsumowując, myślę, że Microsoft będzie nadal rozwijać oba, ponieważ obsługują one różne profile programistów. Microsoft ma oczywiście duże zainteresowanie rozwijaniem swojej bazy programistów i uczynienia stosu .NET tak użytecznym, jak to tylko możliwe.

Answer 3

Mam zamiar wyjść tutaj i nie zgadzam się z ogólną ideą, że MVC jest tutaj "przedsiębiorstwem" lub jest jakoś lepiej z tych dwóch.

MVC jest świetny! Ale spójrz tylko na imię. Jest to skrót od "Model, View, Controller" ... widzisz tam "widok"?

Teraz spójrz na konkurs "Formy internetowe" ... zobacz "formularze" w tym jednym?

MVC wykonuje świetną robotę w sytuacjach typu "widok". W przypadku witryn, które publikują treści ("widoki" informacji), MVC prawdopodobnie ma przewagę, szczególnie w przypadku większych systemów, które wymagają wielu testów i bardzo formalnego projektu, aby wspierać inteligentne przełączanie widoku.

W przypadku aplikacji, które w znaczny sposób wchodzą w interakcję z użytkownikiem za pośrednictwem formularzy (gromadzenie danych i ciężkie aplikacje do wprowadzania danych), formularze internetowe mają przewagę dzięki nieodłącznemu wykorzystaniu postów formularzy jako podstawowego mechanizmu.

Chociaż można robić widoki za pomocą formularzy internetowych i można tworzyć formularze z MVC, każdy z nich ma kompromisy. W obecnym stanie MVC stwierdzam, że pisanie "widoków" na temat danych ciężkich jest o wiele trudniejsze i bolesne niż w przypadku formularzy internetowych ... i nie mam na myśli.

W przyszłości spodziewam się, że MVC będzie lepiej radzić sobie ze scenariuszami wprowadzania danych, ale te scenariusze prawdopodobnie będą miały dość wysoką cenę w porównaniu do tych z formularzami internetowymi.

Żaden z nich nie jest bardziej "korporacyjny" niż drugi, o ile mogę powiedzieć ... najbardziej interesują mnie aplikacje hybrydowe, które wykorzystują MVC do wyświetlania i publikowania końca działalności, podczas gdy formularze internetowe są wykorzystywane bardziej naturalnie do ciężkiego wprowadzania danych koniec ... wszystko w tym samym projekcie internetowym ... Mam nadzieję, że zobaczymy coś takiego.

Answer 4

Zanim zaczęły się pojawiać informacje o strukturze MVC, spędziliśmy dużo czasu w mojej firmie, rozwijając własne środowisko .NET MVC.

Było tak dlatego, że nie chcieliśmy ograniczać się przez ograniczenia abstrakcji WebForms - chcieliśmy uniknąć kompromitacji i interfejsu użytkownika, które WebForm wydaje się nakładać na wszystkie aplikacje najbardziej spersonalizowane. Chcieliśmy także przyjaznych identyfikatorów URI i chcieliśmy lepszej separacji front-end i back-endów niż te oferowane przez WebForms (zdecydowaliśmy się na architekturę XML/XSLT).

Moim zdaniem WebFormy w rzeczywistości oferują znacznie gorszą metodę interakcji z użytkownikiem w szczególności dzięki użyciu ViewState, PostBacks, itp., Które abstrakcyjne mechanizmy HTTP od dewelopera - to daje im mniejszą swobodę w w jaki sposób pozwalają użytkownikom na interakcję z systemem. Klasycznym przykładem jest to, że ponieważ strony WebForms prawie zawsze są wynikiem POST, jeśli użytkownik spróbuje odświeżyć stronę, użytkownik dostaje paskudne ostrzeżenie z przeglądarki. Wzorcem w tradycyjnym świecie projektowania stron internetowych do radzenia sobie z tym zawsze było włączenie dyrektywy przekierowania 302 w odpowiedzi HTTP, a więc trzymanie się pierwotnego paradygmatu HTTP GETs do pobierania danych, a POSTs do wysyłania danych. Inne, podobne problemy, takie jak niemożność posiadania dwóch formularzy na stronie (na przykład formularz logowania do witryny na innym serwerze).

To powiedziawszy, dla RAD, WebForms są genialne. Aktualnie pracuję nad aplikacją administratora dla aplikacji webowej, którą opracowaliśmy przy użyciu naszego niestandardowego środowiska MVC, a teraz sprawdzam, ponieważ potrzebuję tylko wyświetlić zawartość obciążenia tabel bazy danych, aw niektórych przypadkach pozwolić użytkownikowi edytować je na różne sposoby.

Myślę, że jeśli musimy przekonać samych siebie, że MS będą nadal wspierać WebForms - wystarczy pomyśleć o wszystkich byłych programistach Windows. Są to ludzie, dla których WebForms został pierwotnie opracowany i nie znikną. Twórcy oprogramowania będą twoim wybawcą, jeśli jesteś fanem WebForms.

Answer 5

Można zrobić gorzej niż spojrzeć na stanowisku Phil Haak jest od listopada:

The Future of WebForms and ASP.NET MVC

Wskazuje on, 5 kluczowych rzeczy anounced pod ASP.NET na PDC Prod

1. Infrastruktura podstawowa w tym skala i wydajność
2. Web Forms w tym problemów z identyfikatorami klienckim ViewState, wykorzystanie CSS, etc
3. AJAX
4. danych i danych dynamicznych
5. MVC

połączeniu z tym, nie są rzeczy, które zostały zbudowane jako część ASP.NET MVC, które zostały już wypuszczone na webformy takie jak moduł Routing, który będzie bardzo pomocny w niektórych moich projektach ts, nawet bez użycia MVC.

Co więcej, w VS2010 pojawiło się wiele zmian, które powinny pomóc twórcom stron internetowych w korzystaniu z WebForms lub MVC, co byłoby dobre.

Bloggerzy mają tendencję do mówienia o tym, co jest błyszczące i "nowe", tak to się dzieje - z tego powodu zobaczycie wiele słów, chociaż MVC nie jest niczym nowym - sięga co najmniej 30 lat.

To samo można powiedzieć o WPF/Silverlight - czy są to zabójcy WinForm/WebForms? Nie. Są to alternatywne oferty, z pewnymi korzyściami w porównaniu do wcześniejszego sposobu robienia rzeczy, ale także z pewnymi różnicami/wadami.