Când să favorizați ASP.NET WebForms peste MVC

Webforms vs. MVC pare a fi un subiect fierbinte în acest moment. Toată lumea pe care o cunosc promovează MVC ca fiind următorul lucru grozav. Din ușorele mele discuții, mi se pare ok, dar nu, nu cred că va fi sfârșitul formelor web.

Raționamentul meu și motivarea motivelor pentru care formele web ar fi alese în locul MVC, au mai mult de-a face cu o perspectivă de afaceri decât cu ceea ce una este mai bună decât cealaltă.

Timpul / banii sunt cele mai importante motive pentru care formele web ar fi alese în locul MVC.

Dacă majoritatea echipa cunoaște formele web și nu aveți timp să le puneți la curent pe MVC, este posibil ca codul care va fi produs să nu fie de calitate. Învățarea elementelor de bază ale MVC, apoi să sară și să faci acea pagină complexă pe care trebuie să o faci sunt lucruri foarte diferite. Curba de învățare este ridicată, așa că trebuie să includeți acest lucru în bugetul dvs.

Dacă aveți un site web mare scris în toate formele web, este posibil să fiți mai înclinați să creați pagini noi în formele web, astfel încât să nu faceți acest lucru ” Nu aveți două tipuri foarte diferite de pagini pe site-ul dvs.

Nu spun că este o abordare completă sau nimic aici, dar vă face codul mai greu de întreținut dacă există o împărțire a ambelor , mai ales dacă nu toată lumea din echipă este familiarizată cu MVC.

Compania mea a făcut recent trei pagini de testare cu MVC. Ne-am așezat și le-am proiectat. O problemă pe care am întâmpinat-o este că majoritatea ecranelor noastre au funcționalitatea Afișare și editare din aceeași pagină. Am ajuns să avem nevoie de mai multe forme pe pagină. Fără mare, cu excepția cazului în care nu vom folosi pagina noastră principală. A trebuit să reformăm acest lucru, astfel încât atât paginile de formulare web, cât și paginile MVC să poată utiliza aceeași pagină de bază pentru un aspect comun. Acum avem un strat suplimentar de cuibărit.

Trebuia să creăm o structură de folder complet nouă pentru aceste pagini, astfel încât să urmeze separarea corectă a MVC.

Am simțit că există prea multe fișiere pentru 3 pagini, dar asta este opinie personală.

În opinia mea, ați alege formele web peste MVC dacă nu aveți timp / bani pentru a investi în actualizarea site-ului dvs. pentru a utiliza MVC. Dacă faceți o abordare pe jumătate nu va fi mai bun decât formele web pe care le aveți acum. Mai rău, ați putea chiar să configurați această tehnologie pentru eșec în compania dvs. dacă este încurcată, deoarece conducerea superioară ar putea să o vadă ca ceva inferior a ceea ce știu ei.

Comentarii

• Acesta este un răspuns bun. Ți-am dat +1 pentru că experiențele tale personale sunt apreciate. Dar acest lucru este un eșec din cauza lipsei de experiență / set de abilități a dezvoltatorilor pe care am cerut să-l evit . Nu sunt convins că Microsoft ar alege să nu marcheze o tehnologie învechită pur și simplu din cauza fricii de curba de învățare pentru MVC. Acesta poate fi cazul, dar eu ‘ încă nu sunt convins.
• @ P.Brian.Mackey – Nu am spus ‘ că dezvoltarea formularelor este mai rapidă decât MVC. Ați cerut să lăsați acest argument în afara acestuia. Argumentarea timpului și a banilor pentru a vă instrui personalul este un argument diferit. MS a câștigat ‘ t marcând formele web învechite dintr-un motiv important: clienții Enterprise au petrecut ani de zile dezvoltând clienți web în webforms și au câștigat div id = „c6301dd3a5”>

Am dezvoltat aplicații ASP .Net WebForms timp de 3 ani și după o zi de a face un tutorial MVC am fost vândut. MVC este aproape ÎNTOTDEAUNA soluția cea mai bună. De ce?

