Kiedy faworyzować formularze ASP.NET WebForms nad MVC

189

Wiem, że Microsoft powiedział

ASP.NET MVC nie zastępuje formularzy WebForm.

Niektórzy programiści twierdzą, że WebForms jest szybszy niż MVC. Ale wierzę, że szybkość kodowania sprowadza się do poziomu komfortu dzięki technologii, więc nie chcę żadnych odpowiedzi w tym stylu.

Biorąc pod uwagę, że ASP.NET MVC daje programistom większą kontrolę nad aplikacją, dlaczego formularze WebForm nie są uważane za przestarzałe? Alternatywnie, kiedy powinienem preferować WebForms nad MVC dla nowego rozwoju?

53019
źródło
57
@Darknight: \ jest to stronnicze i po prostu złe. MVC nie jest przeznaczony do prostych aplikacji CRUD. Twierdzę, że WebForms jest przeznaczony dla ogólnych aplikacji CRUD (np. Baza danych -> kontrola błyszczącej siatki).
Raynos,
17
@Darknight cokolwiek cię uszczęśliwia -> jeśli podoba Ci się WebForms,
zwariuj na
16
@Darknight Najwyraźniej słabo rozumiesz MVC, jeśli taka jest twoja opinia ... Istnieje kilka ogromnych stron zbudowanych z mvc ... trochę badań, proszę pana.
Robotsushi
31
IMO, nigdy nie używaj formularzy internetowych, jeśli zamiast tego możesz użyć MVC.
scottschulthess
10
Nie jestem tym, który mówi, więc to tylko moja opinia. Po przeczytaniu większości odpowiedzi doszedłem do wniosku, że odpowiedź jest po prostu nigdy. MVC jest po prostu niesamowite, a jedyną wadą, jaką znalazłem, jest to, że wciąż widzę ;na mojej stronie (jeśli dopiero zaczynasz od Razor, dostaniesz dowcip).
MasterMastic 24.01.2013

Odpowiedzi:

105

Wydaje się, że Webforms vs. MVC to obecnie gorący temat. Wszyscy, których znam, reklamują MVC jako kolejną wspaniałą rzecz. Z moich drobnych wcieleń wydaje się, że jest w porządku, ale nie, nie sądzę, że to będzie koniec formularzy internetowych.

Moje rozumowanie i rozumowanie, dlaczego formularze internetowe byłyby wybierane zamiast MVC, mają więcej wspólnego z perspektywą biznesową niż z tym, co jest lepsze od drugiego.

Czas / pieniądze to największe powody, dla których formularze internetowe byłyby wybierane zamiast MVC.

Jeśli większość Twojego zespołu zna formularze internetowe i nie masz czasu na ich przyspieszenie w MVC, kod, który zostanie utworzony, może nie być wysokiej jakości. Nauka podstaw MVC, a następnie wskakiwanie i tworzenie złożonej strony, którą musisz zrobić, to bardzo różne rzeczy. Krzywa uczenia się jest wysoka, więc musisz uwzględnić to w swoim budżecie.

Jeśli masz dużą witrynę napisaną wyłącznie w formularzach internetowych, możesz być bardziej skłonny do tworzenia nowych stron w formularzach internetowych, aby nie mieć dwóch bardzo różnych typów stron w witrynie.

Nie twierdzę, że jest to podejście „wszystko albo nic”, ale utrudnia utrzymanie twojego kodu, jeśli istnieje podział na oba, szczególnie jeśli nie wszyscy w zespole znają MVC.

Moja firma niedawno zrobiła trzy strony testowe z MVC. Usiedliśmy i zaprojektowaliśmy je. Jednym z problemów, na jaki natrafiliśmy, jest to, że większość naszych ekranów ma funkcje Wyświetl i Edytuj na tej samej stronie. Potrzebowaliśmy więcej niż jednego formularza na stronie. Żadna wielka, chyba że nie użylibyśmy naszej strony głównej. Musieliśmy to zmienić, aby zarówno strony formularzy internetowych, jak i strony MVC mogły korzystać z tej samej strony głównej w celu uzyskania wspólnego wyglądu. Teraz mamy dodatkową warstwę zagnieżdżenia.

Musieliśmy stworzyć zupełnie nową strukturę folderów dla tych stron, aby działała zgodnie z prawidłową separacją MVC.

Czułem, że jest zbyt wiele plików na 3 strony, ale to moja osobista opinia.

Moim zdaniem wybrałbyś formularze internetowe zamiast MVC, jeśli nie masz czasu / pieniędzy, aby zainwestować w aktualizację swojej witryny w celu korzystania z MVC. Jeśli podejmiesz do tego połowiczne podejście, nie będzie to lepsze niż formularze internetowe, które masz teraz. Co gorsza, możesz nawet ustawić tę technologię na awarię w swojej firmie, jeśli zostanie zepsuta, ponieważ kierownictwo może postrzegać ją jako coś gorszego od tego, co wiedzą.

