Mikor kell előnyben részesíteni az ASP.NET WebFormeket az MVC-vel szemben

Úgy tűnik, hogy a Webforms vs MVC jelenleg aktuális téma. Mindenki, akit ismerek, az MVC-t tartja a következő nagyszerű dolognak. A benne levő enyhe csöppségekből rendben látszik, de nem, nem hiszem, hogy a webformák vége lesz.

Az érvelésem és az indoklás, hogy miért választanák a webformákat az MVC helyett, inkább az üzleti perspektívával kapcsolatos, nem pedig az, hogy melyik jobb a másiknál.

Az idő / pénz a legfőbb oka annak, hogy a webformákat az MVC helyett választják.

Ha a legtöbb a csapat ismeri a weblapokat, és nincs ideje arra, hogy felgyorsítsa őket az MVC-n, előfordulhat, hogy a létrehozandó kód nem megfelelő. Az MVC alapjainak elsajátítása, majd az ugrás és az összetett oldal elvégzése, amelyet meg kell tennie, nagyon különböző dolgok. A tanulási görbe magas, ezért ezt be kell számolnia a költségvetésébe.

Ha nagy weboldala van, amelyeket minden weblapba írt, akkor hajlamosabb lehet új oldalakat weblapokban létrehozni, hogy ne ” nincs két nagyon különböző típusú oldala a webhelyén.

“Nem mondom” itt minden vagy semmi megközelítés, de ez megnehezíti a kód fenntartását, ha mindkettő fel van osztva , főleg, ha a csapatban nem mindenki ismeri az MVC-t.

Cégem nemrég három tesztoldalt készített az MVC-vel. Leültünk és megterveztük őket. Az egyik kérdés, amibe belefutottunk, hogy a legtöbb képernyőnk a Nézet és Szerkesztés funkció ugyanazon az oldalon. Végül egynél több űrlapra volt szükségünk az oldalon. Nincs nagy dolog, kivéve akkor nem használnánk a főoldalunkat. Ezt meg kellett újítanunk, hogy a weblapok és az MVC oldalak is ugyanazt a főoldalt használhassák a közös megjelenéshez. Most van egy extra fészkelési rétegünk.

Teljesen új mappastruktúrát kellett létrehoznunk ezekhez az oldalakhoz, hogy az megfeleljen az MVC megfelelő elválasztásának.

Úgy éreztem, hogy túl sok fájl van 3 oldalra, de ez az én személyes vélemény.

Véleményem szerint weblapokat választana az MVC helyett, ha nincs ideje / pénze arra, hogy fektessen be webhelye frissítésébe, hogy használhassa az MVC-t. Ha ezt félig-meddig megközelíti, nem lesz jobb, mint a mostani webformák. Sőt, még rosszabbul is beállíthatná ezt a technológiát a vállalatában, ha összezavarodik, mivel a felső vezetés valami alacsonyabb rendűnek tekintheti azt, amit tud.

Megjegyzések

• Ez egy jó válasz. +1-et adtam Önnek, mert nagyra értékelik személyes tapasztalatait. De ez kudarc a fejlesztők tapasztalat- és készséghiánya miatt, amelyet elkerültem . Nem vagyok meggyőződve arról, hogy a Microsoft egyszerűen az MVC tanulási görbéjétől való félelem miatt választja-e az elavult technológia megjelölését. Ez lehet a helyzet, de én ‘ még nem meggyőzve.
• @ P.Brian.Mackey – Nem mondtam ‘, hogy a formák fejlődése gyorsabb, mint az MVC. Azt kérted, hogy hagyd ki belőle ezt az érvet. Idő és pénz érvelése a személyzet kiképzésére egy másik érv. Az MS ‘ nem jelölte meg az elavult webformákat egyetlen nagy okból: Az vállalati ügyfelek évek óta webes klienseket fejlesztettek weblapokban, és nyertek ‘ nem várja, hogy időt és pénzt kell fektetnie a frissítéshez.
• @Raynos – Ha a csapatban mindenki jártas volt az MVC-ben, és a céged új projektet indított, akkor az egyetlen ok, amiért láttam, hogy valaki weblapokat választ, az a személyes választás.
• Közelről ismerem mindkét technológiát. Az összes webes projektem az mvc-vel történik, és egy olyan cégnél dolgozom, ahol szabadon uralkodhatok, bármit megteszek, ami a legjobb. Mindig az MVC-t választom.
• A Webforms-szal kezdtem, és miután felfedeztem az MVC-t, erre váltottam. Nem tudom, hogy ‘ hogyan tudná bárki megvédeni a webformákat. Az oldal életciklusa és egy űrlap a teljes oldalhoz? Viccelsz velem? Valószínűleg a Yahoo sitebuilder volt a célja a vásárló számára, de még ők sem ‘ akarták ezt a szemetet.

3 évig fejlesztettem ki az ASP .Net WebForms alkalmazásokat, és egy nap után elvégeztem egy MVC oktatóanyagot. Az MVC szinte MINDIG a jobb megoldás. Miért?