• Durata de viață a paginii este mai simplă și mai eficientă
• Nu există controale în afară de controalele html. Nu trebuie să vă depanați ieșirea pentru a vedea ce generează ASP .Net.
• ViewModels vă oferă o putere imensă și înlăturați nevoia de a face controlul manual de legare și elimină multe erori legate de legare.
• Puteți avea mai multe formulare pe o pagină. Aceasta a fost o limitare serioasă a WebForm-urilor.
• Web-ul este apatrid și MVC se potrivește mai atent cu arhitectura web-ului. Webforms introduce starea și erorile aveți cu el introducând ViewState. ViewState este automat și funcționează în fundal, deci nu se comportă întotdeauna așa cum doriți.
• Aplicațiile web trebuie să funcționeze cu ajax în zilele noastre. Nu mai este acceptabil să aveți încărcări de pagină completă. MVC face Ajax mult mai bun, mai ușor și mai eficient cu JQuery.
• Deoarece puteți avea mai multe formulare pe o pagină și pentru că arhitectura este condus de apeluri către adrese URL, puteți face lucruri ciudate, cum ar fi ajax, încărcați un formular diferit, cum ar fi un formular de editare în pagina curentă utilizând JQuery. Odată ce vă dați seama ce vă permite acest lucru, puteți face lucruri uimitoare cu ușurință.
• ASP .Net WebForms nu este doar o abstracție față de html, este una extrem de complexă. Uneori ai primi un bug ciudat și te vei lupta cu el mult mai mult decât este necesar. În multe cazuri, ai putea vedea de fapt ce a făcut greșit dar nu sunteți în stare să faceți nimic în acest sens. În sfârșit, faceți soluții ciudate.
• WebForms nu oferă o tehnologie bună pentru designeri. Proiectanților le place adesea să lucreze direct cu html. În MVC este o viziune, în WebForms este o jumătate de zi de lucru.
• Pe măsură ce platforma web evoluează rapid WebForms nu va ține pasul. Nu este conștient de noile etichete sau caracteristici ale HTML5, va reda în continuare aceleași lucruri, cu excepția cazului în care primiți (adesea) controale costisitoare ale terților sau așteptați ca Microsoft să emită o actualizare.
• Controalele din WebForms vă limitează în atât de multe moduri. În MVC puteți pur și simplu să luați o bibliotecă JQuery și să o integrați în șabloanele dvs.

Știu că unele dintre problemele de mai sus au fost abordate într-o oarecare măsură pe măsură ce WebForms evoluează, dar aceasta a fost experiența mea inițială. Una peste alta, mi-ar fi extrem de greu să găsesc un caz de afaceri pentru WebForms, cu excepția cazului în care un proiect îl folosește deja.

Comentarii

• +1 pentru arătând forme multiple. În plus, faptul că formele web HTML generează de cele mai multe ori nu sunt foarte potrivite pentru SEO (ca în: bucăți mari de viewstate din partea de sus a paginii)
• Trebuie să fiu de acord 100% cu acest răspuns. La sfârșitul zilei, WebForms face lucrurile din partea clientului (html / browser) mult mai greu. Trebuie literalmente să lupți cu cadrul pentru a face ceva. O pagină aspx se termină cu mult mai mult cod datorită controalelor serverului decât o face de obicei o pagină cshtml. @ šljaker Dacă începeți să dezactivați ViewState și evitați controalele serverului, ‘ ați abandonat o mare parte din WebForms în acel moment. Nu ‘ nu văd acest argument ca fiind deosebit de convingător.
• Puteți avea controale html simple în WebForms, nimeni nu vă obligă să utilizați comenzile Server. Puteți avea un formular web complet fără stat, nimeni nu vă obligă să utilizați ViewState. Puteți utiliza ajax complet și jQuery în Webforms, nimeni nu vă restricționează să utilizați jQuery. Puteți implementa rutare URL, nimeni nu vă obligă să utilizați adresa URL de bază a fișierului static. Desenarea manuală a unei pagini cu CSS consumă timpul cât trebuie MVC. Puteți proiecta pagina HTML direct pe Webform.
• @mjb: Dacă nu ‘ nu utilizați comenzile serverului, ViewState și așa mai departe, de ce utilizați WebForms deloc când MVC este mai aproape de ceea ce faceți ‘? ‘ seamănă cu conducerea unui tractor la locul de muncă, dar fără a face offroading sau folosind lopata / sapa sau barele stabilizatoare. În acel moment, de ce să nu folosiți doar o mașină?
• @Tjaart Nu este chiar corect să nu aveți mai multe formulare pe pagina ASPNET.Ați putea avea câte forme doriți în pagina ASPNET, dar ați putea avea un singur formular de server – formular cu runat = ” server ” atribut.

Am trimis prin e-mail Scott Guthrie , un expert MVC la Microsoft. Și probabil cel mai calificat om care să răspundă la această întrebare. El a fost destul de amabil să răspundă:

„Diferi clienți caută abordări de programare diferite, iubesc foarte mult WebForms și cred că este minunat. Alții adoră MVC și cred că este minunat. De aceea investim în ambele. „

Deci, pentru mine, acest lucru spune că nu este o problemă tehnică. Este mai mult o „problemă slabă”, dacă vreți. Una de preferință personală. Acest lucru este în conformitate cu ceea ce ați spus câțiva dintre voi.

Vă mulțumim pentru toate răspunsurile.

Comentarii

