Kiedy faworyzować ASP.NET WebForms zamiast MVC

Wydaje się, że formularze internetowe a MVC to obecnie gorący temat. Wszyscy, których znam, przechwalają MVC jako kolejną wspaniałą rzecz. Z moich drobnych maniaków wygląda to w porządku, ale nie, nie sądzę, że to będzie koniec formularzy internetowych.

Moje rozumowanie i uzasadnienie, dlaczego formularze internetowe byłyby wybierane zamiast MVC, bardziej z perspektywy biznesowej niż z tego, co jest lepsze od drugiego.

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

Jeśli większość Twoich zespół zna formularze internetowe, a Ty nie masz czasu, aby przyspieszyć ich działanie w MVC, kod, który zostanie utworzony, może nie być dobrej jakości. Nauka podstaw MVC, a następnie wskoczenie i wykonanie tej złożonej strony, którą musisz zrobić, to bardzo różne rzeczy. Krzywa uczenia się jest duża, więc musisz wziąć to pod uwagę w swoim budżecie.

Jeśli masz dużą witrynę internetową zapisaną w całości w formularzach internetowych, możesz być bardziej skłonny do tworzenia nowych stron w formularzach internetowych, aby nie robić nie masz dwóch bardzo różnych typów stron w swojej witrynie.

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

Moja firma przeprowadziła ostatnio trzy strony testowe z MVC. Usiedliśmy i zaprojektowaliśmy je. Jednym z problemów, które napotkaliśmy, jest to, że większość naszych ekranów ma funkcje Wyświetl i Edytuj na tej samej stronie. Skończyło się na tym, że potrzebowaliśmy więcej niż jednego formularza na tej stronie. Nic wielkiego, poza tym, że nie będziemy używać naszej strony głównej. Musieliśmy to zmienić, aby zarówno strony formularzy internetowych, jak i strony MVC mogły używać tej samej strony głównej dla wspólnego wyglądu i stylu. Teraz mamy dodatkową warstwę zagnieżdżenia.

Musieliśmy stworzyć zupełnie nową strukturę folderów dla tych stron, aby była zgodna z właściwą separacją MVC.

Czułem, że jest za dużo plików na 3 strony, ale to moja osobistą opinię.

Moim zdaniem wybrałbyś formularze internetowe zamiast MVC, jeśli nie masz czasu / pieniędzy na inwestowanie w aktualizację swojej witryny do korzystania z MVC. Jeśli podejmiesz do tego półtora, nie będzie lepsze niż formularze internetowe, które masz teraz. Co gorsza, możesz nawet wystawiać tę technologię na niepowodzenie w swojej firmie, jeśli jest pomieszana, ponieważ wyższe kierownictwo może uznać to za coś gorszego od tego, co wiedzą.

Komentarze

• To dobra odpowiedź. Dałem ci +1, ponieważ cenimy twoje osobiste doświadczenia. Ale jest to porażka z powodu braku doświadczenia / zestawu umiejętności programistów, których chciałem unikać . Nie jestem przekonany, że firma Microsoft zdecydowałaby się nie oznaczać technologii jako przestarzałej tylko z powodu obawy przed krzywą uczenia się MVC. Może tak być, ale ' m jeszcze nie przekonany.
• @ P.Brian.Mackey – Nie ' nie powiedziałem, że tworzenie formularzy jest szybsze niż MVC. Poprosiłeś o pominięcie tego argumentu. Argumentowanie za czasem i pieniędzmi na szkolenie personelu to inny argument. MS wygrał ' t oznaczyć formularze internetowe jako przestarzałe z jednego ważnego powodu: klienci korporacyjni spędzili lata na tworzeniu klientów internetowych w formularzach internetowych i wygrali ' Nie wyglądaj uprzejmie na konieczność zainwestowania czasu i pieniędzy w aktualizację.
• @Raynos – Jeśli wszyscy w zespole biegle posługiwali się MVC, a Twoja firma rozpoczynała nowy projekt, jedynym powodem, dla którego widziałem, jak ktoś wybiera formularze internetowe, jest osobisty wybór.
• Dobrze znam obie technologie. Wszystkie moje projekty internetowe są wykonywane za pomocą mvc i pracuję w firmie, w której mam swobodę robienia tego, co jest najlepsze. Zawsze wybieram MVC.
• Zacząłem od Webforms i kiedy odkryłem MVC, przeszedłem na to. Nie ' nie wiem, jak ktokolwiek mógłby bronić formularzy internetowych. Cykl życia strony i jeden formularz dla całej strony? Czy ty żartujesz? Program do tworzenia witryn Yahoo był prawdopodobnie zamierzonym klientem, ale nawet oni ' nie chcieli tych śmieci.

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