Tyanna
źródło
14
To dobra odpowiedź. Dałem ci +1, ponieważ twoje osobiste doświadczenia są doceniane. Ale jest to porażka z powodu braku doświadczenia / umiejętności programistów, których prosiłem o uniknięcie. Nie jestem przekonany, że Microsoft zdecyduje się nie oznaczać technologii jako przestarzałej z powodu obawy przed krzywą uczenia się dla MVC. Może tak być, ale nie jestem jeszcze przekonany.
P.Brian.Mackey
6
@ P.Brian.Mackey - Nie powiedziałem, że rozwój form jest szybszy niż MVC. Poprosiłeś, żebyś nie uwzględnił tego argumentu. Innym argumentem jest poświęcanie czasu i pieniędzy na szkolenie personelu. MS nie oznaczy formularzy internetowych jako przestarzałych z jednego ważnego powodu: Klienci korporacyjni spędzili lata rozwijając klientów internetowych w formularzach internetowych i nie będą wyglądać uprzejmie z powodu konieczności inwestowania czasu i pieniędzy na aktualizację.
Tyanna
16
@Raynos - Jeśli wszyscy w zespole byli biegli w MVC, a Twoja firma rozpoczyna nowy projekt, to jedynym powodem, dla którego widzę, że ktoś wybiera formularze internetowe, jest osobisty wybór.
Tyanna,
3
Obie technologie znam dokładnie. Wszystkie moje projekty internetowe są wykonywane za pomocą mvc i pracuję w firmie, w której mam swobodę robienia wszystkiego, co najlepsze. Zawsze wybieram MVC.
Robotsushi
6
Zacząłem od formularzy internetowych i kiedy odkryłem MVC, przełączyłem się na to. Nie wiem, jak ktokolwiek mógłby bronić formularzy internetowych. Cykl życia strony i jeden formularz dla całej strony? Czy ty żartujesz? Konstruktor witryn Yahoo był prawdopodobnie jego klientem, ale nawet oni nie chcieli tego śmiecia.
The Muffin Man
188

Tworzyłem aplikacje ASP .Net WebForms przez 3 lata, a po jednym dniu prowadzenia samouczka MVC zostałem sprzedany. MVC jest prawie ZAWSZE lepszym rozwiązaniem. Dlaczego?

  • Cykl życia strony jest prostszy i bardziej wydajny
  • Nie ma czegoś takiego jak kontrolki poza kontrolkami HTML. Nie trzeba debugować danych wyjściowych, aby zobaczyć, co generuje ASP .Net.
  • ViewModels daje ogromną moc i eliminuje potrzebę ręcznego wiązania i eliminuje wiele błędów związanych z wiązaniem.
  • Na stronie możesz mieć wiele formularzy. To było poważne ograniczenie WebForms.
  • Sieć jest bezstanowa, a MVC bardziej pasuje do architektury sieci. Formularze internetowe wprowadzają stan i związane z nim błędy, wprowadzając ViewState. ViewState jest automatyczny i działa w tle, więc nie zawsze działa tak, jak chcesz.
  • Aplikacje internetowe muszą obecnie współpracować z ajax. Niedopuszczalne jest już ładowanie całej strony. MVC sprawia, że ​​ajax jest o wiele lepszy, łatwiejszy i wydajniejszy dzięki JQuery.
  • Ponieważ możesz mieć wiele formularzy na stronie i ponieważ architektura jest sterowana przez wywołania adresów URL, możesz robić funky, takie jak ajax, ładować inny formularz, na przykład edytować formularz na bieżącej stronie za pomocą JQuery. Kiedy zdasz sobie sprawę, co to umożliwia, możesz z łatwością robić niesamowite rzeczy.
  • ASP .Net WebForms to nie tylko abstrakcja w formacie HTML, ale także niezwykle złożona. Czasami dostajesz dziwny błąd i walczysz z nim o wiele dłużej niż to konieczne. W wielu przypadkach można było zobaczyć, co robi źle, ale nie można nic z tym zrobić. W końcu robisz dziwne obejścia.
  • WebForms nie tworzy dobrej technologii dla projektantów. Projektanci często lubią pracować bezpośrednio z HTML. W MVC jest to widok, w WebForms to pół dnia pracy.
  • Ponieważ platforma internetowa ewoluuje szybko, formularze internetowe nie nadążą. Nie jest świadomy nowych tagów ani funkcji HTML5, nadal będzie renderować te same rzeczy, chyba że dostaniesz (często) drogie kontrole innych firm lub nie poczekasz, aż Microsoft wyda aktualizację.
  • Formanty w formularzach internetowych ograniczają Cię na wiele sposobów. W MVC możesz po prostu pobrać bibliotekę JQuery i zintegrować ją z szablonami.

Wiem, że niektóre z powyższych problemów zostały w pewnym stopniu rozwiązane w miarę ewolucji WebForms, ale takie było moje pierwotne doświadczenie. Podsumowując, bardzo trudno byłoby mi znaleźć uzasadnienie biznesowe dla formularzy internetowych, chyba że projekt już z nich korzysta.

Tjaart
źródło
6
+1 za wskazanie wielu formularzy. Dodatkowo fakt, że generują formularze HTML, jest w większości przypadków mało przyjazny dla SEO (jak w: duże fragmenty stanu wyświetlania na górze strony)
jao
4
Muszę w 100% zgodzić się z tą odpowiedzią. Ostatecznie WebForms znacznie trudniej robi rzeczy po stronie klienta (HTML / przeglądarka). Musisz dosłownie walczyć z ramami, aby coś zrobić. Strona aspx kończy się o wiele więcej kodu z powodu kontroli serwera niż zwykle strona cshtml. @ šljaker Jeśli zaczniesz wyłączać ViewState i unikniesz kontroli serwera, w tym momencie porzuciłeś wiele formularzy internetowych. Nie uważam tego argumentu za szczególnie przekonujący.
Andy,
12
Możesz mieć proste formanty HTML w WebForms, nikt nie zmusza cię do korzystania z kontrolek serwera. Możesz mieć pełny bezstanowy formularz internetowy, nikt nie zmusza cię do korzystania z ViewState. Możesz używać pełnej ajax i jQuery w formularzach internetowych, nikt nie ogranicza ci używania jQuery. Możesz zaimplementować routing URL, nikt nie zmusza Cię do korzystania z podstawowego adresu URL pliku statycznego. Ręczne rysowanie strony za pomocą CSS zajmuje tyle czasu, ile potrzeba MVC. Możesz zaprojektować stronę HTML bezpośrednio w formularzu internetowym.
mjb
5
@mjb: Jeśli nie używasz kontrolek serwera, ViewState itd., po co w ogóle używać WebForms, gdy MVC jest bliżej tego, co robisz? To jak jazda ciągnikiem do pracy, ale nie jazda w terenie, używanie łopaty / motyki lub stabilizatora. W tym momencie dlaczego po prostu nie korzystać z samochodu?
Nelson Rothermel
3
@ Tjaart To nie w porządku, że nie możesz mieć wielu formularzy na stronie ASPNET. Możesz mieć tyle formularzy, ile chcesz na stronie ASPNET, ale możesz mieć tylko jeden formularz serwera - formularz z atrybutem runat = "server".
Kuncevic,
80