• Az oldal életciklusa egyszerűbb és hatékonyabb
• A html vezérlőkön kívül nincs olyan, hogy vezérlők. Nem szükséges hibakeresése a kimeneten, hogy lássa, mit hoz létre az ASP .Net.
• A ViewModels hatalmas hatalmat nyújt Önnek és kiküszöböli a kézi vezérlési kötés szükségességét, és kiküszöböli a kötéssel kapcsolatos számos hibát.
• Több űrlap is lehet egy oldalon. Ez a WebFormok komoly korlátozását jelentette.
• Az internet hontalan, és az MVC jobban illeszkedik a web architektúrájához. A Webforms bemutatja az állapotot és a hibákat a ViewState bevezetésével rendelkezik vele. A ViewState automatikus és a háttérben működik, ezért nem mindig viselkedik úgy, ahogy szeretné.
• A webes alkalmazásoknak manapság az ajaxszal kell működniük. Nem elfogadható a teljes oldal betöltése. Az MVC sokkal jobbá, könnyebbé és hatékonyabbá teszi az ajax-ot a JQuery használatával.
• Mivel több űrlap is lehet egy oldalon, és mivel az architektúra Az URL-ekre irányuló hívások vezérelhetik az olyan funky dolgokat, mint az ajax, más formát tölthetnek be, például egy szerkesztési űrlapot az aktuális oldalra a JQuery segítségével. Miután rájött, hogy ez mit tesz lehetővé, egyszerűen csodálatos dolgokat tehet.
• ASP .Net WebForms nem csak egy absztrakció a html felett, hanem egy rendkívül összetett is. Néha furcsa hibát kapna, és a szükségesnél sokkal tovább küzdene vele. Sok esetben valóban láthatja, hogy mit csinál rosszul de nem tud mit kezdeni ez ellen. Végül furcsa megoldásokat tesz.
• A WebForms nem jelent jó technológiát a tervezők számára. A tervezők gyakran szeretik közvetlenül a html-t. Az MVC-ben ez A WebForms fél napos munka.
• Ahogy a webplatform gyorsan fejlődik, a WebFormák nem fognak lépést tartani. Nem a HTML5 új címkéinek vagy szolgáltatásainak ismeretében továbbra is ugyanazokat a tartalmakat jeleníti meg, hacsak nem kap (gyakran) drága harmadik fél vezérlőket, vagy nem várja meg, amíg a Microsoft kiad egy frissítést.
• A WebForms vezérlői sokféleképpen korlátozzák Önt. Az MVC-ben egyszerűen megragadhat egy JQuery könyvtárat, és integrálhatja azt a sablonjaiba.

Tudom, hogy a WebFormák fejlődésével a fenti kérdések némelyikével foglalkoztak, de ez volt az eredeti tapasztalatom. Összességében rendkívül nehéz lenne üzleti esetet találnom a WebForms számára, hacsak egy projekt már nem használja.

Megjegyzések

• +1 több formára mutatva. Ráadásul az a tény, hogy a HTML webes űrlapok generálnak, legtöbbször nem túl SEO-barát (mint például: a nézetállomány nagy darabjai az oldal tetején)
• 100% -ban egyet kell értenem ezzel a válasszal. A nap végén a WebForms sokkal nehezebben teszi az ügyfeleket (html / böngésző). Szó szerint meg kell küzdenie a keretrendszerrel, hogy valami megvalósuljon. Egy aspx oldal sokkal több kódot kap a szerver vezérlésének köszönhetően, mint általában egy cshtml oldal. @ šljaker Ha elkezdi kikapcsolni a ViewState-t és elkerüli a kiszolgálóvezérlőket, akkor ‘ akkor elhagyta a WebFormák nagy részét. Nem ‘ nem látom ezt az érvet különösebben meggyőzőnek.
• A WebFormokban egyszerű HTML-vezérlők is lehetnek, senki sem kényszeríti a kiszolgálóvezérlők használatára. Rendelkezhet teljes hontalan webformával, senki sem kényszeríti a ViewState használatára. Használhatja a teljes ajaxot és a jQuery-t a Webformokban, senki sem korlátozza a jQuery használatát. Megvalósíthatja az URL-útválasztást, senki sem kényszeríti statikus fájlalap URL használatára. Az oldal manuális megrajzolása CSS-sel annyi időt emészt fel, amennyire az MVC-nek szüksége van. A HTML-oldalt közvetlenül a Webformon is megtervezheti.
• @mjb: Ha nem használ ‘ kiszolgálóvezérlőket, ViewState-et és így tovább, miért használja egyáltalán a WebFormust, amikor Az MVC közelebb áll ahhoz, amit ‘ csinál? ‘ olyan, mint amikor traktorral munkába hajtunk, de nem terepezünk, vagy nem használjuk a lapátot / kapát vagy a stabilizátor rudakat. Ezen a ponton miért ne használna csak autót?
• @Tjaart Nem egészen helyes, hogy az ASPNET oldalon nem lehet több űrlap.Lehet annyi űrlap, amennyit csak akar az ASPNET oldalon, de csak egy kiszolgáló űrlapja lehet – űrlap a runat = ” kiszolgálóval ” attribútum.