• Cykl życia strony jest prostszy i wydajniejszy
• Nie ma czegoś takiego jak kontrolki poza kontrolkami HTML. Nie musisz debugować danych wyjściowych, aby zobaczyć, co generuje ASP .Net.
• ViewModels zapewniają ogromną moc i eliminują potrzebę ręcznego wiązania sterowania i eliminują wiele błędów związanych z wiązaniem.
• Możesz mieć wiele formularzy na stronie. To było poważne ograniczenie WebForms.
• Sieć jest bezstanowa, a MVC jest ściślej dopasowany do architektury sieci. Formularze internetowe przedstawiają stan i błędy masz z tym, wprowadzając ViewState. ViewState jest automatyczny i działa w tle, więc nie zawsze zachowuje się tak, jak chcesz.
• Aplikacje internetowe muszą obecnie współpracować z ajaxem. Nie można już ładować całej strony. MVC sprawia, że Ajax jest o wiele lepszy, łatwiejszy i bardziej wydajny dzięki JQuery.
• Ponieważ możesz mieć wiele formularzy na stronie i ponieważ architektura jest napędzane przez wywołania adresów URL, możesz robić dziwne rzeczy, takie jak Ajax ładuje inny formularz, na przykład formularz edycji na bieżącej stronie za pomocą JQuery. Kiedy już zdasz sobie sprawę, na co to pozwala, możesz łatwo robić niesamowite rzeczy.
• ASP .Net WebForms to nie tylko abstrakcja dotycząca HTML, jest niezwykle złożona. Czasami pojawia się dziwny błąd i walczysz z nim znacznie dłużej niż to konieczne. W wielu przypadkach można było zobaczyć, co robi źle ale nie jesteś w stanie nic z tym zrobić. Kończysz się dziwnymi obejściami.
• WebForms nie jest dobrą technologią 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 szybko się rozwija, WebForms nie nadąża. świadomy nowych tagów lub funkcji HTML5, nadal będzie renderował te same rzeczy, chyba że otrzymasz (często) drogie kontrolki innych firm lub poczekasz, aż Microsoft wyda aktualizację.
• Kontrolki w formularzach internetowych ograniczają Cię na wiele sposobów. W MVC możesz po prostu pobrać bibliotekę JQuery i zintegrować ją ze swoimi 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 oryginalne doświadczenie. Podsumowując, niezwykle trudno byłoby znaleźć uzasadnienie biznesowe dla formularzy internetowych, chyba że projekt już ich używa.

Komentarze

• +1 dla wskazując na wiele formularzy. Poza tym fakt, że generowane formularze HTML są w większości przypadków niezbyt przyjazne dla SEO (jak w przypadku: dużych fragmentów stanu wyświetlania na górze strony)
• Muszę się w 100% zgodzić z tą odpowiedzią. Pod koniec dnia formularze internetowe znacznie utrudniają wykonywanie czynności po stronie klienta (html / przeglądarka). Musisz dosłownie walczyć z ramami, aby coś zrobić. Strona aspx zawiera o wiele więcej kodu dzięki kontrolkom serwera niż zazwyczaj strona cshtml. @ šljaker Jeśli zaczniesz wyłączać ViewState i unikniesz kontroli serwera, ' porzuciłeś wiele WebForms w tym momencie. Nie ' nie uważam tego argumentu za szczególnie przekonujący.
• Możesz mieć proste kontrolki HTML w formularzach WebForms, nikt nie zmusza cię do korzystania z kontrolek serwera. Możesz mieć pełny bezstanowy formularz sieciowy, nikt nie zmusza cię do korzystania z ViewState. Możesz używać pełnego ajax i jQuery w Webforms, nikt nie ogranicza ci używania jQuery. Możesz zaimplementować routing adresów URL, nikt nie zmusza cię do korzystania z podstawowego adresu URL pliku statycznego. Ręczne rysowanie strony za pomocą CSS zabiera tyle czasu, ile potrzeba MVC. Możesz zaprojektować stronę HTML bezpośrednio w formularzu internetowym.
• @mjb: Jeśli nie ' nie używasz kontrolek serwera, ViewState i tak dalej, po co w ogóle używać formularzy internetowych, MVC jest bliższe temu, co robisz '? To ' to jak kierowanie traktorem do pracy, ale bez jazdy w terenie lub używania łopaty / motyki lub stabilizatorów. W takim razie dlaczego nie skorzystać po prostu z samochodu?
• @Tjaart Nie jest do końca w porządku, że nie możesz mieć wielu formularzy na stronie ASPNET.Możesz mieć dowolną liczbę formularzy na stronie ASPNET, ale możesz mieć tylko jeden formularz na serwerze – formularz z runat = ” server ” atrybut.