Wysłałem e-mail do Scotta Guthrie , eksperta MVC w firmie Microsoft. I prawdopodobnie najbardziej wykwalifikowany człowiek, aby odpowiedzieć na to pytanie. Był na tyle uprzejmy, że odpowiedział:

„Różni klienci szukają różnych podejść programistycznych i wielu z nich uwielbia formularze internetowe i uważają, że jest świetny. Inni uwielbiają MVC i uważają, że jest świetny. Dlatego inwestujemy w oba”.

Tak więc dla mnie to mówi, że to nie jest problem techniczny. To bardziej „miękki problem”, jeśli chcesz. Jedna z osobistych preferencji. Jest to zgodne z tym, co powiedziało kilku z was.

Dziękuję za wszystkie odpowiedzi.

rev. P.Brian.Mackey
źródło
12
Scott Guthrie wynalazł platformę MVC dla ASP.NET podczas lotu powrotnego z Londynu do Seattle w sezonie 2006/7. Jeśli się nad tym zastanowić, wynalazł również .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Nazywanie go „ekspertem” to ogromne niedopowiedzenie ;-)
Benjamin Howarth
27
To miła polityczna odpowiedź od Scotta Guthrie. Gdyby on sam zainwestował własną aplikację internetową, zobaczyłby projekt MVC i dla wszystkiego, czego nie można by zrobić w MVC, Silverlight byłby awarią. Nie traktuj tego jako negatywnego komentarza do WebForm, myślę, że WebForm są idealne dla mniejszych aplikacji wewnętrznych, które mogą korzystać z komponentów innych firm, takich jak te stworzone przez Telerik. Cieszę się, że Microsoft rozwija obie technologie.
Sean Chase
10
„Scott Guthrie wynalazł środowisko MVC dla ASP.NET podczas lotu”. Myślę, że to naprawdę trywializuje MVC. Nie znam Scotta Guthrie, ale mogę się założyć, że zastanawiał się, jak MVC może zostać zaimplementowany w ASP.NET od dłuższego czasu i wykorzystał ten długi lot, aby zaimplementować prototyp gołej kości jako dowód koncepcji.
John MacIntyre
6
„Dlatego inwestujemy w oba”. A kiedy zobaczymy, że formularze internetowe zaczynają się odrzucać, bezlitośnie je porzucimy, ponieważ inwestowanie w ostatecznie martwy produkt nie leży w naszym najlepszym interesie biznesowym.
Quandary
Dopóki nie będzie już nauczany w szkołach, przez wiele lat będzie zawsze obowiązywał w świecie biznesu. Uczelnie i licea nadal oferują kursy wprowadzające i zaawansowane w vb.net. Nigdzie się nie wybiera !!!
htm11h
44

To jest stare pytanie z wieloma odpowiedziami, ale żadne nie miało odpowiedzi, której oczekiwałbym na liście.

Krótka odpowiedź brzmi:

  • Użyj ASP.NET MVC, jeśli zamierzasz poprawnie zbudować aplikację internetową z nowoczesnymi konwencjami programowymi i wzorcami przyjętymi w branży dla platformy ASP.NET. Z drugiej strony będziesz musiał wiedzieć, jak działają HTML i zasoby po stronie klienta (JavaScript, CSS), a także zwiększyć sposób myślenia programistycznego MVC, który ma stromą krzywą uczenia się, ale po nagłym osiągnięciu nagłego końca.
  • Użyj formularzy sieci Web ASP.NET, jeśli używasz lub chcesz użyć koncentrującego się na graficznym interfejsie użytkownika , RAD (Rapid Application Development) , metody „przeciągnij i upuść” do szybkiego tworzenia prototypów czegoś, tj. Zachowania przycisku / siatki danych 15 minut, a rozwiązanie nie jest przeznaczone dla programistów. Lub użyj formularzy sieci Web ASP.NET, jeśli masz doświadczenie w tworzeniu GUI lub Windows Forms i chcesz przenieść swoją wiedzę do sieci.

Ale aby spojrzeć na to właściwie, musisz zrozumieć historię każdego z nich.

Formularze internetowe ASP.NET były odpowiedzią Microsoftu na osoby budujące dynamiczne aplikacje internetowe przy użyciu formantów ActiveX Visual Basic 6, bibliotek DLL VB6 na serwerze i ASP Classic. W tym czasie tworzenie stron internetowych przy użyciu tych narzędzi Microsoft było prawdziwym bałaganem. Wraz z całym programem .NET Framework, który był efektem powrotu Microsoft do tablicy kreślarskiej dotyczącej produktywnego programowania biznesowego na stosie Windows, ASP.NET Web Forms był w swoim czasie niesamowity i piękny.