E-mailt küldtem Scott Guthrie , a Microsoft MVC szakértője . És valószínűleg a legalkalmasabb ember erre a kérdésre. Kedves volt válaszolni:

“A különböző ügyfelek különböző programozási megközelítéseket keresnek, és sokan szeretik a WebFormust, és azt hiszik, hogy ez nagyszerű. Mások szeretik az MVC-t és szerintem nagyszerű. Ezért fektetünk be mindkettőbe. “

Tehát nekem ez azt mondja, hogy ez nem technikai kérdés. Inkább “puha kérdés”, ha akarod. Az egyik személyes preferencia. Ez összhangban van azzal, amit többen mondtak.

Köszönöm a válaszokat.

Hozzászólások

• Scott Guthrie feltalálta az ASP.NET MVC keretrendszere, miközben a Londonból Seattle-be tartó visszaútra repült 2006/7-ben. Ha jobban belegondolunk, nagyjából ő találta ki a .NET-t is ( hu.wikipedia.org/wiki/Scott_Guthrie ). Hívás ” szakértőnek ” óriási lebecsülés 😉
• Ez ‘ Scott Guthrie szép politikai válasza. Ha ő maga a saját webalkalmazását fektette be, akkor ‘ látna egy MVC projektet, és bármi, ami ‘ nem történhet meg az MVC-ben, A Silverlight lenne a tartalék. Don ‘ ne vegye ezt negatív megjegyzésnek a WebForms felé, azt hiszem, hogy a WebForms kiválóan alkalmas kisebb hatókörű belső alkalmazásokhoz, amelyek kihasználhatják a harmadik felek által gyártott komponenseket, például a Telerik által létrehozottakat. Örülök, hogy ‘ örülök, hogy a Microsoft mindkét technológiával halad előre.
• ” Scott Guthrie feltalálta az MVC keretrendszert az ASP számára A .NET repülés közben ” szerintem ez valóban elbagatellizálja az MVC-t.

Ez egy elavult kérdés, sok válaszsal, de egyik sem megvan a válasz, azt vártam volna, hogy felsorolom.

A rövid válasz:

• Használja az ASP.NET MVC-t, ha webes alkalmazást kíván korszerűen programozni, modern programozással. konvenciók és az ipar átfogta az ASP.NET platform mintáit. A lentről elvárják, hogy tudja, hogyan működnek a HTML és az ügyféloldali erőforrások (Javascript, CSS), valamint fel kell mozdítania az MVC programozási gondolkodásmódját, amelynek meredek a tanulási görbéje, de hirtelen végéhez ér, ha megértette.
• Használja az ASP.NET webes űrlapokat, ha GUI -centrikus, RAD (Rapid Application Development) , a fogd és vidd megközelítés a prototípusok nagyon gyors elkészítéséhez, azaz a nyomógomb / adatrács viselkedése 15 percen belül bekötött, és a megoldást nem a fejlesztők. Vagy Használja az ASP.NET webes űrlapokat, ha rendelkezik háttérrel a GUI vagy a Windows Forms fejlesztésben, és át kívánja adni tudás az internetre.

Ahhoz azonban, hogy ezt megfelelően lássa, meg kell értenie mindegyikük történetét.

Az ASP.NET webes űrlapok voltak a Microsoft válaszai akik dinamikus webalkalmazásokat építettek a Visual Basic 6 Ac használatával tiveX vezérlők, a szerveren található VB6 DLL-ek és az ASP Classic. Abban az időben a webfejlesztés ezen Microsoft eszközök segítségével igazi zűrzavart okozott. A .NET-keretrendszer teljes egészével együtt, amely a Microsoft kimenete volt, lényegében visszatért a rajztáblához arról, hogyan lehet eredményes üzleti programozást végezni a Windows veremben, az ASP.NET Web Forms a maga korában csodálatos és gyönyörű volt.

Az egész megközelítés az volt, hogy a fejlesztők mindkét világ legjobbjait hozzák létre a Windows alkalmazásfejlesztéshez nagyon hasonló dologhoz, de az internetes szolgáltatások erejével.Az ötlet az volt, hogy ugyanúgy, mint egy VB6 / WinForms “Form” (egy ablak) esetén, ugyanúgy egy weboldal is egy forma (akárcsak egy ablak, lásd) , és ezen az űrlapon áthúzhat címkéket, szövegdobozokat, adatrácsokat, gombokat és egyéb dolgokat, amelyekhez a VB / WinForms GUI fejlesztői megszokták.

Ahhoz, hogy egy gomb csináljon valamit, húzás után egyszerűen kattintson duplán a tervezőbe, és fellendüljön a kódszerkesztőben, és megmondja az űrlapnak, mit kell tennie, amikor erre a gombra kattint. “esemény történik. A Windows GUI fejlesztői pontosan így készítettek szoftvert a VB6 és a versengő eszközök GUI eszközei segítségével, kivéve, hogy a kód most a szerveren fut! Ejha!