Wysłałem e-mail do Scott Guthrie , 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ść do programowania i bardzo lubią WebForms i uważają, że jest świetny. Inni kochają MVC i uważam, że jest świetny. Dlatego inwestujemy w oba. „

Więc, dla mnie to mówi, że to nie jest kwestia techniczna. To bardziej „miękka sprawa”, jeśli wolisz. Jedna z osobistych preferencji. Jest to zgodne z tym, co kilku z was powiedziało.

Dzięki za wszystkie odpowiedzi.

Komentarze

• Scott Guthrie wynalazł framework MVC dla ASP.NET podczas lotu powrotnego z Londynu do Seattle w sezonie 2006/7. Jeśli się nad tym zastanowić, wymyślił prawie .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Nazywanie go ” ekspertem ” to ogromne niedomówienie 😉
• To ' to miła polityczna odpowiedź Scotta Guthrie. Gdyby on sam zainwestował we własną aplikację internetową, ' widziałbyś projekt MVC i wszystko, czego nie można ' zrobić w MVC, Silverlight będzie rozwiązaniem awaryjnym. Nie ' Nie traktuj tego jako negatywnego komentarza w stosunku do formularzy internetowych, myślę, że formularze internetowe świetnie nadają się do mniejszych aplikacji wewnętrznych, które mogą czerpać korzyści z komponentów innych firm, takich jak te utworzone przez firmę Telerik. I ' cieszę się, że firma Microsoft rozwija obie technologie.
• ” Scott Guthrie wynalazł platformę MVC dla ASP .NET podczas lotu ” Myślę, że to naprawdę trywializuje MVC. Nie ' nie znam Scotta Guthrie, ale ' jestem gotów się założyć, że zastanawiał się, jak zaimplementować MVC w ASP.NET przez chwilę i wykorzystaliśmy ten długi lot do zaimplementowania prototypu gołej kości jako dowodu słuszności koncepcji.
• ” Dlatego inwestujemy w oba. ” A kiedy zobaczymy, że formularze internetowe zaczynają spadać, bezlitośnie je porzucimy, ponieważ inwestowanie w ostatecznie martwy produkt nie leży w naszym najlepszym interesie biznesowym.
• Dopóki nie jest już nauczany w szkołach, przez wiele lat zawsze będzie miał zastosowanie w świecie biznesu. Kolegia i licea nadal oferują kursy wprowadzające i zaawansowane w vb.net. Nigdzie nie idzie !!!

To nieaktualne pytanie z wieloma odpowiedziami, ale żadnej miałem odpowiedź, której bym oczekiwał.

Krótka odpowiedź brzmi:

• Użyj ASP.NET MVC, jeśli zamierzasz poprawnie zbudować aplikację internetową z nowoczesnym programowaniem konwencje i przyjęte w branży wzorce dla platformy ASP.NET. Z drugiej strony oczekuje się, że będziesz wiedzieć, jak działają HTML i zasoby po stronie klienta (Javascript, CSS), a także przyspieszyć podejście do programowania MVC, które ma stromą krzywą uczenia się, ale po zrozumieniu osiąga nagły koniec.
• Użyj formularzy sieci Web ASP.NET, jeśli używasz lub chcesz używać GUI -centric, RAD (Rapid Application Development) , podejście typu „przeciągnij i upuść” do bardzo szybkiego prototypowania czegoś, np. zachowanie przycisku / siatki danych podłączane w ciągu 15 minut, a rozwiązanie nie jest przeznaczone do czegoś, co jest obsługiwane przez programistów. Lub użyj formularzy sieci Web ASP.NET, jeśli masz doświadczenie w GUI lub programowaniu Windows Forms i chcesz przenieść wiedzy do sieci.

Ale aby przyjrzeć się temu właściwie, musisz zrozumieć historię każdego z nich.

ASP.NET Web Forms było odpowiedzią firmy Microsoft na ci, którzy budowali dynamiczne aplikacje internetowe przy użyciu Visual Basic 6 Ac kontrolki tiveX, biblioteki DLL VB6 na serwerze i ASP Classic. W tamtym czasie tworzenie stron internetowych przy użyciu tych narzędzi firmy Microsoft było prawdziwym bałaganem. Wraz z całością platformy .NET Framework, która była wynikiem pracy firmy Microsoft, w zasadzie wracając do deski kreślarskiej, pokazującej, jak produktywne programowanie biznesowe na stosie systemu Windows, ASP.NET Web Forms było w swoim czasie niesamowite i piękne.

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