Całe podejście polegało na tym, aby dać programistom to, co najlepsze z obu światów, w czymś bardzo podobnym do tworzenia aplikacji Windows, ale z mocą usług internetowych. Pomysł polegał na tym, że podobnie jak w „formularzu” VB6 / WinForms (okno), podobnie strona internetowa jest formularzem (podobnie jak okno, patrz) , i na tym formularzu można przeciągać i upuszczać etykiety, pola tekstowe, siatki danych, przyciski i inne rzeczy, do których byli przyzwyczajeni programiści VB / WinForms.

Aby przycisk coś zrobił, po przeciągnięciu go i upuszczeniu wystarczy kliknąć go dwukrotnie w projektancie i wysiąść w edytorze kodu, informując formularz, co zrobić, gdy nastąpi zdarzenie „kliknięcia”. W taki właśnie sposób programiści Windows GUI stworzyli oprogramowanie za pomocą narzędzi GUI VB6 i konkurencyjnych narzędzi, tyle że teraz kod działa na serwerze! Łał!

To była technologia z 2002 roku. Niesamowite i piękne w swoim czasie jako odpowiedź na rozwiązania GUI z dostępem do Internetu do tworzenia aplikacji RAD , wprowadziło poczucie władzy do bałaganu w świecie programistów, którzy mieli cele biznesowe, które musieli osiągnąć.

Niestety, ten model programowania podkreśla tak bardzo metaforę programowania GUI w systemie Windows, że niesie ze sobą ciężar niezbędnych szczegółów implementacyjnych, cały bagaż, który jest niezbędny, aby pomieścić cykle życia zdarzenia i schowanie brzydkich szczegółów prostego HTML i skrypt wygenerowany przez te komponenty i kontrolki przeciągnij i upuść. A pod koniec dnia programiści obsługujący prawdziwe aplikacje nieuchronnie musieli zagłębić się w te komponenty lub napisać własne, w wyniku czego będą walczyć w bitwach z tą infrastrukturą, bitwach, które pozostawiają stosy na stosach cruft, ciągniętych włosów i łzy.

Utworzyć kopię zapasową. Umyj ręce. Spójrzmy jeszcze raz na problem biznesowy. Jakie są nasze cele biznesowe?

Musimy budować i zarządzać aplikacjami internetowymi . Nasze ograniczenia są takie, że mamy sieć WWW, która działa na HTTP, HTML, JavaScript i CSS, a na serwerze mamy reguły biznesowe, bazy danych i kilka świetnych języków programowania (np. C #). Czy naprawdę potrzebujemy tej metafory interfejsu GUI systemu Windows, aby napędzać naszą metodologię programowania? Dlaczego nie możemy skupić się na problemach z aplikacją i pozbyć się metafor GUI?

W tym momencie wkracza ASP.NET MVC. Zaczęło się od buntu programistów, którzy nazwali siebie „Alt.Net”, którzy chcieli wrócić do właściwych i czystych zasad tworzenia oprogramowania. Nigdy więcej kłopotów i kłopotów, po prostu skup się na celach biznesowych i najlepszych praktykach oprogramowania.

To, co tak naprawdę przekłada się w tym przypadku, to:

  1. Rozdzielenie obaw . Na przykład komponent danych nie musi wiedzieć, w jaki sposób będą renderowane jego dane, ani nie należy obciążać widoku znaczników szczegółami konfiguracji połączenia z bazą danych, dzięki czemu programista może skupić się na swoim obszarze zainteresowania podczas edycji i kod testowy.
  2. Ekspozycja i pełne wsparcie dla ekspozycji na drobiazgi HTML i powiązanych zasobów . W formularzach internetowych HTML jest schowany, a programiści zniechęcają się do tego. W ASP.NET MVC programiści są raczej zachęcani do zarządzania tymi szczegółami; w rzeczywistości jest to konieczność. Zaletą jest to, że programista może ponownie nauczyć się doceniać czystą semantykę HTML, CSS i skryptu i pracować z nim, a nie z nim.
  3. Testowalność obiektów biznesowych . Kontrolery i modele są znacznie lepiej przystosowane do programowego testowania jednostkowego, dzięki czemu można zweryfikować implementacje pod kątem realizacji celów biznesowych, a zmiany można zweryfikować, czy się nie złamią. Z Formularzami internetowymi trudno było przetestować, ponieważ komponenty nie zostały zaprojektowane do testowania indywidualnie, a cała twórczość koncentrowała się wokół formularzy stron i cykli życia ich zdarzeń, a logika biznesowa i logika prezentacji były ze sobą ściśle powiązane.

Zauważ, że HTML jest już językiem znaczników wysokiego poziomu, podobnie jak JavaScript jest językiem programowania wysokiego poziomu. Cała historia byłaby inna, gdybyśmy mieli do czynienia z językiem asemblera i C.

Rozwijając się na # 2, kolejnym celem ASP.NET MVC jest umożliwienie programistom zorganizowania szczegółów front-end części „zobacz” swoich rozwiązań i skorzystania z bogatych podstaw, na których reszta branży zbudowała platforma klienta front-end.

Przekonasz się, że programiści ASP.NET MVC czują się jak w domu, korzystając z bogatych bibliotek JavaScript i technik szablonów po stronie klienta, bez walki z architekturą po stronie serwera. Nie było tak pierwotnie w przypadku formularzy internetowych ASP.NET, ponieważ formularze internetowe nie chcą, abyś w ogóle patrzył na HTML lub skrypt, z wyjątkiem sytuacji, gdy naprawdę musisz się wystrzegać, w takim przypadku uważaj, to nie jest dla słabych z serca.

stymulacji77
źródło
To dobra odpowiedź, ale # 1 i # 2 są błędne (WF nie wymaga komponentu, aby wiedzieć, skąd pochodzą jego dane, jest to opcja i zawsze dodawałeś HTML do plików ASPX, aby obsługiwać tagi asp, którym jesteś renderowanie. Nigdy nie musisz kopać głęboko i walczyć z kontrolkami, chyba że próbujesz uzyskać dostęp do funkcji ASP nieprzeznaczonej do interakcji programistów. Najważniejsze są testowalność i wzorzec projektowy.)
Trisped
39

Jestem całkowicie i całkowicie przekonwertowany na ASP.NET MVC i nie oglądałem się za siebie, ale powiedziałem, że nadal muszę utrzymywać kilka bardzo dużych aplikacji WebForms. Oto moje zdanie na ten temat:

Formularze internetowe
Użyj ich, jeśli masz poważne ciężkie podnoszenie związane z siatkami. Kontrolki siatki są naprawdę bardzo ładne, gdy masz prosty zestaw danych, który ładnie pasuje do formatu tabelarycznego i chcesz zapewnić użytkownikom prosty sposób aktualizowania rekordów. Tak, wiem, że MVC 4 ma naprawdę niesamowitą rzecz typu Ajax, z której można korzystać, co działa świetnie, ale w naszej firmie często musimy wczoraj coś uruchomić, a dobre staromodne siatki działają świetnie, a użytkownicy są szczęśliwi, że mogą być z radością tabulować na siatce. Dla mnie to naprawdę najlepsza rzecz w WebForms; ale jak Ryanzwróciłem uwagę, że WebFormy mogą być wielkim bałaganem, ponieważ grasz po obu stronach ogrodzenia ze sprytnego pliku za kodem. Może to być zarówno róża, jak i cierń w tym samym czasie, aby utrzymać wszystkie rzeczy typu kontrolera zmieszane z Twoimi widokami.

MVC
Skorzystaj z tego, jeśli naprawdę chcesz stworzyć własne i masz możliwość uruchomienia aplikacji od zera. Posiadanie jasno określonej aplikacji MVC wymaga nieco więcej pracy, ale jej zalety w zakresie konserwacji przewyższają początkowy koszt instalacji. Jeśli chcesz robić ciekawe interakcje z Ajaxem, wolisz napisać swój model z kodem, takim jak czysty adres URL i trasy, i mieć możliwość kontrolowania całego przepływu aplikacji, to zdecydowanie jest to najlepsza droga. Na początku trzeba się przyzwyczaić, ale myślę, że jest to lepsza opcja dla aplikacji typu greenfield.

Podsumowując, dla mnie sprowadza się to do gridów i! Grids. :)

