Kdy upřednostňovat webové formuláře ASP.NET před MVC

Webforms vs. MVC se právě teď jeví jako aktuální téma. Každý, koho znám, označuje MVC za další skvělou věc. Z mých drobných zmatků v něm to vypadá dobře, ale ne, nemyslím si, že to bude konec webových formulářů.

Moje úvahy a úvahy o tom, proč by se webové formuláře vybíraly přes MVC, mají spíše co do činění s obchodní perspektivou než s tím, co je lepší než druhé.

Čas / peníze jsou největší důvody, proč by se webové formuláře vybíraly nad MVC.

Pokud většina z vašich tým zná webové formuláře a nemáte čas je na MVC zrychlit, kód, který bude vytvořen, nemusí být kvalitní. Naučit se základy MVC, pak skočit a udělat tu složitou stránku, kterou musíte udělat, jsou velmi odlišné věci. Křivka učení je vysoká, takže to musíte zohlednit ve svém rozpočtu.

Pokud máte velký web napsaný celý ve webových formulářích, můžete mít větší sklon vytvářet jakékoli nové stránky ve webových formulářích, abyste tak neučinili. “ Na svém webu nemáte dva velmi odlišné typy stránek.

Neříkám, že to je přístup typu „všechno nebo nic“, ale váš kód bude těžší udržovat, pokud dojde k rozdělení obou. , zvláště pokud ne všichni v týmu znají MVC.

Moje společnost nedávno provedla tři testovací stránky s MVC. Posadili jsme se a navrhli je. Jeden problém, se kterým jsme se setkali, je, že většina našich obrazovek má funkce Zobrazit a upravit na stejné stránce. Nakonec jsme na stránce potřebovali více než jeden formulář. Žádná velká věc, kromě toho bychom nepoužili naši hlavní stránku. Museli jsme to předělat, aby stránky webového formuláře i stránky MVC mohly používat stejnou předlohu pro společný vzhled a chování. Nyní máme další vrstvu vnoření.

Potřebovali jsme pro tyto stránky vytvořit zcela novou strukturu složek, aby postupovala podle správného oddělení MVC.

Cítil jsem, že na 3 stránky je příliš mnoho souborů, ale to je moje osobní názor.

Podle mého názoru byste si vybrali webové formuláře oproti MVC, pokud nemáte čas / peníze investovat do aktualizace svého webu tak, aby používal MVC. Pokud k tomu použijete poloviční přístup, nebude to o nic lepší než webové formuláře, které nyní máte. Horší je, že byste dokonce mohli tuto technologii nastavit na selhání ve vaší společnosti, pokud by se to pokazilo, protože vyšší management by to mohl vidět jako něco horšího, než co vědí.

Komentáře

• To je dobrá odpověď. Dal jsem vám +1, protože si ceníte vašich osobních zkušeností. Toto je však selhání kvůli nedostatku zkušeností / dovedností vývojářů, kterým jsem se chtěl vyhnout . Nejsem přesvědčen, že by se Microsoft rozhodl neoznačit zastaralou technologii jednoduše kvůli obavám z křivky učení pro MVC. Může tomu tak být, ale ještě ‚ ještě ne přesvědčen.
• @ P.Brian.Mackey – Neřekl jsem ‚, že vývoj forem je rychlejší než MVC. Požádali jste, aby tento argument z toho nebyl. Argumentovat čas a peníze na zaškolení zaměstnanců je jiný argument. Společnost MS ‚ neoznačuje webové formuláře za zastaralé z jednoho velkého důvodu: Podnikoví klienti strávili roky vývojem webových klientů ve webových formulářích a vyhráli ‚ nevypadá laskavě, že je třeba investovat čas a peníze na aktualizaci.
• @Raynos – Pokud všichni členové týmu ovládali MVC a vaše společnost zahajovala nový projekt, jediným důvodem, proč jsem viděl, že si někdo vybírá webové formuláře, je osobní volba.
• Znám obě technologie důvěrně. Všechny mé webové projekty se dělají s mvc a pracuji ve společnosti, kde mám volnou ruku, abych udělal cokoli, co je nejlepší. Vždy jsem si vybral MVC.
• Začal jsem s Webforms a jakmile jsem objevil MVC, přešel jsem na to. Nevím ‚ nevím, jak by kdokoli mohl bránit webové formuláře. Životní cyklus stránky a jeden formulář pro celou stránku? Děláš si ze mě srandu? Yahoo sitebuilder pro ni byl pravděpodobně zamýšleným zákazníkem, ale ani ony ‚ nechtěly toto haraburdí.

Vyvíjel jsem aplikace ASP .Net WebForms po dobu 3 let a po jednom dni výuky MVC jsem byl prodán. MVC je téměř VŽDY lepším řešením. Proč?