• Scott Guthrie a inventat cadrul MVC pentru ASP.NET în timpul unui zbor de întoarcere de la Londra la Seattle în 2006/7. Gândiți-vă la asta, a inventat și el .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). A-l numi un ” expert ” este o subevaluare enormă 😉
• Acel ‘ un răspuns politic frumos de la Scott Guthrie. Dacă el însuși și-ar investi propria aplicație web, ‘ ar vedea un proiect MVC și pentru orice nu s-ar putea ‘ să se poată face în MVC, Silverlight ar fi o rezervă. Nu ‘ nu considerați acest lucru ca un comentariu negativ față de WebForms, cred că WebForms sunt excelente pentru aplicații interne cu scop mai mic, care pot beneficia de componente ale unor terțe părți, cum ar fi cele create de Telerik. Mă ‘ mă bucur că Microsoft merge mai departe cu ambele tehnologii.
• ” Scott Guthrie a inventat cadrul MVC pentru ASP .NET în timpul unui zbor ” Cred că asta banalizează cu adevărat MVC. Nu ‘ nu îl știu pe Scott Guthrie, dar ‘ sunt dispus să pariez că a peculat modul în care ar putea fi implementat MVC în ASP.NET pentru o vreme și am folosit acel zbor lung pentru a implementa un prototip de oase goale ca dovadă a conceptului.
• ” De aceea investim în ambele. ” Și când vom vedea că formularele web încep să scadă, îl vom renunța fără milă, deoarece investiția într-un produs în cele din urmă mort nu este în interesul nostru pentru afaceri.
• Până la nu mai este predat în școli, de mulți ani, va fi întotdeauna aplicabil în lumea afacerilor. Colegiile și liceele continuă să ofere cursuri de introducere și cursuri avansate în vb.net. NU merge nicăieri !!!

Aceasta este o întrebare învechită cu multe răspunsuri, dar niciuna aveam răspunsul la care m-aș fi așteptat să fie listat.

Răspunsul scurt este:

• Utilizați ASP.NET MVC dacă intenționați să construiți corect o aplicație web cu programare modernă convențiile și industria au adoptat modele pentru platforma ASP.NET. În partea de jos, va fi de așteptat să știți cum funcționează resursele HTML și client (Javascript, CSS), precum și să creșteți mentalitatea de programare MVC, care are o curbă de învățare abruptă, dar ajunge la un sfârșit brusc odată apucat.
• Utilizați formulare Web ASP.NET dacă „utilizați sau doriți să utilizați un GUI -centric, RAD (Rapid Application Development) , abordare drag-and-drop pentru a prototipa ceva foarte repede, adică comportamentul butonului / grilei de date conectat în 15 minute, iar soluția nu este destinată a fi ceva susținut de dezvoltatori. Sau Utilizați ASP.NET Web Forms dacă aveți un fundal în GUI sau în dezvoltarea Windows Forms și doriți să transferați cunoștințe către web.

Dar pentru a privi corect acest lucru, trebuie să înțelegeți istoricul fiecăruia.

ASP.NET Web Forms a fost răspunsul Microsoft la cei care construiseră aplicații web dinamice folosind Visual Basic 6 Ac controalele tiveX, DLL-urile VB6 de pe server și ASP Classic. La acea vreme, dezvoltarea web utilizând aceste instrumente Microsoft era o adevărată mizerie. Împreună cu întregul .NET Framework, care a fost rezultatul Microsoft, revenind în esență la planșa de desen despre modul de realizare a programării de afaceri productive pe stiva Windows, ASP.NET Web Forms a fost, la vremea sa, uimitor și frumos.

Întreaga abordare a fost de a oferi dezvoltatorilor cele mai bune din ambele lumi ceva foarte similar cu dezvoltarea aplicațiilor Windows, dar cu puterea serviciilor de internet.Ideea a fost că, la fel ca în cazul unui „Form” VB6 / WinForms (o fereastră), de asemenea, o pagină web este un formular (la fel ca o fereastră, vezi) , iar în acel formular puteți trage și plasa etichete, casete de text, grile de date, butoane și alte lucruri cu care erau obișnuiți dezvoltatorii GUB VB / WinForms.

Pentru a face ca un buton să facă ceva, după ce îl glisați și îl fixați, trebuie doar să faceți dublu clic pe el în proiectant și să vă aflați în editorul de cod, spunând formularului ce trebuie să faceți când acel „clic” „eveniment se întâmplă. Acesta a fost exact modul în care dezvoltatorii Windows GUI au creat software utilizând instrumentele GUI ale instrumentelor VB6 și ale instrumentelor concurente, cu excepția cazului în care codul se execută pe server! Uau!

Aceasta a fost tehnologia din 2002. Uimitor și frumos la vremea sa ca răspuns la internet -activat soluții GUI pentru RAD dezvoltare , a adus un sentiment de putere către o lume dezordonată a dezvoltatorilor de software care aveau obiective de afaceri pe care trebuiau să le îndeplinească.