Nodey The Node Guy
źródło
+1 za ładne zdjęcie dostarczone z „odtwarzaniem obu stron ogrodzenia ze sprytnego pliku z kodem”.
Marcel
Ten bardzo pomocny. Robię bardzo ciężką aplikację opartą na siatce i wykluczyłem silverlight, xbap i to było sprowadzone do show między tymi dwoma.
frostymarvellous
15

Moje doświadczenie:

  • Napisałem projekty CakePHP przez rok.
  • Ukończono średniej wielkości projekt Webforms w ciągu sześciu miesięcy.
  • Przez trzy lata pracował nad projektem Windows Forms.

Po tym doświadczeniu próbowałem napisać kolejną aplikację za pomocą formularzy internetowych i odczułem frustrację po około jednym dniu zmagania się z tym, jak formularze internetowe próbują chronić programistę przed rzeczywistością, w której opracowują aplikację wykorzystującą HTML, JavaScript i CSS.

Potem wypróbowałem MVC i mając większą bezpośrednią kontrolę nad wyjściem (i trochę doświadczenia z paradygmatem MVC z CakePHP) byłem w stanie ukończyć tę prostą aplikację dokładnie tak, jak chciałem, w około 1/2 dnia.

Dostępność potężnych frameworków interfejsu użytkownika, takich jak jQuery, bardzo eliminuje atrakcyjność rezygnacji z bezpośredniej kontroli danych wyjściowych na rzecz używania często obszernych, wstępnie zbudowanych komponentów interfejsu użytkownika.

mootinator
źródło
2
@JimG - Uhh, wszystko, co wiąże się z wprowadzaniem rekordów bez ciekawych skojarzeń do bazy danych i zmuszaniem tej osoby lub innej osoby do czytania / drukowania ich w innym miejscu, może być zasadniczo rusztowane przy użyciu frameworka MVC. To prawda, że ​​nie jest to większość aplikacji, ale jest o wiele więcej niż można zrobić z Formularzami. Chyba twoje -1 potwierdza mój punkt widzenia.
mootinator
1
To 1/4 dnia.
mootinator
1
Ale jeśli wymagania są następujące: „Potrzebuję aplikacji z dwiema rolami, jedna do rejestrowania niektórych informacji, druga do ich przeglądania, a tak naprawdę nie dbam o to, jak to wygląda”. Tak, to całkiem wykonalne.
mootinator
3
przepraszam, ale opracowanie aplikacji internetowej do wprowadzania danych i przeglądania danych jest tak proste, że można to zrobić w ciągu kilku godzin. utworzenie struktury aplikacji MVC, kontrolerów, widoków i działań, zajęłoby tyle samo czasu, ale nie doprowadziłoby cię do ukończenia produktu.
Dementyczny
2
@Dementic Zwykle dla prostej aplikacji MVC buduje się modele, a następnie kontrolery i widoki rusztowań i / lub generuje kontrolery / widoki rusztowań. Nic tak naprawdę czasochłonnego.
mootinator
8

Wolę formularze internetowe, ponieważ moim tłem jest tworzenie okien.

