Kiedy faworyzować formularze ASP.NET WebForms nad MVC

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?

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ą.

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.

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.

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.

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. :)

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.

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ę

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.

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ę.

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.

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.

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,

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?

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.

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.

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.

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ć.

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ą.

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.