Din păcate, acest model de programare subliniază atât de mult metafora programării GUI Windows, încât poartă cu sine povara detaliilor sale necesare de implementare. , toate bagajele grevante nec este necesar pentru a se potrivi ciclurilor de viață ale evenimentelor și a ascunde detaliile urâte ale HTML-ului și scriptului simplu pe care le-ar genera aceste componente și comenzi de glisare și plasare. Și la sfârșitul zilei, dezvoltatorii care susțin aplicații reale trebuiau inevitabil să se adâncească în aceste componente sau să scrie propriile lor și, în consecință, ar purta bătălii cu această infrastructură, bătălii care ar lăsa în urmă grămezi pe grămezi de cruft, păr tras și lacrimi.

Înapoi. Spala-ti mainile. Să ne uităm din nou la problema afacerii. Care sunt obiectivele noastre de afaceri?

Trebuie să construim și să gestionăm aplicații web . Constrângerile noastre sunt că avem World Wide Web, care se află pe HTTP, HTML, Javascript și CSS, iar pe server avem reguli de afaceri, baze de date și o mică mână de limbaje de programare grozave (de exemplu, C #). Chiar avem nevoie de această metaforă Windows GUI pentru a conduce metodologia noastră de dezvoltare? De ce nu ne putem concentra doar pe problemele aplicației și să eliminăm metaforele GUI?

Aici intervine ASP.NET MVC. A început de la o rebeliune de dezvoltatori care s-au numit „Alt.Net” care doreau să revină la principiile de dezvoltare software adecvate și pure. Nu mai aveți probleme, doar concentrați-vă asupra obiectivelor de afaceri și a celor mai bune practici software.

Ce se traduce cu adevărat în acest caz este:

1. Separarea preocupărilor . De exemplu, o componentă de date nu trebuie să știe cum vor fi redate datele sale și nici nu ar trebui ca marcajul de vizualizare să fie grevat cu detalii de configurare a conexiunii la baza de date și, în acest fel, un dezvoltator se poate concentra asupra domeniului său de interes atunci când editează și cod de testare.
2. Expunere și suport complet pentru expunerea la conținut HTML și resurse conexe . În Web Forms, HTML este ascuns, dezvoltatorii sunt descurajați să se agite cu asta. În ASP.NET MVC, dezvoltatorii sunt încurajați să gestioneze acele detalii; de fapt este o necesitate. Avantajul este că dezvoltatorul poate învăța din nou să aprecieze semantica curată a HTML, CSS și script și să lucreze cu mai degrabă decât împotriva acestuia.
3. Testabilitatea obiectelor comerciale . Controlerele și modelele sunt mult mai potrivite pentru testarea unităților programatice, astfel încât implementările să poată fi validate pentru a îndeplini obiectivele de afaceri, iar modificările pot fi verificate că nu se vor rupe. Cu Web Forms, a fost dificil de testat, deoarece componentele nu au fost concepute pentru a fi testate individual, iar întregul rezultat al dezvoltării se învârtea în jurul formularelor de pagină și a ciclurilor lor de viață ale evenimentelor, cu logica de afaceri și logica de prezentare profund interconectate.

Rețineți că HTML este deja un limbaj de markup la nivel înalt, la fel ca și Javascript un limbaj de programare la nivel înalt. Întreaga poveste ar fi fost diferită dacă am avea de-a face cu limbajul de asamblare și C.

Extindându-ne pe # 2, un alt obiectiv al ASP.NET MVC este de a permite dezvoltatorilor să organizeze detaliile front-end ale porțiunea „view” a soluțiilor lor și profitați de fundația bogată pe care restul industriei și-a construit-o pe platforma client front-end.

Veți descoperi că dezvoltatorii ASP.NET MVC se simt ca acasă folosind biblioteci Javascript bogate și tehnici de șablonare pentru client, fără a lupta cu arhitectura de pe server. Acest lucru nu a fost inițial cazul ASP.NET Web Forms, deoarece Web Forms nu vrea să vă uitați deloc la HTML sau script, cu excepția cazului în care chiar trebuie să , caz în care, atenție, nu este pentru cei slabi .

Comentarii

• Acesta este un răspuns bun, dar # 1 și # 2 sunt greșite (WF nu necesită o componentă pentru a ști unde sunt datele sale vine de la, este o opțiune și ați adăugat întotdeauna HTML la fișierele ASPX pentru a sprijini etichetele ASP pe care le redați. Nu ați fost nevoie niciodată să săpați adânc și să luptați cu controalele decât dacă ați încercat să accesați o caracteristică ASP care nu este destinată dezvoltatorului interacțiune. Punctele mari sunt testabilitatea și modelul de proiectare.)

Sunt un convertitor complet și total către ASP.NET MVC și nu m-am uitat înapoi, ceea ce a spus că trebuie totuși să mențin mai multe aplicații WebForms foarte mari. Iată ideea mea:

WebForms
Utilizați-le atunci când aveți o viață gravă care au legătură cu grilele. Comenzile grilei sunt foarte frumoase atunci când aveți un set de date simplu, care se potrivește frumos într-un format tabelar și doriți să oferiți utilizatorilor un mod simplu de actualizare a înregistrărilor. Da, știu că MVC 4 are un tip de listă Ajax foarte plăcut pe care îl poți folosi, care funcționează excelent, dar, în afacerea noastră, avem adesea nevoie să rulăm ceva ieri, iar rețelele de modă veche funcționează excelent, iar utilizatorii sunt fericiți să fie capabil să traverseze o grilă cu bucurie. Pentru mine, acesta este cu adevărat cel mai bun lucru despre WebForms pentru mine; dar, așa cum a subliniat Ryan , WebForms poate fi o mare mizerie, deoarece joci ambele părți a gardului dintr-un fișier de cod în spate. Poate fi atât un trandafir, cât și un ghimpe în același timp pentru a păstra toate lucrurile dvs. de tip controler amestecate cu vizualizările dvs.

MVC
Utilizați acest lucru atunci când doriți cu adevărat să vă rulați propriul dvs. și aveți posibilitatea de a porni o aplicație de la zero. A avea o aplicație MVC clar definită este ceva mai mult pentru a începe, dar beneficiile sale în mentenabilitate depășesc costul inițial de configurare. Dacă doriți să faceți interacțiuni interesante Ajax, preferați să scrieți modelul cu cod, cum ar fi adresele URL și rutele curate, și să puteți controla întregul flux al aplicației, atunci acesta este cu siguranță calea de urmat. la început, dar cred că este cea mai bună opțiune pentru aplicațiile ecologice.

În concluzie, pentru mine, se reduce la grile și! grile. 🙂

Comentarii

• +1 pentru imaginea frumoasă livrată cu ” redând ambele părți ale gard dintr-un fișier codat în spate „.
• Foarte util acesta. ‘ fac o aplicație bazată pe grilă foarte grea și am ‘ am exclus silverlight, xbap și a ajuns la un spectacol între aceste două.

Experiența mea:

• Am scris proiecte CakePHP timp de un an.
• Am finalizat un proiect Webforms de dimensiuni medii timp de șase luni.
• Am lucrat la un proiect Windows Forms timp de trei ani.

După această experiență, am încercat să scriu o altă aplicație folosind webforms și m-am frustrat după ce m-am luptat aproximativ o zi cu modul în care webforms încearcă să protejeze dezvoltatorul de realitatea că „dezvoltă o aplicație care folosește html, javascript și css.

Am încercat apoi MVC și, având un control mai direct asupra rezultatului (și ceva experiență cu paradigma MVC de la CakePHP) am reușit să finalizez acea aplicație simplă exact așa cum am dorit-o în aproximativ 1/2 pe zi.

Disponibilitatea cadrelor UI puternice precum jQuery foarte mult eli elimină apelul de a renunța la controlul direct al rezultatului în favoarea utilizării componentelor UI prefabricate adesea voluminoase.

Comentarii

• @JimG – Uhh , orice presupune ca o persoană să introducă înregistrări fără asociații interesante într-o bază de date și să-i ceară pe persoana respectivă sau pe altcineva să le citească / tipărească într-un alt punct poate fi practic schelat folosind un cadru MVC. Acordat, asta nu este ‘ t majoritatea aplicațiilor, dar ‘ este un demult mult mai mult decât poți face cu Forms. Cred că -1 vă demonstrează punctul meu de vedere.
• Că ‘ este 1/4 dintr-o zi.
• Dar dacă cerințele se ridică la ” Am nevoie de o aplicație cu două roluri, unul pentru a înregistra niște informații, celălalt pentru a le privi și nu ‘ nu sunt grijă cum arată. ” Atunci, da, ‘ este destul de realizabil.
• îmi pare rău, dar dezvoltarea unei aplicații webforms pentru a introduce date și a vizualiza datele este atât de simplă, încât se poate face în câteva ore. crearea structurii unei aplicații MVC, controlere, vizualizări și acțiuni, ar dura aceeași perioadă de timp, dar nu vă va duce la un produs finit.
• @Dementic De obicei, pentru o aplicație simplă MVC, se creează modele, apoi schele controlere și vizualizări și / sau generează controlere / vizualizări schele. Nimic care consumă mult timp acolo.

Prefer formele web, deoarece fundalul meu este dezvoltarea ferestrelor.

Viteza dezvoltării este o problemă cheie și pot transmite cu ușurință o problemă cuiva din India pentru a o rezolva peste noapte cu formulare, de asemenea, dacă am o problemă de viteză pe o pagină, o carte foarte bună despre asp.net viteza este la îndemână (Rick Kiessig este omul).

webforms este pentru ex windows people mvc este pentru web people

dar, în lumea modernă, unde Rick a scris o carte minunată , cu serverele în creștere zilnică și codificatorii ieftini în India, ei bine, formularele web au avantajul

Cei 2 centi ai mei sunt să utilizați întotdeauna ASP.NET MVC pentru proiecte noi, dacă aveți opțiunea. În opinia mea, formularele web nu sunt o modalitate bună de a dezvolta aplicații web, punct.

Cred că abstracția REST-ului de bază este rea, întregul model de postback este rău, modul în care html / css este predat cu o dependență pe editorul GUI este rău, accentul pus pe lucruri precum vrăjitorii și GUI-urile pentru a configura lucrurile este rău, adresele URL sunt rele.

Comentarii

• ai putea explica mai multe detalii de ce crezi?
• Cred că a revenit la abstractizarea REST de bază, a revenit întregul model de postback, modul în care html / css este predat cu dependența de editorul GUI este rău , accentul pus pe lucruri precum vrăjitorii și interfețele grafice pentru a configura lucrurile este rău, adresele URL sunt rele etc. și așa mai departe

Am citit toate răspunsurile și consider că experiența mea personală ar adăuga ceva la răspunsurile de mai sus.

Cu 3-4 ani în urmă, am dezvoltat 2-3 proiecte de site-uri web folosind Webforms. În acea perioadă, MVC nu era în jur sau nu am auzit de asta. Dezvoltarea a fost în mod natural (veneam de la dezvoltarea Win-formulare, fără experiență anterioară de dezvoltare web) rapidă pentru mine, deoarece nu trebuie să învăț HTML în detalii, iar controalele web au ajutat foarte mult (foarte mult, a făcut viața mai ușoară) .

Acum, după tot acest timp, nu mai lucram la niciun proiect web până de curând și pur și simplu construiam niște aplicații Windows folosind WPF.

Cu câteva zile în urmă aveam o idee pentru un site-ul web și m-am gândit să-l dezvolt: de data aceasta în MVC (deoarece s-a vorbit peste tot, în afară de faptul că am nevoie să învăț fie, așa că aleg MVC). / p>

Deci, diferențele cheie pe care le găsesc b / n sunt următoarele: –

• Pentru cineva care vine din dezvoltarea Windows, formularele web vor fi întotdeauna favorabile. Asp Curba de învățare .net pentru un dezvoltator Windows este puțin abruptă

• Pentru cineva care vine din dezvoltarea web într-o altă tehnologie, MVC va fi favorizat, deoarece se bate în joc Cele mai recente dintre toate.

• Dezvoltarea este mai ușoară și mai curată în MVC dacă sunteți echipat cu cunoștințe bune despre HTML și CSS

• Implementarea este încă o problemă. În formularele web trebuie doar să copiați și să inserați. Dar, acest lucru necesită anumite lucruri de făcut.

Pe scurt, amândoi vor rămâne aici o vreme.

Nu am văzut această considerație prezentată încă între cele 15 răspunsuri existente la acest fir, dar cred că „Merită luat în considerare.

Din experiența mea, Web Forms este mai asemănător cu Win Forms și WPF decât MVC. Având în vedere acest lucru, cred că s-ar putea lua în considerare alegerea formularelor web atunci când echipa are cea mai mare experiență în acest tip de tehnologie sau atunci când proiectul Web Forms va furniza o interfață pe același set de date ca un formular de câștig existent (sau dezvoltat concomitent) sau Proiect WPF. Acest lucru permite dezvoltatorilor să treacă mai ușor între proiecte, deoarece logica aplicației poate fi destul de similară între cele două.

După cum au subliniat alte răspunsuri, dezvoltarea cadrului MVC este mai asemănătoare cu dezvoltarea web în Ruby, PHP, Python etc. decât omologii săi Microsoft; deci, în mod firesc, alegerea MVC poate fi influențată de experiența echipelor din acele domenii, împreună cu factorii prezentați în alte răspunsuri.

Comentarii

• + 1 Cu siguranță un argument rezonabil pentru Webforms. Mi-e teamă că echipele urmează această mentalitate pentru a evita să învețe lucruri noi. MVC este plin de multe modele care ar putea să nu fie familiare unei echipe. Învățarea acestor tipuri de modele și implementarea lor conduc la o mai bună aderență la principiile SOLID, ceea ce se traduce printr-o mai bună întreținere generală. Aceste tehnici dovedite sunt, de asemenea, adevărata cheie a reutilizabilității.

Motivul nostru pentru a nu merge pentru MVC acum câțiva ani a fost o tehnologie imatură de la Microsoft. În ultimii ani, suntem acum la o versiune mai matură (4) și MS pare să fi aflat unde merg cu asta.Cu toate acestea, suntem încă reticenți în dezvoltarea de aplicații majore LOB utilizând MVC, deoarece caracteristicile pe care dorim să le folosim în versiunea 4 necesită un server Windows 2012 (re socketuri web prin IIS8). Cred că peste încă un an vom accepta mai mult MVC, deoarece sperăm că vor fi disponibile mai multe controale ale terților, tehnologia se va stabili și vom avea infrastructura care să o susțină.

Comentarii

• V-ar deranja să enumerați unele dintre aceste funcții despre care spuneți că necesită Windows Server 2012?

Această decizie depinde de preferințele dvs., de cerințele dvs. sau chiar de cunoștințele și experiența dvs.

Timpul pentru instruirea învățării MVC sau timpul pentru a obține o livrare. Toate aceste lucruri contează pentru a alege una sau alta abordare.

Nu este că una este mai bună decât alta, pur și simplu atât abordarea, cât și cadrele au argumente pro și contra.

Personal, favorizez MVC 3, Vă recomand să încercați propria experiență, dar trebuie să spun că programul din MVC este un mod curat, distractiv, flexibil, extensibil, sigur și structurat.

Cu respect,

Singurul motiv pentru care aș alege WebForms în loc de MVC este pentru că aveți mult mai multe controale de interfață terță parte pentru WebForms decât MVC. Aleg MVC pentru că am lucrat prea mult cu WebForms și vreau să lucrez cu ceva proaspăt / nou, dar totuși de la MS shop 🙂

Practic, nimic nu te împiedică să oprești viewstate în WebForms și să folosești ViewModels și buclele if / for în loc de legarea modelului și comenzile de pe server.

Este acest cod WebForms sau MVC:

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

Singura limită pe care am găsit-o în WebForms este că, dacă utilizați injecția / inversarea Control, nu poți avea injecție de constructor, deoarece paginile WebForms trebuie să aibă un constructor fără parametri, deci trebuie să folosești injecția de proprietăți. Este într-adevăr o problemă atât de mare?

ASP.NET MVC este într-adevăr un răspuns la Ruby și noul mod, mai modern și (IMO) mai bun de a decupla browserul (clientul) de server cât mai mult posibil.

Formele web ASP.NET vă oferă mult control asupra clientului din partea serverului, cu acces direct la aproape totul. În esență, vizualizarea și controlerul sunt una în același lucru, ceea ce vă oferă multă putere și, de cele mai multe ori, o mulțime de mizerie.

ASP.NET MVC separă vizualizarea și controlerul prin detașarea cuplajului strâns al un fișier .aspx și fișierul .aspx.cs care îi însoțește în formele web.

În esență, diferența constă în prelucrarea pentru a vă afișa datele cu mult mai mult (de obicei toate) la fișierul de vizualizare și lăsând logica de afaceri și restul în controler, păstrându-le pe amândouă mai curate prin convenție, dar și cu un acces mai mic unul la altul decât permite formularele web.

Comentarii

• Deci CÂND ar trebui să fie favorizate formele web în locul MVC? Acest lucru nu răspunde la întrebarea originală despre postere.
• @WeekendWarrior – Când doriți un acces mai mare la server de către client, alegeți formulare web. Dacă doriți mai multe decuplări ale clientului / serverului în codul dvs., alegeți MVC. La sfârșitul zilei, ambii fac exact același lucru. Filtrele de redirecționare fac același lucru cu adresele URL MVC și puteți muta codul de webforms în spate la un nivel mediu separat pentru a-l decupla mai mult. weblogs.asp.net/scottgu/archive/2010/01/24/…
• În ceea ce privește al treilea punct, logica de afaceri ajunge în fișierul .aspx.cs – cred că este vina dezvoltatorilor. ‘ nu este / presupus / să fie acolo. În Webforms, .aspx este ” vizualizare „, .aspx.cs este ” controller ” echivalent, destinat procesării codului care se referă direct numai la interfața de utilizare prin sondarea unui strat de business sau a unui strat de fațadă de business cu granulație grosieră. Faptul că oamenii pun logica afacerii în .aspx.cs este doar o programare slabă. De asemenea, ar putea pune logica de afaceri chiar în vizualizarea în MVC! MVC nu ‘ forțează separarea acestor lucruri.
• În esență, el are mai multă dreptate decât alte răspunsuri postate aici. ASP.net este ideea de bază din spatele unei familii modulare de tehnologii web, așa cum a fost creată de Microsoft. Modulul MVC ASP.net ar putea fi un hype temporal, dar cu siguranță nu este ultimul, totul începe cu ASP.net, deci atunci când alegeți ASP.net, dacă nu credeți că MVC nu este ceea ce vă place, poate că sunteți mai mult în ceva altfel OWIN sau …, ceva mai avansat, sau a creat propriul cadru pentru sarcinile tale. S-ar putea să nu aveți nevoie nici măcar de ASP.MVC și săriți-l și mergeți la Owin sau Katana, dar până când nu folosiți asp.net

În opinia mea, acestea sunt suficient de legate și au aproximativ aceleași capacități pe care ar trebui să le apară până la preferință.

Un excelent dezvoltator WebForms poate produce un produs la fel de puternic ca un dezvoltator MVC excelent. Dar marele dezvoltator WebForms care încearcă să se forțeze să adopte MVC va fi scurt. Același lucru este valabil și pentru un dezvoltator MVC grozav care oferă WebForms o fotografie.

Nu sunt entități complet separate și, atâta timp cât Microsoft continuă să le susțină pe ambele, cred că veți vedea în continuare un grup mixt de dezvoltatori excepționali pentru fiecare.

Este vorba despre alegerea personală, presupunând că suntem cu toții pricepuți la tehnologia pe care o folosim. Folosesc abordarea de proiectare WebForms de mulți ani și trebuie să spun că singurul dezavantaj este că, datorită abordării sale simpliste, mulți oameni nu își iau timpul pentru a descoperi capacitățile sale vaste.

Am folosit recent MVC pentru a finaliza un proiect și, deși îmi place foarte mult abordarea de proiectare a dezvoltării aplicațiilor (care vă oferă mai mult control, curățarea adreselor URL, SOC, etc), nu este foarte mult , că WebForms nu poate. De fapt, apariția jQuery și a funcționării sale cu WebForms (precum și MVC) a făcut ca aceste argumente să nu fie o problemă. Și când oamenii vorbesc despre separarea preocupărilor ca un avantaj pe care MVC îl are față de MVP, îi întreb cât de mult ei știu despre programarea orientată pe obiecte și cât de mult pun în aplicare principiul abstractizării și polimorfismului.

În prezent mă simt confortabil folosind ambele tehnologii și aleg și aleg în funcție de situație. pentru dvs., dar adevărul rămâne că nu toată lumea își ia timpul să învețe în profunzime de ce este capabilă o anumită tehnologie.

Comentarii

• Ditto on vastele capacități ale formelor web. Majoritatea oamenilor văd roțile de formare ale formelor web și compară acest lucru cu MVC.
• Nu există prea mult sens să înveți o abstracție pe lângă HTML și Javascript în zilele noastre (chiar și în zilele noastre) 2013). ‘ nu vă va ajuta la niciun fel de oportunități viitoare. HTML și Javas cript este bine așa cum este. Luptarea este o bătălie pierdută.