• Životní cyklus stránky je jednodušší a efektivnější
• Kromě ovládacích prvků html neexistuje nic jako ovládací prvky. Nemusíte ladit svůj výstup, abyste zjistili, co ASP .Net generuje.
• ViewModels vám dávají nesmírnou moc a vyhýbají se nutnosti manuálního ovládání vazby a eliminuje mnoho chyb souvisejících s vazbou. li>
• Na stránce můžete mít více formulářů. Toto bylo vážné omezení WebForms.
• Web je bez státní příslušnosti a MVC lépe odpovídá architektuře webu. Webforms zavádí stav a chyby zavedením ViewState to máte. ViewState je automatický a pracuje na pozadí, takže se vždy nechová tak, jak chcete.
• Webové aplikace dnes musí pracovat s ajaxem. Už není přijatelné mít načtení celé stránky. Díky MVC je Ajax díky JQuery mnohem lepší, jednodušší a efektivnější.
• Protože na stránce můžete mít více formulářů a protože architektura je na základě volání na adresy URL můžete pomocí JQuery dělat funky věci, jako je ajax, načíst jiný formulář, například upravit formulář na svou aktuální stránku. Jakmile si uvědomíte, co vám to umožňuje, můžete snadno dělat úžasné věci.
• ASP .Net WebForms není jen abstrakce nad html, je také extrémně složitá. Někdy byste dostali divnou chybu a bojovali byste s ní mnohem déle, než je třeba. V mnoha případech jste vlastně mohli vidět, co dělá špatně ale nemůžete s tím nic dělat. Nakonec budete dělat divná řešení.
• WebForms nedělá pro designéry dobrou technologii. Návrháři často rádi pracují přímo s html. V MVC je to pohled, v WebForms je to půl dne práce.
• Jelikož se webová platforma rychle vyvíjí, WebForms nebude držet krok. vědom nových značek nebo funkcí HTML5, bude stále vykreslovat stejné věci, pokud nedostanete (často) drahé ovládací prvky třetích stran nebo počkáte, než Microsoft vydá aktualizaci.
• Ovládací prvky ve WebForms vás omezují mnoha způsoby. V MVC stačí popadnout knihovnu JQuery a integrovat ji do svých šablon.

Vím, že některé z výše uvedených problémů byly do jisté míry řešeny s vývojem WebForms, ale to byla moje původní zkušenost. Celkově bych shledal, že je extrémně těžké najít obchodní případ pro WebForms, pokud jej již projekt nepoužívá.

Komentáře

• +1 pro poukazování na více forem. Navíc skutečnost, že webové formuláře HTML generují, většinou není příliš přátelská k SEO (jako v: velké části viewstate v horní části stránky)
• S touto odpovědí musím 100% souhlasit. Na konci dne WebForms dělá věci na straně klienta (html / prohlížeč) mnohem těžší. Doslova musíte bojovat s rámcem, abyste něco udělali. Stránka aspx končí díky serverovým ovládacím prvkům mnohem více kódu než obvykle stránka cshtml. @ šljaker Pokud začnete vypínat ViewState a vyhýbáte se ovládacím prvkům serveru, ‚ jste v tomto okamžiku opustili většinu WebForms. ‚ Nevidím tento argument jako zvlášť přesvědčivý.
• Ve WebForms můžete mít jednoduché html ovládací prvky, nikdo vás nenutí používat ovládací prvky serveru. Můžete mít Webform bez státní příslušnosti, nikdo vás nenutí používat ViewState. Ve Webforms můžete použít plný ajax a jQuery, nikdo vás v používání jQuery neomezuje. Můžete implementovat směrování URL, nikdo vás nenutí používat základní URL statického souboru. Ruční kreslení stránky pomocí CSS spotřebuje čas tolik, kolik MVC potřebuje. Stránku HTML můžete navrhnout přímo ve Webformu.
• @mjb: Pokud ‚ nepoužíváte ovládací prvky serveru, ViewState atd., Proč vůbec používat WebForms, když MVC je blíže tomu, co ‚ děláte? ‚ Je to jako řídit traktor do práce, ale nedělat offroad nebo používat lopatu / plečku nebo stabilizační tyče. V tom okamžiku proč nepoužívat pouze auto?
• @Tjaart Není zcela v pořádku, že na stránce ASPNET nemůžete mít více formulářů.Na stránce ASPNET můžete mít tolik formulářů, kolik chcete, ale můžete mít pouze jeden serverový formulář – formulář s runat = “ serverem “ atribut.

Poslal jsem e-mailem Scott Guthrie , odborník na MVC ve společnosti Microsoft. A pravděpodobně nejkvalifikovanější muž, který na tuto otázku odpoví. Byl natolik laskavý, že odpověděl:

„Různí zákazníci hledají různé programovací přístupy. WebForms hodně miluje a myslí si, že je skvělý. Ostatní milují MVC myslím, že je to skvělé. Proto investujeme do obou. „