Szybkość programowania jest kluczową kwestią i mogę łatwo przekazać problem komuś w Indiach, aby naprawić go za pomocą formularzy, a także, jeśli mam problem z szybkością na stronie, przydatna jest naprawdę dobra książka o szybkości asp.net (Rick Kiessig to mężczyzna).

webforms jest dla ex windows people mvc jest dla ludzi web

ale we współczesnym świecie, w którym Rick napisał niesamowitą książkę, z codziennymi serwerami zwiększającymi szybkość i tanimi koderami w Indiach, cóż, formularze internetowe mają przewagę

Jason Palmer
źródło
7

Moje 2 centy to zawsze używać ASP.NET MVC do nowych projektów, jeśli masz taką opcję. Moim zdaniem formularze internetowe nie są dobrym sposobem na tworzenie aplikacji internetowych, kropka.

Myślę, że wyodrębnianie podstawowego REST jest złe, cały model postback jest zły, sposób, w jaki html / css jest obsługiwany przy użyciu edytora GUI, jest zły, nacisk na takie rzeczy jak kreatory i GUI do konfigurowania jest zły, adresy URL są złe.

scottschulthess
źródło
czy możesz wyjaśnić bardziej szczegółowo, dlaczego tak uważasz?
komar
myślę, że abstrakcyjne REST powróciło, cały model postback powrócił, sposób, w jaki html / css jest obsługiwany przy użyciu edytora GUI, jest zły, nacisk na takie rzeczy jak kreatory i GUI do konfigurowania jest zły, adresy URL są złe itp. itd.
scottschulthess
6

Przeczytałem wszystkie odpowiedzi i uważam, że moje osobiste doświadczenie dodałoby coś do powyższych odpowiedzi.

3-4 lata temu opracowałem 2-3 projekty stron internetowych przy użyciu formularzy internetowych. W tym czasie MVC nie było w pobliżu lub o tym nie słyszałem. Rozwój był naturalnie (pochodziłem z programowania Win-form bez wcześniejszego doświadczenia w tworzeniu stron internetowych) dla mnie szybki, ponieważ nie muszę uczyć się szczegółów HTML i kontrola sieci bardzo mi pomogła (do diabła, to ułatwiło życie) .

Teraz, po tak długim czasie, do niedawna nie pracowałem nad żadnym projektem internetowym i jedynie budowałem aplikację Windows za pomocą WPF.

Kilka dni temu wpadłem na pomysł strony internetowej i pomyślałem o jej rozwoju: tym razem w MVC (ponieważ wszędzie o niej mówiono, poza tym musiałem się uczyć, więc wybrałem MVC). Projekt jest wciąż w fazie rozwoju, ponieważ wciąż się uczę i buduję razem.

Tak więc, Kluczowe różnice, które znalazłem czarno-białe, są następujące: -

  • Dla kogoś pochodzącego z rozwoju systemu Windows formularze internetowe będą zawsze korzystne. Krzywa uczenia się Asp.net dla programisty Windows jest nieco stroma

  • Dla kogoś pochodzącego z rozwoju sieci w innej technologii, MVC będzie faworyzowane, ponieważ kpi z najnowszej z nich wszystkich.

  • Programowanie jest łatwiejsze i czystsze w MVC, jeśli masz dobrą znajomość HTML i CSS

  • Wdrożenie nadal stanowi problem. W formularzach internetowych wystarczyło skopiować i wkleić. Ale to wymaga pewnych rzeczy do zrobienia.

Krótko mówiąc, oboje zostaną tu na chwilę.

Pankaj Upadhyay
źródło
6

Nie widziałem jeszcze tego rozważania wśród istniejących 15 odpowiedzi na ten wątek, ale myślę, że warto to rozważyć.

Z mojego doświadczenia wynika, że ​​formularze internetowe są bardziej podobne do Win Forms i WPF niż MVC. Biorąc to pod uwagę, myślę, że można rozważyć wybór formularzy internetowych, gdy zespół ma największe doświadczenie w tego rodzaju technologiach lub gdy projekt formularzy internetowych zapewni interfejs do tego samego zestawu danych, co istniejące (lub jednocześnie opracowywane) formularze wygrywające lub Projekt WPF. Dzięki temu programiści mogą łatwiej przechodzić między projektami, ponieważ logika aplikacji może być między nimi podobna.

Jak wskazały inne odpowiedzi, rozwój w środowisku MVC jest bardziej podobny do tworzenia stron WWW w Ruby, PHP, Python itp. Niż w jego odpowiednikach Microsoft; tak więc na wybór MVC może mieć wpływ doświadczenie zespołów w tych obszarach, a także czynniki przedstawione w innych odpowiedziach.

Andy Hunt
źródło
+1 Z pewnością rozsądny argument dla formularzy internetowych. Obawiam się, że zespoły kierują się tym sposobem myślenia, aby uniknąć uczenia się nowych rzeczy. MVC jest wypełnione wieloma wzorami, które mogą być nieznane zespołowi. Poznanie tego rodzaju wzorców i ich wdrożenie prowadzi do lepszego przestrzegania zasad SOLID, co przekłada się na lepszą ogólną łatwość konserwacji. Te sprawdzone techniki są również prawdziwym kluczem do ponownego użycia.
P.Brian.Mackey
3