Când mă confrunt cu o problemă de programare, mă uit deseori la web pentru răspunsuri. Webforms are o mulțime de informații / componente pentru a face aproape orice. În MVC, din cauza surselor mai puține online și a straturilor de abstracții necesare pentru ca ceva să funcționeze a pus o limită în lucrurile pe care aș putea să le fac odată. Totalul MVC îmi ucide productivitatea ca dezvoltator, în timp ce cu Webforms nu este. Așa că, deocamdată, mă mențin la formele web până când MVC se maturizează suficient pentru a-l înlocui.

Ei bine, WebForm-urile au mai multe resurse de învățare disponibile (pur și simplu datorită faptului că sunt mai vechi) și, prin urmare, noii programatori care nu știu „t” vor fi mai predispuși să găsească informații referitoare la această tehnologie mai veche, spre deosebire de lucrurile mai noi, cum ar fi MVC.

Programatorii seniori / experimentați sunt mai în vârstă și vor fi mai competenți în tehnologia mai veche, datorită faptului că „au programat în ea mai mult decât au aveți în cea mai nouă.

Dacă nu puteți cheltui banii și efortul pentru a-i face pe băieții dvs. să fie mai pricepuți la MVC precum sunt în aplicațiile WebForms, veți încerca, fără îndoială, să renunțați la actualizarea la noul platformă cât mai mult timp posibil.