Takže pro mě to říká, že to není technický problém. Je to spíše „měkký problém“, pokud chcete. Jeden s osobními preferencemi. To je v souladu s tím, co jste řekli několik z vás.

Děkujeme za všechny odpovědi.

Komentáře

• Vynalezl Scott Guthrie rámec MVC pro ASP.NET během letu zpět z Londýna do Seattlu v letech 2006/7. Když o tom přemýšlím, do značné míry vynalezl i .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Říkat mu “ expert “ je nesmírné podcenění 😉
• To ‚ je pěkná politická odpověď od Scotta Guthrieho. Pokud by sám investoval vlastní webovou aplikaci, ‚ uvidíte projekt MVC a pro cokoli, co by nebylo možné ‚ provést v MVC, Silverlight by byl záložní. Nepoužívejte ‚ to jako komentář negativní vůči WebForms, myslím, že WebForms jsou skvělé pro interní aplikace s menším rozsahem, které mohou těžit z komponent třetích stran, jako jsou ty, které vytvořil Telerik. Jsem ‚ jsem rád, že Microsoft jde vpřed s oběma technologiemi.
• “ Scott Guthrie vynalezl rámec MVC pro ASP .NET během letu “ Myslím, že to MVC opravdu bagatelizuje. ‚ Nevím Scotta Guthrieho, ale ‚ jsem ochoten se vsadit, že obviňoval, jak může být MVC implementováno v ASP.NET nějakou dobu a tento dlouhý let využil k implementaci prototypu holých kostí jako důkaz koncepce.
• “ Proto investujeme do obou. “ A když zjistíme, že webové formuláře začínají upadat, nemilosrdně je upustíme, protože investice do konečně mrtvého produktu není v našem nejlepším obchodním zájmu.
• Dokud již se na školách neučí, po mnoho let bude vždy použitelný v obchodním světě. Vysoké školy a střední školy nadále nabízejí úvodní a pokročilé kurzy vb.net. NENÍ to nikam !!!

Toto je zatuchlá otázka se spoustou odpovědí, ale žádná měl odpověď, kterou bych očekával, že bude uveden.

Krátká odpověď je:

• Použijte ASP.NET MVC, pokud chcete správně vytvořit webovou aplikaci s moderním programováním konvence a průmyslově přijaté vzory pro platformu ASP.NET. Na spodní straně se od vás očekává, že budete vědět, jak fungují zdroje HTML a zdroje na straně klienta (Javascript, CSS), stejně jako se rozběhnete na programovací myšlení MVC, které má strmou křivku učení, ale jakmile uchopí, dosáhne náhlého konce.
• Webové formuláře ASP.NET použijte, pokud používáte nebo chcete použít GUI -centrické, RAD (Rapid Application Development) , drag-and-drop přístup k prototypování něčeho velmi rychlého, tj. chování tlačítka / datové mřížky připojené do 15 minut, a toto řešení není zamýšleno jako něco podporované vývojáři. Nebo použijte webové formuláře ASP.NET, pokud máte pozadí ve GUI nebo vývoji Windows Forms a chcete přenést své znalost webu.

Abyste se však na to mohli správně podívat, musíte porozumět historii každého z nich.

Webové formuláře ASP.NET byly odpovědí společnosti Microsoft na ti, kteří stavěli dynamické webové aplikace pomocí Visual Basic 6 Ac ovládací prvky tiveX, VB6 DLL na serveru a ASP Classic. V té době byl vývoj webu pomocí těchto nástrojů společnosti Microsoft skutečným nepořádkem. Spolu s celým .NET Framework, který byl výstupem Microsoftu, který se v podstatě vrátil k rýsovacímu prknu, jak provádět produktivní obchodní programování na zásobníku Windows, byly webové formuláře ASP.NET ve své době úžasné a krásné.

Celý přístup spočíval v tom, aby vývojáři dostali to nejlepší z obou světů něčeho velmi podobného vývoji aplikací pro Windows, ale s výkonem internetových služeb.Myšlenka byla, že stejně jako u formuláře „VB6 / WinForms„ Form “(okno) je i webová stránka formou (stejně jako okno, viz) a v tomto formuláři můžete přetahovat štítky, textová pole, datové mřížky, tlačítka a další věci, na které byli vývojáři grafického uživatelského rozhraní VB / WinForms zvyklí.

Chcete-li, aby tlačítko něco udělalo, po jeho přetažení stačí na něj dvakrát kliknout v návrháři a spustit boom, jste v editoru kódu a řeknete formuláři, co má dělat, když toto „kliknutí“ „událost se stane. Přesně tak vytvořili vývojáři Windows GUI software pomocí GUI nástrojů VB6 a konkurenčních nástrojů, kromě toho, že se kód spouští na serveru! Páni!