Aby przycisk wykonał jakąś czynność, po przeciągnięciu go i upuszczeniu wystarczy kliknąć go dwukrotnie w projektancie i przejść do edytora kodu, mówiąc formularzowi, co ma zrobić, gdy to „kliknie „zdarzenie się dzieje. Dokładnie tak programiści GUI dla systemu Windows stworzyli oprogramowanie przy użyciu GUI VB6 i konkurencyjnych narzędzi, z wyjątkiem tego, że teraz kod jest wykonywany na serwerze! Wow!

To była technologia 2002. Niesamowita i piękna w swoim czasie jako odpowiedź na Internet -enabled GUI rozwiązań dla RAD , przyniosło to poczucie władzy do chaotycznego świata programistów, którzy mieli cele biznesowe, które musieli osiągnąć.

Niestety, ten model programowania tak bardzo podkreśla metaforę programowania GUI systemu Windows, że niesie ze sobą ciężar niezbędnych szczegółów implementacji , cały bagaż obciążający, gdzie indziej niesklasyfikowany Niezbędne do uwzględnienia cykli życia wydarzeń i schowania brzydkich szczegółów prostego kodu HTML i skryptu, które te komponenty i elementy sterujące typu „przeciągnij i upuść” będą generować. Ostatecznie programiści wspierający rzeczywiste aplikacje nieuchronnie musieli zagłębić się w te komponenty lub napisać własne, a co za tym idzie, toczyć bitwy z tą infrastrukturą, bitwy, które pozostawiłyby za sobą stosy na stosach okrucieństwa, wyrwanych włosów i łzy.

Cofnij się. Umyj ręce. Spójrzmy ponownie na problem biznesowy. Jakie są nasze cele biznesowe?