Ez 2002-es technológia volt. Csodálatos és gyönyörű a maga idejében válaszként az internetre -engedélyezett GUI megoldások a RAD fejlesztéshez hatalomérzetet hozott a szoftverfejlesztők zűrzavaros világába, amelynek üzleti célkitűzései voltak, amelyek megvalósításához szükségesek voltak.

Sajnos ez a programozási modell annyira hangsúlyozza a Windows GUI programozás metaforáját, hogy magában hordozza a szükséges megvalósítási részletek terheit. , az összes máshova nem tartozó teherautó poggyász elengedhetetlen az esemény életciklusainak és az egyszerű HTML és szkript csúnya részleteinek elhárítása, amelyeket ezek a fogd és vidd komponensek és vezérlők adnának ki. És a nap végén a valódi alkalmazásokat támogató fejlesztőknek óhatatlanul mélyre kellett ásniuk ezeket az összetevőket, vagy meg kellett írniuk a sajátjukat, következésképpen csatákat vívtak ezzel az infrastruktúrával, amelyek olyan halmokat hagytak maguk után, amelyeken óriási hajó, húzott haj és könnyek.

Biztonsági másolat készítése. Mosd meg a kezed. Vizsgáljuk meg újra az üzleti problémát. Melyek az üzleti céljaink?