Byla to technologie z roku 2002. Úžasná a krásná ve své době jako odpověď na internet – povoleno GUI řešení pro RAD vývoj , přineslo to pocit síly do chaotického světa vývojářů softwaru, kteří měli obchodní cíle, které potřebovali k dosažení.

Tento programovací model bohužel tolik zdůrazňuje metaforu programování Windows GUI, že s sebou nese břemeno jeho nezbytných implementačních detailů , všechna zatěžující zavazadla jn Je nezbytné přizpůsobit životní cykly událostí a zastrčit ošklivé podrobnosti jednoduchého kódu HTML a skriptu, které by tyto komponenty a ovládací prvky typu drag-and-drop vyprodukovaly. A na konci dne museli vývojáři podporující skutečné aplikace nevyhnutelně kopat do těchto komponent nebo psát své vlastní, a následně by bojovali s touto infrastrukturou, bitvami, které by po sobě zanechávaly hromady na hromadách cruftu, vytažených vlasů a slzy.

Zálohujte. Myjte si ruce. Pojďme se znovu podívat na obchodní problém. Jaké jsou naše obchodní cíle?

Musíme vytvářet a spravovat webové aplikace . Naše omezení spočívají v tom, že máme World Wide Web, který sedí na HTTP, HTML, Javascript a CSS a na serveru máme obchodní pravidla, databáze a malou hrst skvělých programovacích jazyků (např. C #). Opravdu potřebujeme tuto metaforu Windows GUI, abychom mohli řídit naši vývojovou metodiku? Proč se nemůžeme soustředit jen na problémy s aplikací a skoncovat s metaforami GUI?

Toto je místo, kde přichází ASP.NET MVC. Začalo to vzpourou vývojářů, kteří si říkali „Alt.Net“, kteří se chtěli vrátit ke správným a čistým principům vývoje softwaru. Už žádné přemýšlení a soustředění, jen se zaměřte na obchodní cíle a osvědčené postupy softwaru.

V tomto případě to skutečně znamená:

1. Oddělení obav . Například datová komponenta nemusí vědět, jak se budou její data vykreslovat, ani by nemělo být zobrazení značek zatíženo podrobnostmi o konfiguraci databázového připojení, a tímto způsobem se může vývojář při úpravách a úpravách soustředit na svou oblast zájmu. testovací kód.
2. Expozice a plná podpora pro vystavení hlouposti HTML a souvisejících zdrojů . Ve webových formulářích je HTML zastrčeno, vývojáře to odrazuje od toho, aby s tím fušovali. V ASP.NET MVC jsou vývojáři spíše povzbuzováni ke správě těchto podrobností; ve skutečnosti je to nutnost. Výhodou je, že se vývojář může znovu naučit ocenit čistou sémantiku HTML, CSS a skriptu a pracovat s spíše než proti ní.
3. Testovatelnost obchodních objektů . Řadiče a modely se mnohem lépe hodí pro testování programových jednotek, takže implementace lze ověřit tak, aby splňovaly obchodní cíle, a lze ověřit změny, které se nezlomí. S webovými formuláři bylo obtížné testovat, protože komponenty nebyly navrženy tak, aby byly testovány jednotlivě, a celý vývojový výstup se točil kolem formulářů stránek a jejich životních cyklů událostí s hluboce propojenou obchodní logikou a logikou prezentace.

Všimněte si, že HTML je již značkovací jazyk velmi vysoké úrovně, stejně jako Javascript programovací jazyk vysoké úrovně. Celý příběh by se lišil, kdybychom měli co do činění s jazykem Assembly a C.

Při rozšíření na # 2 je dalším cílem ASP.NET MVC umožnit vývojářům uspořádat front-end podrobnosti „pohledová“ část jejich řešení a využijte výhod bohatého základu, který zbytek průmyslu postavil na front-end klientské platformě.

Zjistíte, že se vývojáři ASP.NET MVC cítí jako doma, když využívají bohaté knihovny Javascript a techniky šablon na straně klienta bez boje s architekturou na straně serveru. Toto původně nebyl případ ASP.NET Web Forms, protože Web Forms vůbec nepřeje, abyste se dívali na HTML nebo skript, kromě případů, kdy opravdu musíte , v takovém případě si dejte pozor, není to pro slabé lidi .

Komentáře

• To je dobrá odpověď, ale # 1 a # 2 jsou špatné (WF nevyžaduje, aby komponenta věděla, kde jsou její data pochází z, je to volba a do svých souborů ASPX jste vždy přidali HTML, aby podporovaly tagy asp, které vykreslujete. Nikdy jste nemuseli kopat a bojovat s ovládacími prvky, pokud jste se nepokoušeli získat přístup k funkci ASP, která není určena pro vývojáře interakce. Velkými body jsou testovatelnost a designový vzor.)

Jsem úplná a úplná konverze na ASP.NET MVC a neohlíželi se zpět, to znamená, že stále musím udržovat několik velmi velkých aplikací WebForms. Zde je můj pohled na to:

WebForms
Použijte je, když máte vážný těžký život co do činění s mřížkami. Ovládací prvky mřížky jsou opravdu velmi pěkné, pokud máte jednoduchou datovou sadu, která se vejde pěkně do tabulkového formátu a chcete uživatelům poskytnout jednoduchý způsob aktualizace záznamů. Ano, vím, že MVC 4 má opravdu snazzy věc typu Ajax typu seznamu, kterou můžete použít, což funguje skvěle, ale v našem podnikání často potřebujeme něco včera spustit a dobré staromódní mřížky fungují skvěle a uživatelé jsou rádi, že jsou schopný radovat se přes mřížku. Pro mě je to pro WebForms opravdu to nejlepší, ale jak Ryan zdůraznil, WebForms může být velkým časovým nepořádkem, protože hrajete obě strany plotu ze šikovného souboru na pozadí. Může to být jak růže, tak trn současně, aby všechny vaše věci typu řadiče byly smíchány s vašimi pohledy.

MVC
Tuto možnost použijte, pokud opravdu chcete vytvořit vlastní a máte příležitost spustit aplikaci úplně od začátku. Mít jasně definovanou aplikaci MVC je o něco více práce, ale její výhody v udržovatelnosti převažují nad počátečními náklady na nastavení. Pokud chcete dělat zajímavé interakce Ajaxu, raději napište svůj model s kódem, jako jsou čisté adresy URL a trasy, a ovládejte celý tok své aplikace, pak je to určitě způsob, jak jít. Trvá několik zvyknutí zpočátku, ale myslím, že je to lepší volba pro aplikace na zelené louce.

Závěrem tedy pro mě jde o mřížky a! mřížky. 🙂

Komentáře

• +1 pro pěkný obrázek dodaný s “ přehráváním obou stran plot ze šikovného souboru na pozadí „.
• Tento je velmi užitečný. ‚ dělám velmi těžkou mřížkovou aplikaci a já ‚ jsem vyloučil Silverlight, xbap a bylo to na přehlídku mezi tyto dva.

Moje zkušenost:

• Napsal projekty CakePHP po dobu jednoho roku.
• Dokončili jsme středně velký projekt Webforms po dobu šesti měsíců.
• Pracovali jsme na projektu Windows Forms tři roky.

Po tuto zkušenost jsem zkusil napsat jinou aplikaci pomocí webových formulářů a byl jsem frustrovaný, když jsem asi den bojoval s tím, jak se webové formuláře snaží chránit vývojáře před realitou, že vyvíjejí aplikaci, která používá html, javascript a css.

Poté jsem vyzkoušel MVC a s přímější kontrolou nad výstupem (a zkušenostmi s paradigmatem MVC od CakePHP) jsem dokázal tuto jednoduchou aplikaci dokončit přesně tak, jak jsem ji chtěl, asi za 1/2 dne.

Dostupnost výkonných rámců uživatelského rozhraní, jako je jQuery, do značné míry eli minuje přitažlivost vzdání se přímé kontroly nad výstupem ve prospěch použití často objemných předem připravených komponent uživatelského rozhraní.

Komentáře

• @JimG – Uhh , cokoli, co zahrnuje osobu, která zadává záznamy bez zajímavých asociací do databáze, a nechat ji danou osobou nebo někým jiným číst / tisknout v jiném bodě, lze v zásadě vygenerovat pomocí rámce MVC. Je pravda, že to není ‚ většina aplikací, ale ‚ je to sakra mnohem víc, než můžete dělat s Formuláři. Myslím, že vaše -1 dokazuje můj názor.
• To ‚ s 1/4 dne.
• Ale pokud požadavky dosáhnou “ Potřebuji aplikaci se dvěma rolemi, jednou pro zaznamenávání některých informací, druhou pro její prohlížení a druhou ‚ opravdu záleží na tom, jak to vypadá. “ Pak ano, to je ‚ docela možné.
• omlouvám se, ale vývoj aplikace webových formulářů pro zadávání dat a prohlížení dat je tak jednoduchý, že to lze provést za několik hodin. Vytvoření struktury aplikace MVC, Controllers, Views and Actions, by trvalo stejně dlouho, ale nedostane vás k hotovému produktu.
• @Dementic Obvykle se pro jednoduchou aplikaci MVC staví modely, poté se kontrolují a zobrazují lešení a / nebo se generují lešení a kontroléry / zobrazení. Nic tam není časově náročné.

Dávám přednost webovým formulářům, protože mým pozadím je vývoj systému Windows.

Rychlost vývoje je klíčovým problémem a můžu snadno předat problém někomu v Indii, aby to přes noc vyřešil pomocí formulářů, také, pokud mám na stránce problém s rychlostí, opravdu dobrá kniha o asp.net rychlost je praktická (Rick Kiessig je muž).

webové formuláře jsou pro lidi z ex windows mvc jsou pro lidi z webu

ale v moderním světě, kde Rick napsal úžasnou knihu , díky tomu, že se v Indii denně zvyšuje rychlost a levné kodéry, mají webové formuláře výhodu

Moje 2 centy jsou vždy použít ASP.NET MVC pro nové projekty, pokud máte tuto možnost. Podle mého názoru nejsou webové formuláře dobrým způsobem, jak vyvíjet webové aplikace, tečka.

Myslím si, že abstrahování od základního RESTu je špatné, celý model postbacku je špatný, způsob, jakým se html / css spoléhá na spolehlivost v editoru grafického uživatelského rozhraní je špatný, důraz na nastavení věcí, jako jsou čarodějové a grafická rozhraní, je špatný, adresy URL jsou špatné.

Komentáře

• mohl byste podrobněji vysvětlit, proč si to myslíte?
• Myslím, že abstrahování od základního REST je zpět, celý model postback je zpět, způsob, jakým je html / css předáván se spoléháním na editor GUI, je špatný , důraz na nastavení věcí, jako jsou průvodci a GUI, je špatný, adresy URL jsou špatné atd.

Přečetl jsem všechny odpovědi a mám pocit, že moje osobní zkušenost by něco přidala k výše uvedeným odpovědím.

Před 3-4 lety jsem pomocí Webforms vytvořil 2-3 webové projekty. V té době nebylo MVC o tom ani jsem neslyšel. Vývoj byl pro mě přirozeně (vycházel jsem z vývoje formulářů Win bez předchozích zkušeností s vývojem webu) rychlý, protože se nemusím podrobně učit HTML a ovládání webu mi hodně pomohlo (sakra, usnadnilo to život) .

Nyní, po celou tu dobu, jsem donedávna nepracoval s žádným webovým projektem a pouze jsem budoval nějaké aplikace pro Windows pomocí WPF.

Před několika dny jsem měl nápad na web a myšlenka na jeho vývoj: tentokrát v MVC (protože se o něm hovoří všude, kromě toho jsem se musel učit buď, tak jsem si vybral MVC). Projekt je stále ve fázi vývoje, protože se stále učím a stavím společně.

Takže klíčové rozdíly, které najdu, jsou následující: –

• Pro někoho, kdo pochází z vývoje systému Windows, budou webové formuláře vždy výhodné. Asp Křivka učení .net pro vývojáře Windows je trochu strmá.

• Pro někoho, kdo pochází z vývoje webových aplikací v jiné technologii, bude upřednostňován MVC, protože to zesměšňuje Nejnovější ze všech.

• Vývoj je v MVC snazší a čistší, pokud máte dobrou znalost HTML a CSS

• Nasazení je stále problém. Ve webových formulářích stačí kopírovat a vložit. To ale vyžaduje, aby se udělaly určité věci.

Stručně řečeno, oba zde chvíli zůstanou.

Ještě jsem neviděl tuto úvahu předloženou mezi stávajícími 15 odpověďmi na toto vlákno, ale myslím, že „Stojí za zvážení.

Z mé zkušenosti jsou webové formuláře více podobné Win Forms a WPF než MVC. Vzhledem k tomu si myslím, že by bylo možné zvážit výběr webových formulářů, když má tým největší zkušenosti s tímto druhem technologie, nebo když projekt webových formulářů přinese rozhraní na stejnou datovou sadu jako stávající (nebo současně vyvinutý) Win Forms nebo Projekt WPF. To umožňuje vývojářům snáze přecházet mezi projekty, protože aplikační logika může být mezi těmito dvěma docela podobná.

Jak zdůraznily další odpovědi, vývoj v rámci MVC je více podobný vývoji webových aplikací v Ruby, PHP, Python atd. Než jeho protějšky Microsoft; takže výběr MVC může být přirozeně ovlivněn zkušenostmi týmů v těchto oblastech a faktory uvedenými v jiných odpovědích.

Komentáře

• + 1 Určitě rozumný argument pro Webforms. Obávám se, že týmy sledují toto myšlení, aby se vyhnuly novým věcem. MVC je plné mnoha vzorů, které mohou být týmu neznámé. Učení se těmto typům vzorů a jejich implementace vede k lepšímu dodržování zásad SOLID, což znamená lepší celkovou udržovatelnost. Tyto osvědčené techniky jsou také skutečným klíčem k opětovné použitelnosti.

Náš důvod, proč nechodit MVC před několika lety to byla nezralá technologie od Microsoftu. V posledních několika letech nyní pracujeme na vyspělejší verzi (4) a zdá se, že se MS dopracovalo k tomu, kam jdou.Stále se však zdráháme vyvíjet hlavní LOB aplikace pomocí MVC, protože funkce, které chceme použít ve verzi 4, vyžadují server Windows 2012 (re webové zásuvky přes IIS8). Domnívám se, že za 1 rok budeme více akceptovat MVC, doufejme, že bude k dispozici více ovládacích prvků třetích stran, technologie se usadila a my budeme mít infrastrukturu, která ji bude podporovat.

Komentáře

• Nevadilo by vám vypsat některé z těchto funkcí, které podle vás vyžadují Windows Server 2012?

Toto rozhodnutí závisí na vašich preferencích, vašich požadavcích nebo dokonce na vašich znalostech a zkušenostech.

Čas na školení k učení MVC nebo čas na doručení. Na všech těchto věcech záleží na výběru jednoho nebo druhého přístupu.

Není to tak, že jeden je lepší než jiný, prostě oba přístupy nebo rámce mají klady a zápory.

Osobně dávám přednost MVC 3, Doporučuji vám vyzkoušet si vlastní zkušenost, ale musím říci, že program v MVC je čistý, zábavný, flexibilní, rozšiřitelný, bezpečný a strukturovaný.

S pozdravem,

Jediným důvodem, proč bych si vybral WebForms místo MVC, je to, že máte mnohem více ovládacích prvků uživatelského rozhraní třetích stran pro WebForms než MVC. Vybral jsem si MVC, protože jsem příliš pracoval s WebForms a chci pracovat s něčím čerstvým / novým, ale stále z MS shopu 🙂

Nic vám v zásadě nebrání vypnout viewstate ve WebForms a používat ViewModels a smyčky if / for namísto vazby modelu a ovládacích prvků na straně serveru.

Je to WebForms nebo MVC kód:

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

Jediným omezením, které jsem ve WebForms našel, je, že pokud použijete Dependency Injection / Inversion of Ovládací prvek, nemůžete mít vkládání konstruktoru, protože stránky WebForms musí mít konstruktor bez parametrů, takže musíte použít vkládání vlastností. Je to opravdu tak velký problém?

ASP.NET MVC je opravdu odpovědí na Ruby a na nový, moderní a (IMO) lepší způsob co největšího oddělení prohlížeče (klienta) od serveru.

Webové formuláře ASP.NET vám poskytují velkou kontrolu nad klientem ze strany serveru s přímým přístupem do značné míry všechno. V podstatě je váš pohled a ovladač stejné, což vám dává spoustu síly a většinou spoustu nepořádku.

ASP.NET MVC odděluje pohled a řadič odpojením těsného spojení soubor .aspx a soubor .aspx.cs, který je doprovází ve webových formulářích.

Rozdíl v zásadě spočívá v tom, že mnohem více (obvykle vše) zpracování zobrazí data do souboru zobrazení a ponechání obchodní logiky a zbytku v řadiči, což je udržuje čistší podle konvence, ale také s menším vzájemným přístupem, než umožňují webové formuláře.

Komentáře

• Takže KDY by měly být webové formuláře upřednostňovány před MVC? To neodpovídá na otázku původních plakátů.
• @WeekendWarrior – Pokud ano, chcete-li klientovi získat více přístupů na straně serveru, zvolte webové formuláře. Pokud chcete ve svém kódu více oddělení klienta / serveru, zvolte MVC. Na konci dne oba dělají přesně to samé. Filtry přesměrování dělají totéž jako adresy URL MVC a můžete přesunout kód webových formulářů za sebou na samostatnou střední vrstvu, abyste ji více oddělili. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Pokud jde o váš třetí bod, tato obchodní logika končí v souboru .aspx.cs – myslím, že to je chyba vývojářů. ‚ tam není / neměl / být. Ve Webforms je .aspx “ pohled „, .aspx.cs je “ controller “ ekvivalent, určený ke zpracování kódu, který přímo souvisí pouze s uživatelským rozhraním, dotazováním obchodní vrstvy nebo hrubozrnné obchodní fasádní vrstvy. Skutečnost, že lidé vkládají obchodní logiku do souboru .aspx.cs, je jen špatné programování. Mohli by také dát obchodní logiku přímo do pohledu v MVC! MVC si ‚ nevynucuje oddělení těchto věcí.
• V zásadě má větší pravdu než jiné zde zveřejněné odpovědi. ASP.net je základní myšlenkou modulární rodiny webových technologií vytvořené společností Microsoft. Modul ASP.net MVC může být dočasný humbuk, ale určitě to není poslední, všechno začíná ASP.net, takže když si vyberete ASP.net, pokud si nemyslíte, že MVC není vaše věc, možná vaše něco do něčeho jinak OWIN nebo …, něco pokročilejšího, nebo vytvořte si vlastní rámec pro své úkoly. Možná ani nebudete potřebovat ASP.MVC a přeskočit to a jít Owin nebo Katana, ale dokud tam nebudete používat asp.net

Podle mého názoru jsou dostatečně příbuzné a mají zhruba stejné schopnosti, jaké by měly přijít až k preferencím.

Skvělý vývojář WebForms může vyrobit produkt stejně výkonný jako skvělý vývojář MVC. Ale skvělý vývojář WebForms, který se snaží přinutit k přijetí MVC, brzy přijde. Totéž platí pro skvělého vývojáře MVC, který dává WebForms šanci.

Nejsou to úplně samostatné entity a pokud Microsoft bude i nadále podporovat obě, věřím, že budete i nadále vidět smíšenou skupinu výjimečných vývojářů pro každého.

Jedná se o osobní volbu za předpokladu, že jsme všichni zdatní v technologii, kterou používáme. Návrh designu WebForms používám již mnoho let a musím říci, že jedinou nevýhodou je, že díky jeho zjednodušujícímu přístupu si mnoho lidí nedělá čas na odhalení jeho rozsáhlých schopností.

Nedávno jsem k dokončení projektu použil MVC, a přestože se mi docela líbí designový přístup k vývoji aplikací (který vám dává větší kontrolu, čisté adresy URL, SOC atd.), opravdu toho moc neposkytuje , že WebForms nemůže „t. Ve skutečnosti vznik jQuery a jeho práce s WebForms (stejně jako s MVC) učinil z těchto argumentů menší problém. A když lidé mluví o oddělení obav jako o výhodě, kterou má MVC oproti MVP, ptám se jich, kolik vědí o objektově orientovaném programování a o tom, jak moc využívají princip abstrakce a polymorfismu.

V současné době mi obě technologie vyhovuje a vybírám a volím na základě situace. Upřímně řečeno, je to nahoře vám, ale pravdou zůstává, že ne každý si najde čas a důkladně se dozví, čeho je konkrétní technologie schopna.

Komentáře

• Ditto on obrovské možnosti webových formulářů. Většina lidí vidí tréninková kolečka webových formulářů a porovnává je s MVC.
• V dnešní době nemá smysl učit se abstrakci nad HTML a Javascript (dokonce ani v 2013). To ‚ vám nebude prospěšné pro vaše budoucí příležitosti. HTML a Javas cript je v pohodě tak, jak to je. Bojovat s ním je prohraná bitva.

Když čelím problému s programováním, často se dívám na web pro odpovědi. Webforms má spoustu informací / komponent o tom, že dělá téměř cokoli. V MVC kvůli menšímu počtu zdrojů online a vrstvám abstrakcí potřebných k tomu, aby něco fungovalo, dal limit ve věcech, které jsem kdysi mohl udělat. Celkově MVC zabíjí moji produktivitu jako vývojáře, zatímco s Webforms to není. Takže zatím se držím webových formulářů, dokud MVC nevyzrálo natolik, aby jej nahradil.

WebForms mají k dispozici více studijních zdrojů (jednoduše kvůli tomu, že jsou starší), a proto nové programátory, kteří o nich nevědí, pravděpodobně najdou informace týkající se této starší technologie na rozdíl od novějších věcí, jako je MVC.

Starší / zkušení programátoři jsou starší a budou ve starší technologii zdatnější, protože v ní programují déle než oni mít v novější.

Pokud nemůžete utratit peníze a úsilí, abyste získali své chlapce tak zdatné v MVC, jako jsou v aplikacích WebForms, nepochybně se pokusíte odložit upgrade na nový platformu tak dlouho, jak je to možné.

Představuje tedy několik logistických problémů: Vyvažují výhody MVC náklady z hlediska nižší kvality a čas nasazení? Pokud mám web napsaný výhradně ve WebForms, stálo by to za námahu a peníze integrovat do něj MVC?

Jak uvedl předchozí komentátor, MVC vám také brání v dosažení stejné úrovně rozhraní s řadič, jak byste byli schopni s WebForms. I když jsem vše pro stránku „Zabraňte uživateli v tom, aby věci plnil / učil se“, pro týmy může být nepřiměřeně obtížné nasadit / implementovat program, který se fanaticky drží tohoto paradigmatu pro všechno, co píší.

Myslím, že propast mezi těmito dvěma technologiemi už není tak široká, jak bývala.

• Webové formuláře mohou používat směrovací modul, který používá MVC (nebo něco velmi podobného).
• Správce skriptů může kombinovat skripty, načítat z CDN a dokonce zpozdit načítání skriptů.

Chcete-li přímo odpovědět na vaši otázku, myslím, že jde o preference a / nebo jaký je projekt. Oba mají k rozvoji výrazně odlišný přístup. Osobně pracuji na přechodu na MVC, ale práce s Webforms mě stále baví. Myslím, že odpověď na otázku, zda byste měli používat MVC nebo Webforms, je na vás, abyste se rozhodli prožít obě technologie.

Komentáře

• Webové formuláře a MVC ve výchozím nastavení doporučují radikálně odlišný přístup k vývoji webu, to je důležité , několik vývojářů se odchyluje z “ výchozí „. Oba však lze použít k dosažení stejné věci.