Deci, prezintă mai multe probleme logistice: Beneficiile MVC depășesc costul în termeni de calitate mai mică și timpul de implementare? Dacă am un site scris în întregime în WebForms, ar merita efortul și banii să integrez MVC în acesta?

După cum sa afirmat de un comentator anterior, MVC vă împiedică, de asemenea, să atingeți același nivel de interfață cu controlerului așa cum ați putea cu WebForms. În timp ce eu sunt „pentru toți utilizatorii să împiedice lucrurile să învețe / să învețe” lucrurile, totuși poate fi în mod nerezonabil ca echipele să implementeze / să implementeze un program care se menține în mod fanatic la acea paradigmă pentru tot ceea ce scriu.

Cred că decalajul dintre aceste două tehnologii nu este la fel de mare ca pe vremuri.

• Formularele web pot utiliza motorul de rutare pe care MVC îl folosește (sau ceva foarte similar).
• Managerul de scripturi poate combina scripturi, încărca dintr-un CDN și chiar întârzia încărcarea scripturilor.

Pentru a răspunde direct la întrebare, cred că se reduce la preferință. și / sau care este proiectul. Ambii au o abordare semnificativ diferită a dezvoltării. Personal, m-am străduit să mă îndrept spre MVC, dar totuși îmi place să lucrez cu Webforms. Cred că răspunsul la faptul dacă ar trebui să utilizați MVC sau Webforms este să decideți prin experimentarea ambelor tehnologii.

Comentarii

• Formele web și MVC recomandă în mod implicit o atitudine de dezvoltare web radical diferită, acest lucru este important , puțini dezvoltatori deviază din ” ” implicit. Ambele pot fi folosite pentru a realiza același lucru.