webalkalmazásokat kell létrehoznunk és kezelnünk. Korlátozásaink az, hogy rendelkezünk a világhálóval, amely a HTTP-n, a HTML-en, a Javascript-en és a CSS-en található, és a szerveren üzleti szabályaink vannak, adatbázisunk és egy kis maroknyi nagyszerű programozási nyelv (pl. C #). Valóban szükségünk van erre a Windows GUI metaforára a fejlesztési módszertanunk hajtásához? Miért nem lehet csak az alkalmazás problémáira összpontosítani és felszámolni a GUI metaforákat?

Itt jön be az ASP.NET MVC. Ez egy olyan fejlesztők lázadásából indult ki, akik magukat “Alt.Net” -nek nevezték, akik vissza akartak térni a megfelelő és tiszta szoftverfejlesztési elvekhez. Nincs több szóváltás és felhajtás, csak az üzleti célokra és a szoftveres bevált gyakorlatokra kell összpontosítani.

Ez valójában ezt jelenti ebben az esetben:

1. Az aggályok elkülönítése . Például egy adatkomponensnek nem kell tudnia, hogyan fogják megjeleníteni az adatait, és a nézetjelölést sem szabad megterhelni az adatbázis-kapcsolat konfigurációjának részleteivel, és ily módon a fejlesztő szerkesztéskor az aggodalomra okot adó területre összpontosíthat. tesztelési kód.
2. A HTML és a kapcsolódó erőforrások apró szemcséjének való kitettség és teljes támogatása . A Webes űrlapokban a HTML el van ragadva, a fejlesztők nem vesznek részt ebben. Az ASP.NET MVC-ben a fejlesztőket inkább ösztönzik e részletek kezelésére; valójában ez szükséges. Előnye, hogy a fejlesztő újra megtanulhatja értékelni a HTML, CSS és szkript tiszta szemantikáját, és együtt dolgozhat vele , nem pedig ellene.
3. Üzleti objektumok tesztelhetősége . A vezérlők és a modellek sokkal jobban megfelelnek az automatizált egységek tesztelésének, így a megvalósítások érvényesíthetők az üzleti célok elérése érdekében, és a változások igazolhatók abban, hogy nem törnek össze. A webes űrlapokkal nehéz volt tesztelni, mivel az összetevőket nem úgy tervezték, hogy egyedileg tesztelhessék őket, és a teljes fejlesztési kimenet oldal űrlapok és eseményeik életciklusa körül forog, az üzleti logika és a prezentációs logika mélységében összefonódva.

Ne feledje, hogy a HTML már nagyon magas szintű jelölőnyelv, ahogy a Javascript is egy magas szintű programozási nyelv. Az egész történet más lett volna, ha az Assembly nyelvével és a C-vel foglalkozunk.

Bővítve a 2. helyet, akkor az ASP.NET MVC másik célja az, hogy lehetővé tegye a fejlesztők számára, hogy rendszerezzék a a megoldások “nézet” részét és kihasználják azt a gazdag alapot, amelyet az ipar többi része a front-end kliens platformra épített.

Megállapíthatja, hogy az ASP.NET MVC fejlesztői otthonosan érzik magukat gazdag Javascript könyvtárak és kliensoldali sablonozási technikák felhasználásával, anélkül, hogy a szerveroldali architektúrával harcolnának. Eredetileg ez nem volt az ASP esetében.NET Web Forms, mert a Web Forms egyáltalán nem akarja, hogy a HTML-t vagy a szkriptet nézze, kivéve, ha valóban muszáj , ebben az esetben vigyázzon, ez nem a gyenge szívének felel meg .

Megjegyzések

• Ez jó válasz, de az # 1 és a # 2 téves (a WF nem igényli, hogy egy komponens tudja, hol vannak az adatai származik, ez egy lehetőség, és mindig hozzáadott HTML-t az ASPX fájljaihoz, hogy támogassa a megjelenített asp címkéket. Soha nem kellett mélyrehatóan ásnia és harcolni a vezérlőkkel, hacsak nem egy fejlesztőnek szánt ASP funkcióhoz próbáltál hozzáférni kölcsönhatás. A nagy pontok a tesztelhetőség és a tervezési minta.)

Teljes és teljes megtérő vagyok az ASP.NET MVC-hez, és nem néztem vissza, ez azt mondta, hogy továbbra is fenn kell tartanom néhány nagyon nagy WebForms alkalmazást. Itt állok vele:

WebForms
Használja ezeket, ha komoly nehézségei vannak rácsokhoz kötődik. A rácsvezérlők nagyon szépek, ha van egy egyszerű adatkészlete, amely remekül illeszkedik táblázatos formátumba, és egyszerű módot kíván biztosítani a felhasználók számára a rekordok frissítésére. Igen, tudom, hogy az MVC 4-nek van egy igazán pörgős Ajax listatípusa, amelyet használhat, ami remekül működik, de üzletünkben gyakran meg kell indítanunk valamit tegnap, és a jó régimódi hálózatok remekül működnek, és a felhasználók örülnek, hogy képes vidáman lapozgatni a rácson. Számomra ez a legjobb dolog a WebForms-ban számomra; de, amire Ryan rámutatott, a WebForms nagy időzavar lehet, mert mindkét oldalt játszik a kerítés egy remek kód mögött álló fájlból. Rózsa és tövis lehet egyszerre, ha az összes vezérlő típusú dolgot összekeveredik a nézeteivel.

MVC
Akkor használja ezt, ha nagyon szeretné megalapozni a sajátját, és lehetősége van egy alkalmazást a nulláról elindítani. A világosan meghatározott MVC alkalmazás birtoklása egy kicsit több munka az induláshoz, de a karbantarthatóság előnyei meghaladják a kezdeti telepítési költségeket. Ha érdekes Ajax interakciókat szeretne végezni, akkor inkább írja be a modelljét kóddal, például a tiszta URL-ekkel és az útvonalakkal, és tudja irányítani az alkalmazás teljes folyamatát, akkor ez mindenképpen a megfelelő út. elsőre, de úgy gondolom, hogy ez a jobb lehetőség a zöldmezős alkalmazásokhoz.

Összegzésképpen számomra ez rácsokra és! rácsokra vonatkozik. 🙂

Megjegyzések

• +1 a szép képért, amelyen a ” lejátszás mindkét oldalon látható kerítés egy remek kód mögötti fájlból “.
• Ez nagyon hasznos. ‘ Nagyon nehéz rácsalapú alkalmazást csinálok, és ‘ kizártam a silverlight, az xbap lehetőségét, és a show között ez a kettő.

Tapasztalatom:

• CakePHP projekteket írtam egy évig.
• Végzett egy közepes méretű Webforms projektet hat hónap alatt.
• Három évig dolgozott egy Windows Forms projekten.

Miután ezt a tapasztalatot kipróbáltam egy másik alkalmazás megírásával webformák segítségével, és elkeseredtem, miután körülbelül egy napig küzdöttem azzal, hogy a webforms megpróbálja megvédeni a fejlesztőt attól a valóságtól, hogy html-t, javascriptet és css-t használó alkalmazást fejlesztenek.

Ezután kipróbáltam az MVC-t, és közvetlenebb irányítással rendelkeztem a kimenet felett (és némi tapasztalattal rendelkeztem a CakePHP MVC-paradigmájával kapcsolatban) kb. egy nap alatt képes voltam úgy elkészíteni az egyszerű alkalmazást, ahogyan szerettem volna.

Az olyan hatékony felhasználói felület-keretrendszerek, mint a jQuery, elérhetősége nagyon el gyengíti a kimenet közvetlen irányításának feladását a gyakran terjedelmes, előre elkészített felhasználói felület összetevőinek használata mellett.

Megjegyzések

• @JimG – Uhh , bármi, ami azt jelenti, hogy egy személy érdekes asszociációk nélkül vezet be rekordokat az adatbázisba, és ha ez a személy vagy valaki más elolvassa / kinyomtatja őket, az alapvetően egy MVC keretrendszer segítségével állványozható. Meg kell adnom, hogy ez nem a ‘ t a legtöbb alkalmazás, de ‘ sokkal többet jelent, mint amit a Forms-szal megtehet. Azt hiszem, a -1 bizonyítja az én álláspontomat.
• Ez ‘ a nap 1/4-e.
• De ha a követelmények összege ” Szükségem van egy alkalmazásra, amely két szereppel rendelkezik, az egyik az információk rögzítéséhez, a másik a megtekintéshez, és én nem igazán szeretem ‘ érdekel, hogy néz ki. ” Akkor, igen, ez ‘ egész kivitelezhető.
• sajnálom, de Webforms alkalmazás fejlesztése az adatok beviteléhez és az adatok megtekintéséhez olyan egyszerű, hogy néhány órán belül elvégezhető. Az MVC alkalmazás, a Vezérlők, a Nézetek és a Műveletek struktúrájának létrehozása ugyanannyi időt igényel, de nem jut el egy kész termékhez.
• @Dementic Egy egyszerű MVC alkalmazáshoz általában modelleket épít, majd állványokat állít fel a vezérlők és nézetek között, és / vagy állványos vezérlőket / nézeteket generál. Semmi sem igazán időigényes.

Inkább a webformákat szeretem, mert a hátterem a Windows fejlesztés.

A fejlesztés sebessége kulcsfontosságú kérdés, és könnyen átadhatok egy problémát valakinek az indiában, hogy egyik napról a másikra megoldhassam űrlapokkal, és ha van egy problémám egy oldalon, akkor egy nagyon jó könyv az asp.net-ről a sebesség praktikus (Rick Kiessig az ember).

A webformák az ex windows számára szólnak, az mvc a webes emberek számára

de a modern világban, ahol Rick egy fantasztikus könyvet írt , a kiszolgálók sebességének növekedése naponta és olcsó kódolók Indiában. Nos, a webformáknak megvan az élük

Az én 2 centem hogy az ASP.NET MVC-t mindig új projektekhez használja, ha erre lehetősége van. Véleményem szerint a webes űrlapok nem alkalmasak webalkalmazások fejlesztésére, időszak.

Szerintem az alapvető REST elvonása rossz, a teljes postback modell rossz, a html / css megbízhatósága a grafikus felület szerkesztőjében rossz, a varázslóknak és a grafikus felhasználói felületeknek a hangsúly a dolgok felállítására rossz, az URL-ek rosszak.

Megjegyzések

• meg tudnád magyarázni részletesebben, miért gondolod ezt?
• szerintem visszatért az alapvető REST elvonatkoztatása, visszatért a teljes postback modell, rossz a html / css kézbesítésének módja a GUI szerkesztőre támaszkodva , a dolgok beállítására rossz a hangsúly, mint a varázslók és a GUI-k, rosszak az URL-ek stb. és így tovább

Még nem láttam ezt a megfontolást a szál meglévő 15 válasza között, de szerintem “Érdemes megfontolni.

Tapasztalatom szerint a Web Forms jobban hasonlít a Win Forms és a WPF fájlokra, mint az MVC. Ezt figyelembe véve azt gondolom, hogy fontolóra lehet venni a Web űrlapok választását, amikor a csapatnak van legnagyobb tapasztalata az ilyen típusú technológiában, vagy amikor a Web űrlap projekt egy interfészt ad át ugyanazon az adathalmazon, mint egy meglévő (vagy egyidejűleg fejlesztett) Win űrlap, WPF projekt. Ez lehetővé teszi a fejlesztők számára, hogy könnyebben lépjenek át a projektek között, mivel az alkalmazás logikája meglehetősen hasonló lehet a kettő között.

Amint más válaszok rámutattak, az MVC keretrendszer fejlesztése inkább hasonlít a Ruby webfejlesztésére, PHP, Python stb., Mint a Microsoft társai; így természetesen az MVC kiválasztását befolyásolhatják a csapatok tapasztalatai az adott területeken, valamint a többi válaszban beküldött tényezők.

Megjegyzések

• + 1 Természetesen ésszerű érv a Webforms mellett. Attól tartok, hogy a csapatok ezt a gondolkodásmódot követik, hogy ne tanuljanak új dolgokat. Az MVC sok olyan mintával van tele, amelyek ismeretlenek lehetnek egy csapat számára. Az ilyen típusú minták elsajátítása és megvalósítása a SOLID elvek jobb betartásához vezet, ami jobb általános karbantarthatóságot eredményez. Ezek a bevált technikák jelentik az újrafelhasználhatóság valódi kulcsát is.

A nem indulás oka néhány évvel ezelőtt az MVC-nek ez egy éretlen technológia volt a Microsoft részéről. Az elmúlt néhány évben kiforrottabb verzión dolgozunk (4), és úgy tűnik, hogy az MS kidolgozta, hová tartanak ezzel.Azonban még mindig vonakodunk a nagyobb LOB-alkalmazások MVC-vel történő fejlesztésétől, mivel a 4-es verzióban használni kívánt funkciókhoz Windows 2012-kiszolgálóra van szükség (az IIS8-on keresztüli webaljzatokra). Úgy gondolom, hogy még 1 év múlva jobban elfogadjuk az MVC-t, mivel remélhetőleg több harmadik fél általi vezérlés lesz elérhető, a technológia rendeződött, és megvan az infrastruktúra a támogatásához.

Megjegyzések

• Szívesen felsorolná ezeknek a szolgáltatásoknak a felsorolását, amelyekhez Ön szerint Windows Server 2012 szükséges?

Ez a döntés az Ön preferenciáitól, igényeitől vagy akár ismereteitől és tapasztalatától függ.

Az MVC megtanulásának ideje vagy az idő a szállításhoz. Mindezek fontosak, ha egyik vagy másik szemrehányást választjuk.

Nem az, hogy egyik jobb a másiknál, egyszerűen mind a szemrehányásnak, mind pedig a keretrendszernek vannak előnyei és hátrányai. Azt javaslom, próbálja ki saját tapasztalatait, de el kell mondanom, hogy az MVC programja tiszta, szórakoztató, rugalmas, bővíthető, biztonságos és strukturált módszer.

Üdvözlettel,

Az egyetlen ok, amiért a WebFormust választanám az MVC helyett, az az, hogy sokkal több harmadik fél felhasználói felület vezérlője van a WebFormokhoz, mint az MVC. Az MVC-t választom, mert túl sokat dolgoztam a WebFormokkal és valami újat akarok használni, de még mindig az MS shop-tól 🙂

Alapvetően semmi nem akadályozza meg a WebStorm nézetének kikapcsolásában és a ViewModels használatában és if / for ciklusok a modellkötés és a szerveroldali vezérlések helyett.

Ez a WebForms vagy MVC kód:

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

A WebFormsban egyetlen korlátozást találtam, hogy ha a Dependency Injection / Inversion of Vezérlés, nem lehet konstruktor injekció, mivel a WebForms oldalaknak paraméter nélküli konstruktorral kell rendelkezniük, ezért tulajdonságinjekciót kell használnia. Tényleg olyan nagy dolog ez?

Az ASP.NET MVC valóban válasz a Ruby-ra, és az új, divatos és (IMO) jobb módja annak, hogy a böngészőt (klienst) a lehető legnagyobb mértékben leválasszák a szerverről.

ASP.NET webformák nagyjából mindenre. Lényegében a nézete és a vezérlője ugyanaz, ami sok energiát és többnyire sok rendetlenséget jelent.

ASP.NET MVC elválasztja a nézetet és a vezérlőt azáltal, hogy leválasztja a egy .aspx fájl és az .aspx.cs fájl, amely webformákban kíséri őket.

Lényegében az a különbség, hogy sokkal többet (általában az egészet) kell megjeleníteni az adatokból a nézetfájlba, és az üzleti logikát és a többit hagyja a vezérlőben, mindkettőjüket tisztábban tartva, de egyúttal kevesebb hozzáféréssel is rendelkeznek egymáshoz, mint a webes űrlapok lehetővé teszik.

Megjegyzések

• Tehát MIKOR kell a webformákat előnyben részesíteni az MVC-vel szemben? Ez nem válaszolja meg az eredeti poszterkérdést.
• @WeekendWarrior – Ha több szerveroldali hozzáférést szeretne az ügyfélhez, akkor válasszon weblapokat. Ha a kliens / szerver további leválasztását szeretné a kódban, válassza az MVC lehetőséget. A nap végén mindkettő pontosan ugyanazt csinálja. Az átirányított szűrők ugyanazt csinálják, mint az MVC URL-ek, és a webforms kódot áthelyezheti egy külön középső szintre, hogy jobban szétválassza. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Ami a harmadik pontot illeti, ez az üzleti logika az .aspx.cs fájlba kerül – szerintem ez a fejlesztők hibája. ‘ nincs / állítólag / ott. A Webforms-ban az .aspx a ” nézet “, az .aspx.cs a / div> vezérlő ” egyenértékű, csak a felhasználói felületre közvetlenül kapcsolódó kód feldolgozására szolgál, üzleti réteg vagy durva szemcsés üzleti homlokzati réteg lekérdezésével. Az a tény, hogy az emberek üzleti logikát helyeznek az .aspx.cs fájlba, csak rossz programozás. Helyezhetik az üzleti logikát az MVC nézetébe is! Az MVC nem ‘ nem kényszeríti el ezeket a dolgokat.
• Lényegében igaza van, mint az itt közzétett más válaszoknak. Az ASP.net a Microsoft által létrehozott moduláris webes technológiai család alapgondolata. Az ASP.net MVC modul lehet egy ideiglenes hype, de az biztos, hogy nem utolsó, minden az ASP.net-nél kezdődik, tehát mikor érdemes választani az ASP.net-et, ha nem gondolja, hogy az MVC nem a ti dolgotok, talán inkább a valami különben OWIN vagy …, valami fejlettebb, vagy saját keretet készített a feladatokhoz. Lehet, hogy nem is lesz szüksége ASP.MVC-re, és hagyja ki, és menjen Owinhoz vagy Katanához, de amíg ott nem használja az asp-t.net

Véleményem szerint eléggé kapcsolódnak egymáshoz, és nagyjából ugyanazokkal a képességekkel rendelkeznek, mint amilyennek lennie kellene a preferenciákig.

Egy nagyszerű WebForms fejlesztő ugyanolyan hatékony terméket képes előállítani, mint egy nagyszerű MVC fejlesztő. De a nagy WebForms fejlesztő, aki megpróbálja rávenni magát az MVC elfogadására, rövid lesz. Ugyanez vonatkozik egy nagyszerű MVC-fejlesztőre, aki lövést ad a WebForms-ból.

Nem teljesen különálló entitások, és mindaddig, amíg a Microsoft továbbra is támogatja mindkettőt, úgy gondolom, hogy továbbra is kivételes fejlesztők vegyes csoportját fogja látni mindegyikhez.

Ez a személyes választásról szól, feltéve, hogy mindannyian jártasak vagyunk az alkalmazott technológiában. Sok éve használom a WebForms tervezési megközelítést, és el kell mondanom, hogy az egyetlen hátrány az, hogy leegyszerűsített megközelítése miatt sokan nem szánják idejüket hatalmas képességeinek feltárására.

Nemrég az MVC-t használtam egy projekt befejezéséhez, és bár nagyon szeretem az alkalmazásfejlesztés tervezési megközelítését (amely nagyobb ellenőrzést biztosít, tiszta URL-eket, SOC-t stb. ad), valójában nem sok nyújt , hogy a WebForms nem képes. Valójában a jQuery megjelenése és működése a WebFormesszel (valamint az MVC-vel) kevésbé tette ezeket az érveket. És amikor az emberek az aggodalmak elkülönítéséről beszélnek, mint az MVC előnye az MVP-vel szemben, megkérdezem tőlük, mennyit tudnak az objektumorientált programozásról és arról, hogy mennyire használják az absztrakció és a polimorfizmus elvét.

Jelenleg mindkét technológiát jól érzem, és a helyzet alapján válogatok. Őszintén szólva ez a helyzet neked, de az az igazság továbbra is fennáll, hogy nem mindenki veszi el az idejét, hogy alaposan megismerje, mire képes egy adott technológia.

Megjegyzések

• a webformák hatalmas képességei. A legtöbb ember látja a webformák edző kerekeit, és összehasonlítja ezt az MVC-vel.
• Kevés értelme van absztrakció megtanulásának a HTML és a Javascript tetején ebben a korban (még 2013). Ez ‘ nem tesz jót a jövőbeni lehetőségeidnek. HTML és Javas A szkript nagyon jó, ahogy van. Harcolni vesztes csata.

Programozási problémával szembesülve gyakran az internetre nézek válaszokra. A Webforms rengeteg információval / komponenssel rendelkezik, amivel bármit megtesznek. Az MVC-ben a kevesebb online forrás és a valaminek a működéséhez szükséges absztrakciós rétegek korlátot szabtak azoknak a dolgoknak, amelyeket egyszer megtehettem. Az MVC teljes mértékben megöli a termelékenységemet fejlesztőként, míg a Webforms-szal nem. Tehát egyelőre ragaszkodom a webformákhoz, amíg az MVC nem érlelődik elég ahhoz, hogy helyettesítse.

Nos, a WebFormaknak több tanulási forrása áll rendelkezésre (pusztán annak a ténynek köszönhető, hogy régebbi), és így azok az új programozók, akik “nem” vannak a tudásban, nagyobb valószínűséggel találnak információk erről a régebbi technológiáról, szemben az olyan újabb dolgokkal, mint az MVC.

Az idősebb / tapasztalt programozók idősebbek, és jártasabbak a régebbi technológiában, mivel hosszabb ideig programoztak benne, mint amennyit

Hacsak nem költi el a pénzt és erőfeszítést, hogy a srácok ugyanolyan jártasak legyenek az MVC-ben, mint ők a WebForms alkalmazásokban, akkor kétségtelenül megpróbálja visszatartani az új verzióra való frissítést. a lehető leghosszabb ideig.

Tehát számos logisztikai problémát vet fel: Az MVC előnyei felülmúlják-e a költségeket a gyengébb minőség és bevetési idő? Ha van egy olyan webhelyem, amelyet teljes egészében a WebForms-ba írtam, érdemes lenne-e fáradságot és pénzt fordítani az MVC integrálására?

Amint azt egy korábbi hozzászóló elmondta, az MVC azt is megakadályozza, hogy azonos szintű felületet érj el a a vezérlő, ahogyan azt a WebForms segítségével megtehetné. Noha a dolgok “Tartsam a felhasználót a dolgok feltöltésétől / tanulásig” oldalához értek, mégis indokolatlanul gondot okozhat a csapatoknak egy olyan program telepítése / végrehajtása, amely fanatikusan ragaszkodik ehhez a paradigmához mindenhez, amit írnak.

Úgy gondolom, hogy a két technológia közötti szakadék nem olyan széles, mint korábban.

• A webes űrlapok használhatják az MVC által használt útválasztó motort (vagy valami nagyon hasonlót).
• A szkriptkezelő kombinálhatja a szkripteket, betölthet egy CDN-ről, és még késleltetheti is a szkriptek betöltését.

A kérdés közvetlen megválaszolásához azt gondolom, hogy ez preferenciának számít. és / vagy mi a projekt. Mindkettő jelentősen eltérő megközelítést alkalmaz a fejlődésben. Személy szerint azon dolgoztam, hogy az MVC felé haladjak, de továbbra is szívesen dolgozom a Webforms-szal. Úgy gondolom, hogy az MVC vagy a Webforms használatára a válasz az, hogy Ön dönthessen mindkét technológia tapasztalatán keresztül.

Megjegyzések

• A weblapok és az MVC alapértelmezés szerint gyökeresen eltérő webfejlesztési hozzáállást javasolnak, ez fontos , kevés fejlesztő tér el ” az alapértelmezett “. Mindkettőjük felhasználható ugyanarra a dologra.