Musimy tworzyć i zarządzać aplikacjami internetowymi . Nasze ograniczenia polegają na tym, że mamy sieć WWW, który znajduje się w HTTP, HTML, Javascript i CSS, a na serwerze mamy reguły biznesowe, bazy danych i garść świetnych języków programowania (np. C #). Czy naprawdę potrzebujemy tej metafory GUI systemu Windows do kierowania naszą metodologią programowania? Dlaczego nie możemy po prostu skupić się na problemach z aplikacjami i pozbyć się metafor GUI?

W tym miejscu pojawia się ASP.NET MVC. Zaczął się od buntu programistów, którzy nazywali siebie „Alt.Net”, którzy chcieli wrócić do właściwych i czystych zasad tworzenia oprogramowania. Koniec z kłopotami i zamieszaniem, po prostu skup się na celach biznesowych i najlepszych praktykach dotyczących oprogramowania.

To naprawdę oznacza w tym przypadku:

1. Rozdzielenie obaw . Na przykład, komponent danych nie musi wiedzieć, jak jego dane będą renderowane, ani też widok znaczników nie powinien być obciążony szczegółami konfiguracji połączenia z bazą danych. W ten sposób programista może skupić się na swoim obszarze zainteresowania podczas edycji i testowanie kodu.
2. Ekspozycja i pełna obsługa dostępu do szczegółowości HTML i powiązanych zasobów . W formularzach sieci Web HTML jest ukryty, deweloperzy nie powinni się tym przejmować. 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 przeciwko nim.
3. Testowalność obiektów biznesowych . Kontrolery i modele znacznie lepiej nadają się do programowego testowania jednostkowego, dzięki czemu implementacje można zweryfikować pod kątem spełnienia celów biznesowych, a zmiany można zweryfikować, czy nie ulegną uszkodzeniu. W przypadku formularzy internetowych było to trudne do przetestowania, ponieważ komponenty nie były przeznaczone do testowania indywidualnie, a cały wynik rozwoju obracał się wokół formularzy stron i ich cykli życia zdarzeń, przy czym cała logika biznesowa i logika prezentacji były ze sobą ściśle powiązane.

Zwróć uwagę, że HTML jest już językiem znaczników bardzo wysokiego poziomu, podobnie jak Javascript – językiem programowania wysokiego poziomu. Cała historia wyglądałaby inaczej, gdybyśmy mieli do czynienia z językiem asemblera i C.

Rozwijając punkt 2, kolejnym celem ASP.NET MVC jest umożliwienie programistom uporządkowania szczegółów frontonu „Zobacz” część swoich rozwiązań i skorzystaj z bogatych podstaw, które reszta branży zbudowała na platformie klienta front-end.

Przekonasz się, że programiści ASP.NET MVC czują się jak w domu, wykorzystując bogate biblioteki JavaScript i techniki tworzenia szablonów po stronie klienta bez walki z architekturą po stronie serwera. Pierwotnie tak nie było w przypadku ASP.NET, ponieważ formularze internetowe nie chcą, abyś w ogóle patrzył na HTML lub skrypt, z wyjątkiem sytuacji, gdy naprawdę musisz , w takim przypadku uważaj, to nie jest dla osób o słabym sercu .

Komentarze

• To jest dobra odpowiedź, ale punkty 1 i 2 są błędne (WF nie wymaga komponentu, aby wiedzieć, gdzie są jego dane pochodzi z, jest to opcja i zawsze dodawałeś HTML do swoich plików ASPX, aby obsługiwać tagi asp, które renderujesz. Nigdy nie trzeba było sięgać głębiej i walczyć z kontrolkami, chyba że próbowałeś uzyskać dostęp do funkcji ASP, która nie jest przeznaczona dla programistów interakcji. Najważniejsze są testowalność i wzorzec projektowy.)

Jestem kompletnym i całkowicie przekonwertowanym do ASP.NET MVC i nie obejrzałem się za siebie, mówiąc, że nadal muszę obsługiwać kilka bardzo dużych aplikacji WebForms. Oto moje podejście:

WebForms
Używaj ich, gdy masz poważne problemy dotyczy siatek. Kontrolki siatki są naprawdę bardzo przyjemne, 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ę efektowną listę Ajax, której możesz użyć, która działa świetnie, ale w naszej firmie często musimy mieć coś uruchomionego wczoraj, a dobre staromodne siatki działają świetnie, a użytkownicy są szczęśliwi, że są w stanie z radością przechodzić przez siatkę. Dla mnie to naprawdę najlepsza rzecz w przypadku formularzy internetowych, ale jak Ryan wskazał, że formularze internetowe mogą być wielkim bałaganem, ponieważ grasz po obu stronach ogrodzenia ze sprytnego pliku związanego z kodem. Może to być jednocześnie róża i cierń, aby wszystkie elementy typu kontrolera zostały zmieszane z widokami.

MVC
Użyj tego, jeśli naprawdę chcesz rozwinąć własną aplikację i masz możliwość uruchomienia aplikacji od zera. Posiadanie jasno zdefiniowanej aplikacji MVC wymaga nieco więcej pracy, ale jej zalety w zakresie konserwacji przewyższają początkowy koszt konfiguracji. Jeśli chcesz robić ciekawe interakcje Ajax, wolisz pisać swój model z kodem, takim jak czyste adresy URL i trasy oraz mieć możliwość kontrolowania całego przepływu aplikacji, to zdecydowanie jest to droga. Przyzwyczajenie się do tego wymaga trochę czasu na początku, ale myślę, że jest to lepsza opcja dla aplikacji typu greenfield.

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

Komentarze

• +1 za ładne zdjęcie dostarczone z ” grającym po obu stronach ogrodzenie z fajnego pliku związanego z kodem „.
• Ten bardzo pomocny. ' robię bardzo rozbudowaną aplikację opartą na siatce i ' wykluczyłem Silverlight, xbap i było to spowodowane pokazem między tych dwóch.

Moje doświadczenie:

• Napisałem projekty CakePHP przez rok.
• Ukończył średni projekt Webforms w ciągu sześciu miesięcy.
• Pracowałem nad projektem Windows Forms przez trzy lata.

Po Z tego doświadczenia próbowałem napisać inną aplikację przy użyciu formularzy internetowych i byłem sfrustrowany po całodziennych zmaganiach z tym, jak formularze internetowe próbują chronić programistę przed faktem, że opracowują oni aplikację, która używa html, javascript i css.

Potem wypróbowałem MVC i mając bardziej bezpośrednią kontrolę nad wyjściem (i pewne doświadczenie z paradygmatem MVC od CakePHP) byłem w stanie ukończyć tę prostą aplikację dokładnie tak, jak chciałem, w około pół dnia.

Dostępność potężnych frameworków UI, takich jak jQuery, jest bardzo dużo eli minimalizuje atrakcyjność rezygnacji z bezpośredniej kontroli nad danymi wyjściowymi na rzecz używania często nieporęcznych, gotowych komponentów interfejsu użytkownika.

Komentarze

• @JimG – Uhh , wszystko, co wiąże się z wprowadzaniem przez osobę rekordów bez interesujących skojarzeń do bazy danych, i pozwalaniem tej osobie lub komuś innemu na przeczytanie / wydrukowanie ich w innym miejscu, może być w zasadzie szkieletem przy użyciu frameworka MVC. To prawda, że nie jest to ' t w większości aplikacji, ale jest to ' o wiele więcej, niż można zrobić z Formularzami. Domyślam się, że Twoje -1 potwierdza mój punkt widzenia.
• To ' 1/4 dnia.
• Ale jeśli wymagania wynoszą ” Potrzebuję aplikacji z dwiema rolami: jedną do rejestrowania informacji, a drugą do przeglądania, a ja nie ' tak naprawdę obchodzi mnie, jak to wygląda. ” W takim razie tak, ' jest całkiem wykonalne.
• Przykro mi, ale opracowanie aplikacji webforms do wprowadzania danych i przeglądania danych jest tak proste, że można to zrobić w kilka godzin. tworzenie struktury aplikacji MVC, kontrolerów, widoków i akcji zajmie tyle samo czasu, ale nie doprowadzi Cię do gotowego produktu.
• @Dementic Zwykle dla prostej aplikacji MVC buduje się modele, a następnie tworzy szkielet kontrolerów i widoków i / lub generuje kontrolery / widoki szkieletowe. Nie ma tam nic czasochłonnego.

Wolę formularze internetowe, ponieważ moim tłem jest programowanie w systemie Windows.

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

webforms jest dla byłych ludzi z Windowsem mvc jest dla ludzi internetu

ale we współczesnym świecie, gdzie Rick napisał niesamowitą książkę z codziennymi rosnącymi szybkościami serwerów i tanim koderem w Indiach, cóż, formularze internetowe mają przewagę

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

Uważam, że abstrahowanie od podstawowego REST jest złe, cały model postback jest zły, sposób, w jaki html / css jest traktowany z poleganiem w edytorze GUI jest zły, nacisk na rzeczy takie jak kreatory i GUI do konfiguracji jest zły, adresy URL są złe.

Komentarze

• czy mógłbyś bardziej szczegółowo wyjaśnić, dlaczego tak myślisz?
• myślę, że abstrahowanie od podstawowego REST powróciło, cały model postback powrócił, sposób, w jaki html / css jest obsługiwany z poleganiem na edytorze GUI jest zły , nacisk na takie rzeczy jak kreatory i GUI do konfiguracji jest zły, adresy URL są złe itd. itd.

Przeczytałem wszystkie odpowiedzi i czuję, że moje osobiste doświadczenia mogą dodać coś do powyższych odpowiedzi.

3-4 lata temu opracowałem 2-3 projekty witryn internetowych przy użyciu formularzy internetowych. Mniej więcej w tym czasie MVC nie było w pobliżu lub nie słyszałem o nim. Rozwój był dla mnie naturalnie (pochodziłem z tworzenia formularzy Win bez wcześniejszego doświadczenia w tworzeniu stron internetowych), ponieważ nie muszę uczyć się języka HTML w szczegółach, a sterowanie sieciowe bardzo pomogło (do diabła, ułatwiło życie) .

Teraz, po tylu latach, nie pracowałem nad żadnym projektem internetowym aż do niedawna i po prostu budowałem jakąś aplikację Windows przy użyciu WPF.

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

Kluczowe różnice, które widzę, są następujące: –

• Formularze internetowe zawsze będą korzystne dla kogoś, kto zajmuje się programowaniem w systemie Windows. Krzywa uczenia się .net dla programisty systemu Windows jest nieco stroma

• Dla kogoś, kto zajmuje się tworzeniem stron internetowych w innej technologii, MVC będzie faworyzowany, ponieważ kpi z najnowszą z nich wszystkich.

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

• Wdrażanie nadal stanowi problem. W formularzach internetowych wystarczyło skopiować i wkleić. Ale to wymaga pewnych rzeczy.

Krótko mówiąc, obaj zostaną tutaj przez chwilę.

Nie widziałem jeszcze tej uwagi wśród 15 istniejących odpowiedzi w tym wątku, ale myślę, że tak warto rozważyć.

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

Jak wskazywały inne odpowiedzi, programowanie we frameworku MVC jest bardziej podobne do tworzenia stron internetowych w Rubim, PHP, Python itp. Niż jego odpowiedniki firmy Microsoft; więc oczywiście na wybór MVC może mieć wpływ doświadczenie zespołów w tych obszarach, a także czynniki przedstawione w innych odpowiedziach.

Komentarze

• + 1 Z pewnością rozsądny argument za Webforms. Obawiam się, że zespoły podążają za tym sposobem myślenia, aby uniknąć uczenia się nowych rzeczy. MVC jest wypełnione wieloma wzorami, które mogą być nieznane zespołowi. Nauczenie się tego typu wzorców i wdrażanie ich 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.

Nasz powód, dla którego nie wybieramy się do MVC kilka lat temu była to niedojrzała technologia firmy Microsoft. W ciągu ostatnich kilku lat jesteśmy teraz na bardziej dojrzałej wersji (4) i wydaje się, że MS już się zorientowało, dokąd zmierzają w tym zakresie.Jednak nadal jesteśmy niechętni do tworzenia głównych aplikacji LOB przy użyciu MVC, ponieważ funkcje, których chcemy używać w wersji 4, wymagają serwera Windows 2012 (ponownie gniazda sieciowe przez IIS8). Sądzę, że za 1 rok będziemy bardziej akceptować MVC, ponieważ mamy nadzieję, że będzie dostępnych więcej kontroli stron trzecich, technologia się uspokoi i będziemy mieć infrastrukturę do jej obsługi.

Komentarze

• Czy mógłbyś wymienić niektóre z tych funkcji, które Twoim zdaniem wymagają systemu Windows Server 2012?

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

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

Czy to nie jest lepsze od drugiego? Polecam wypróbować własne doświadczenie, ale muszę powiedzieć, że program w MVC to czysty, zabawny, elastyczny, rozszerzalny, bezpieczny i zorganizowany sposób.

Pozdrawiam,

Jedynym powodem, dla którego wybrałbym WebForms zamiast MVC, jest to, że masz znacznie więcej kontrolek UI innych firm niż MVC. Wybrałem MVC, ponieważ za dużo pracowałem z WebForms i chcę pracować z czymś świeżym / nowym, ale nadal ze sklepu MS 🙂

W zasadzie nic nie stoi na przeszkodzie, aby wyłączyć stan widoku w formularzach internetowych i użyć ViewModels i pętle if / for zamiast powiązania modelu i kontroli po stronie serwera.

Czy to jest kod WebForms czy MVC:

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

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

ASP.NET MVC jest naprawdę odpowiedzią na Ruby i nowy, modny i (IMO) lepszy sposób na maksymalne oddzielenie przeglądarki (klienta) od serwera.

ASP.NET Webforms daje dużą kontrolę nad klientem po stronie serwera, z bezpośrednim dostępem prawie do wszystkiego. W zasadzie widok i kontroler są takie same, co daje dużo możliwości, a najczęściej dużo bałaganu.

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

Zasadniczo różnica polega na tym, że przetwarzanie jest znacznie większe (zazwyczaj całość) w celu wyświetlenia danych do pliku widoku i pozostawiając logikę biznesową i resztę w kontrolerze, dzięki czemu oba są zgodne z konwencją, ale także z mniejszym dostępem do siebie nawzajem, niż pozwala na to formularze internetowe.

Komentarze

• KIEDY więc formularze internetowe powinny być faworyzowane nad MVC? To nie odpowiada na pierwotne pytanie dotyczące plakatów.
• @WeekendWarrior – Tak, jeśli chcesz mieć większy dostęp do klienta po stronie serwera, wybierz formularze internetowe. Jeśli chcesz więcej odsprzęgania klienta / serwera w swoim kodzie, wybierz MVC. Pod koniec dnia obaj robią dokładnie to samo. Filtry przekierowania robią to samo, co adresy URL MVC i można przenieść kod formularzy internetowych do oddzielnej warstwy środkowej, aby go bardziej oddzielić. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Odnośnie trzeciego punktu, ta logika biznesowa kończy się w pliku .aspx.cs – myślę, że to wina programistów. ' nie ma / nie powinno / tam być. W formularzach internetowych .aspx to ” widok „, a .aspx.cs to ” controller „, przeznaczony do przetwarzania kodu bezpośrednio związanego tylko z interfejsem użytkownika poprzez odpytywanie warstwy biznesowej lub gruboziarnistej biznesowej warstwy elewacyjnej. Fakt, że ludzie umieszczają logikę biznesową w pliku .aspx.cs, to po prostu słabe programowanie. Mogą również umieścić logikę biznesową w widoku w MVC! MVC nie ' nie wymusza oddzielenia tych rzeczy.
• Zasadniczo ma więcej racji niż inne odpowiedzi zamieszczone tutaj. ASP.net to podstawowa idea rodziny modularnych technologii internetowych stworzonych przez firmę Microsoft. Moduł ASP.net MVC może być chwilowym szumem, ale na pewno nie ostatni, wszystko zaczyna się od ASP.net, więc kiedy wybrać ASP.net, jeśli nie myślisz, że MVC nie jest twoją rzeczą, może bardziej w czymś inny OWIN lub …, coś bardziej zaawansowanego, lub stworzyłeś własny framework do swoich zadań. Możesz nawet nie potrzebować ASP.MVC i pominąć go i przejść do Owin lub Katana, ale do tego czasu użyj asp.net

Moim zdaniem są one wystarczająco powiązane i mają mniej więcej takie same możliwości, jakie powinny nadejść do preferencji.

Świetny programista WebForms może stworzyć produkt równie potężny, jak świetny programista MVC. Ale wielki programista WebForms, który próbuje zmusić się do przyjęcia MVC, nie powiedzie się. To samo dotyczy świetnego programisty MVC, który daje szansę na WebForms.

Nie są to całkowicie oddzielne jednostki i dopóki Microsoft będzie nadal wspierać oba, wierzę, że nadal będziesz widzieć mieszaną grupę wyjątkowych programistów dla każdego.

Wszystko zależy od osobistego wyboru, zakładając, że wszyscy biegle posługujemy się technologią, której używamy. Używam podejścia projektowego WebForms od wielu lat i muszę powiedzieć, że jedyną wadą jest to, że dzięki uproszczonemu podejściu wiele osób nie poświęca czasu na odkrywanie 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 zapewnia większą kontrolę, czyste adresy URL, SOC itp.), tak naprawdę nie zapewnia zbyt wiele , że WebForms nie mogą. W rzeczywistości pojawienie się jQuery i jego współpracy z WebForms (a także MVC) sprawiło, że te argumenty są mniej problematyczne. A kiedy ludzie mówią o oddzieleniu obaw jako przewadze MVC nad MVP, pytam ich, ile wiedzą o programowaniu zorientowanym obiektowo i jak bardzo wykorzystali zasadę abstrakcji i polimorfizmu.