Powodem, dla którego nie zdecydowaliśmy się na MVC kilka lat temu, była niedojrzała technologia firmy Microsoft. W ciągu ostatnich kilku lat jesteśmy teraz w bardziej dojrzałej wersji (4) i wydaje się, że stwardnienie rozsiane opracowało, dokąd zmierzają. Nadal jednak niechętnie rozwijamy główne aplikacje LOB przy użyciu MVC, ponieważ funkcje, których chcemy używać w wersji 4, wymagają serwera Windows 2012 (ponownie gniazda sieciowe za pośrednictwem IIS8). Wydaje mi się, że za 1 rok będziemy bardziej akceptować MVC, ponieważ mam nadzieję, że będzie dostępnych więcej kontroli stron trzecich, technologia się ustabilizuje i będziemy mieli infrastrukturę do jej obsługi.

Steve
źródło
1
Czy mógłbyś wymienić niektóre z tych funkcji, które według Ciebie wymagają systemu Windows Server 2012?
MikeTeeVee
2

Ta decyzja zależy od twoich preferencji, twoich wymagań, a nawet twojej wiedzy i doświadczenia.

Czas na szkolenie do nauki MVC lub czas na dostawę. Wszystkie te rzeczy mają znaczenie, aby wybrać jedno lub drugie podejście.

Nie jest tak, że jedno jest lepsze od drugiego, po prostu zarówno podejście, jak i ramy mają wady i zalety.

Osobiście preferuję MVC 3, polecam spróbować swoich własnych doświadczeń, ale muszę powiedzieć, że program w MVC jest czysty, zabawny, elastyczny, rozszerzalny, bezpieczny i ustrukturyzowany.

Pozdrowienia,

pacoespinoza
źródło
2

Jedyny powód, dla którego wybrałbym WebForms zamiast MVC, to fakt, że masz znacznie więcej kontrolek UI firm trzecich dla WebForms niż MVC. Wybrałem MVC, ponieważ zbyt dużo pracowałem z WebForms i chcę pracować z czymś świeżym / nowym, ale wciąż ze sklepu MS :)

Zasadniczo nic nie stoi na przeszkodzie, aby wyłączyć stan widoku w WebForms i użyć ViewModels i pętli if / for zamiast wiązania modelu i kontroli po stronie serwera.

Czy to jest WebForms lub kod MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

Jedynym ograniczeniem, jakie znalazłem w WebForms, jest to, że jeśli używasz Dependency Injection / Inversion of Control, nie możesz mieć zastrzyku konstruktora, ponieważ strony WebForms muszą mieć konstruktora bez parametrów, więc musisz użyć zastrzyku właściwości. Czy to naprawdę taka wielka sprawa?

šljaker
źródło
1

ASP.NET MVC to naprawdę odpowiedź na Ruby, a także nowy, modny i (IMO) lepszy sposób na jak największe oddzielenie przeglądarki (klienta) od serwera.

ASP.NET Webforms daje dużą kontrolę nad klientem od strony serwera, z bezpośrednim dostępem do prawie wszystkiego. Zasadniczo twój widok i kontroler są jednym w tym samym, co daje dużo mocy, a większość razy dużo bałaganu.

Program ASP.NET MVC oddziela widok i kontroler, odłączając ścisłe połączenie pliku .aspx i pliku .aspx.cs, który towarzyszy im w formularzach internetowych.

Zasadniczo różnica polega na tym, że znacznie więcej (zazwyczaj wszystkie) przetwarzania ma wyświetlać dane do pliku widoku, i pozostawia logikę biznesową i resztę w kontrolerze, utrzymując je w czystości zgodnie z konwencją, ale także z mniejszym dostępem do każdego z nich inne niż pozwala na to formularze internetowe.

Ryan Hayes
źródło
KIEDY zatem należy preferować formularze internetowe zamiast MVC? To nie odpowiada na oryginalne pytanie dotyczące plakatów.
Steven Striga
@WeekendWarrior - Jeśli chcesz uzyskać większy dostęp do klienta po stronie serwera, wybierz formularze internetowe. Jeśli chcesz więcej oddzielania klienta / serwera w swoim kodzie, wybierz MVC. Pod koniec dnia oboje robią dokładnie to samo. Filtry przekierowania robią to samo, co adresy URL MVC. Możesz przenieść kod formularza internetowego do osobnej warstwy środkowej, aby go bardziej oddzielić. weblogs.asp.net/scottgu/archive/2010/01/24/…
Ryan Hayes
Jeśli chodzi o twój trzeci punkt, logika biznesowa kończy się w pliku .aspx.cs - myślę, że to wina programistów. Nie ma / nie powinien tam być. W formularzach internetowych .aspx jest „widokiem”, a .aspx.cs jest odpowiednikiem „kontrolera”, przeznaczonym do przetwarzania kodu bezpośrednio związanego z interfejsem użytkownika przez odpytywanie warstwy biznesowej lub gruboziarnistej biznesowej fasady. Fakt, że ludzie umieszczają logikę biznesową w .aspx.cs, jest po prostu kiepskim programowaniem. Mogą również umieścić logikę biznesową w widoku MVC! MVC nie wymusza separacji tych rzeczy.
James
Zasadniczo ma on więcej racji niż inne odpowiedzi zamieszczone tutaj. ASP.net jest podstawową ideą stojącą za modułową rodziną technologii sieciowych stworzoną przez Microsoft. Moduł ASP.net MVC może być chwilowym szumem, ale na pewno nie jest to ostatni, wszystko zaczyna się od ASP.net, więc kiedy wybrać ASP.net, jeśli nie uważasz, że MVC nie jest twoją rzeczą, być może bardziej w coś w przeciwnym razie OWIN lub ..., coś bardziej zaawansowanego, lub stworzyło własne ramy dla swoich zadań. Być może nawet nie potrzebujesz ASP.MVC i pomiń go i idź Owin lub Katana, ale do tego czasu użyj asp.net
user3800527
1