Obecnie czuję się komfortowo, korzystając z obu technologii i wybieram i wybieram w zależności od sytuacji. Szczerze mówiąc, wszystko gotowe do Ciebie, ale prawda pozostaje taka, że nie każdy poświęca czas na dokładne poznanie możliwości danej technologii.

Komentarze

• Jak wyżej ogromne możliwości formularzy internetowych. Większość ludzi widzi koła szkoleniowe formularzy internetowych i porównuje je z MVC.
• W dzisiejszych czasach nie ma sensu uczyć się abstrakcji oprócz HTML i JavaScript (nawet w 2013). ' nie przyniesie ci korzyści w przyszłości. HTML i Javas cript jest po prostu w porządku, taki jaki jest. Walka z tym to przegrana bitwa.

W obliczu problemu programistycznego często zaglądam do sieci na odpowiedzi. Formularze internetowe zawierają mnóstwo informacji / komponentów umożliwiających robienie niemal wszystkiego. W MVC ze względu na mniej źródeł online i warstwy abstrakcji potrzebne do tego, aby coś działało, ograniczyło to, co kiedyś mogłem zrobić. Łącznie MVC zabija moją produktywność jako programisty, podczas gdy z formularzami internetowymi nie jest. Więc na razie trzymam się formularzy internetowych, dopóki MVC nie dojrzeje na tyle, aby go zastąpić.

Cóż, formularze internetowe mają więcej dostępnych zasobów edukacyjnych (po prostu ze względu na to, że są starsze), a zatem nowi programiści, którzy nie są „t” wiedzą, będą bardziej skłonni do znalezienia informacje dotyczące 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, ponieważ programowali w niej dłużej niż oni w nowszym.

Jeśli nie możesz wydać pieniędzy i wysiłku, aby sprawić, by twoi ludzie byli tak biegli w MVC, jak w aplikacjach WebForms, bez wątpienia będziesz próbował powstrzymać się od aktualizacji do nowej tak długo, jak to możliwe.

Stwarza to kilka problemów logistycznych: czy korzyści płynące z MVC przewyższają koszty pod względem niższej jakości i czas wdrożenia? Jeśli mam witrynę napisaną w całości w formularzach internetowych, czy byłoby warte wysiłku i pieniędzy zintegrowanie z nią MVC?

Jak stwierdził poprzedni komentator, MVC uniemożliwia również osiągnięcie tego samego poziomu interfejsu z kontroler, tak jak w przypadku WebForms. Chociaż jestem zwolennikiem strony „Nie pozwól użytkownikowi na upychanie rzeczy / uczenie się”, zespoły mogą nadal być nieracjonalnie kłopotliwe we wdrażaniu / wdrażaniu programu, który fanatycznie trzyma się tego paradygmatu we wszystkim, co piszą.

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

• Formularze internetowe mogą korzystać z mechanizmu routingu używanego przez MVC (lub czegoś 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 czym jest projekt. Obaj mają zupełnie inne podejście do rozwoju. Osobiście pracowałem nad przejściem na MVC, ale nadal lubię pracować z formularzami internetowymi. Myślę, że odpowiedzią na pytanie, czy powinieneś używać MVC, czy formularzy internetowych, jest podjęcie decyzji poprzez doświadczenie obu technologii.

Komentarze

• Formularze internetowe i MVC domyślnie zalecają radykalnie inne podejście do tworzenia stron internetowych, jest to ważne , niewielu programistów się odstaje z ” domyślnego „. Oba można jednak wykorzystać do osiągnięcia tego samego.