Moim zdaniem są one wystarczająco powiązane i mają w przybliżeniu te same możliwości, które sprowadzają się do preferencji.

Świetny programista WebForms może wyprodukować produkt równie potężny jak wielki programista MVC. Ale wielki programista WebForms, próbujący zmusić się do przyjęcia MVC, wkrótce się pojawi. To samo dotyczy świetnego programisty MVC, który daje WebForms szansę.

Nie są to całkowicie odrębne jednostki i dopóki Microsoft będzie w dalszym ciągu wspierać oba, wierzę, że nadal będzie można zobaczyć mieszaną grupę wyjątkowych programistów dla każdego.

użytkownik29981
źródło
0

Chodzi o osobisty wybór, zakładając, że wszyscy jesteśmy biegli w używanej technologii. Od wielu lat stosuję podejście do projektowania WebForms i muszę powiedzieć, że jedynym minusem jest to, że z powodu jego uproszczonego podejścia wiele osób nie poświęca czasu na odkrycie jego ogromnych możliwości.

Niedawno użyłem MVC do ukończenia projektu i chociaż bardzo podoba mi się podejście projektowe do tworzenia aplikacji (które daje większą kontrolę, czyste adresy URL, SOC itp.), Tak naprawdę nie ma wiele, czego nie zapewnia WebForms. W rzeczywistości pojawienie się jQuery i jego działanie z WebForms (a także MVC) sprawiło, że te argumenty stały się mniejszym problemem. A kiedy ludzie mówią o rozdzieleniu problemów jako przewadze MVC nad MVP, pytam ich, ile wiedzą o programowaniu obiektowym i jak bardzo wykorzystali zasadę abstrakcji i polimorfizmu.

Obecnie czuję się swobodnie, używając obu technologii, i wybieram i wybieram na podstawie sytuacji. Szczerze mówiąc, to zależy od ciebie, ale prawda jest taka, że ​​nie wszyscy poświęcają czas, aby dowiedzieć się dogłębnie, do czego jest zdolna dana technologia.

David Grant
źródło
To samo dotyczy ogromnych możliwości formularzy internetowych. Większość ludzi widzi koła szkoleniowe formularzy internetowych i porównuje to z MVC.
TheLegendaryCopyCoder
W dzisiejszych czasach (nawet w 2013 r.) Nie ma sensu uczyć się abstrakcji na HTML i JavaScript. Nie zrobi ci nic dobrego na przyszłe okazje. HTML i JavaScript są w porządku. Walka z nim to przegrana bitwa.
user441521,
0

W obliczu problemu z programowaniem często szukam odpowiedzi w Internecie. Webforms ma mnóstwo informacji / komponentów na temat robienia wszystkiego. W MVC z powodu mniejszej liczby źródeł w Internecie, a warstwy abstrakcji potrzebne do tego, by coś zadziałało, ograniczyły rzeczy, które kiedyś mogłem zrobić. MVC total zabija moją produktywność jako programista, podczas gdy z Webformami tak nie jest. Na razie trzymam się formularzy internetowych, dopóki MVC nie dojrzeje na tyle, by je zastąpić.

Synek
źródło
0

Cóż, WebFormy mają więcej dostępnych zasobów edukacyjnych (po prostu dlatego, że są starsze), a zatem nowi programiści, którzy nie są „znani”, będą bardziej prawdopodobne, że znajdą informacje na temat tej starszej technologii w przeciwieństwie do nowszych rzeczy, takich jak MVC .

Starsi / doświadczeni programiści są starsi i będą bardziej biegli w starszej technologii ze względu na fakt, że programowali w niej dłużej niż w nowszej.

O ile nie możesz wydać pieniędzy i starać się, aby Twoi znajomi byli tak biegli w MVC, jak w aplikacjach WebForms, bez wątpienia będziesz próbował powstrzymać aktualizację do nowej platformy tak długo, jak to możliwe.

Stanowi więc kilka problemów logistycznych: czy korzyści płynące z MVC przewyższają koszty pod względem niższej jakości i czasu wdrożenia? Jeśli mam witrynę napisaną w całości w WebForms, czy warto byłoby zintegrować z nią MVC?

Jak stwierdził poprzedni komentator, MVC również uniemożliwia osiągnięcie tego samego poziomu interfejsu ze sterownikiem, jak w przypadku WebForms. Chociaż jestem zwolennikiem „powstrzymywania użytkownika od upychania rzeczy / uczenia się”, wciąż może być nieuzasadnionym problemem dla zespołów wdrożenie / wdrożenie programu, który fanatycznie trzyma się tego paradygmatu dla wszystkiego, co piszą.

32288
źródło
-1

Myślę, że różnica między tymi dwiema technologiami nie jest tak duża, jak kiedyś.

  • Formularze internetowe mogą korzystać z silnika routingu, z którego korzysta MVC (lub coś bardzo podobnego).
  • Menedżer skryptów może łączyć skrypty, ładować je z CDN, a nawet opóźniać ładowanie skryptów.

Aby bezpośrednio odpowiedzieć na twoje pytanie, myślę, że sprowadza się to do preferencji i / lub projektu. Oba mają zupełnie inne podejście do rozwoju. Osobiście pracuję nad przejściem do MVC, ale nadal lubię pracować z formularzami internetowymi. Myślę, że odpowiedź na pytanie, czy powinieneś używać MVC lub formularzy internetowych, należy do ciebie, wybierając obie technologie.

The Muffin Man
źródło
1
Webforms i MVC domyślnie zalecają radykalnie odmienne podejście do tworzenia stron internetowych, jest to ważne , niewielu programistów odchodzi od „domyślnych”. Oba można jednak wykorzystać do osiągnięcia tego samego.
Raynos