Milloin ASP.NET-verkkomuotoja suositaan MVC: n yli

Webforms vs. MVC näyttää olevan kuuma aihe juuri nyt. Kaikki tuntemani mainitsevat MVC: n olevan seuraava hieno asia. Minusta tuntuu siltä, että siinä on pieniä nokkojani, mutta ei, en usko, että se on verkkolomakkeiden loppu.

Perusteluni ja perustelut siitä, miksi verkkolomakkeet valitaan MVC: n sijaan, ovat enemmän tekemistä liiketoiminnan näkökulmasta kuin mikä on parempi kuin toinen.

Aika / raha ovat tärkeimmät syyt siihen, miksi verkkolomakkeet valitaan MVC: n sijaan.

Jos suurin osa tiimi tietää verkkolomakkeet, ja sinulla ei ole aikaa saada ne vauhtiin MVC: ssä, tuotettava koodi ei välttämättä ole laadukas. MVC: n perusteiden oppiminen ja sitten hyppääminen sisään ja tekemällä monimutkainen sivu, joka sinun on tehtävä, ovat hyvin erilaisia asioita. Oppimiskäyrä on korkea, joten se on otettava huomioon budjetissasi.

Jos sinulla on suuri verkkosivusto, joka on kirjoitettu kaikki verkkolomakkeisiin, saatat olla taipuvaisempi tekemään uusia sivuja verkkolomakkeisiin, jotta et ” sivustollasi ei ole kahta hyvin erityyppistä sivua.

En sano sitä ”tässä on kaikki tai ei mitään”, mutta se tekee koodistasi vaikeampi ylläpitää, jos molemmat on jaettu , varsinkin jos kaikki joukkueen jäsenet eivät tunne MVC: tä.

Yritykseni teki äskettäin kolme testisivua MVC: n kanssa. Istuimme alas ja suunnittelemme ne. Yksi ongelma, jonka törmäsimme on se, että suurin osa näytöistämme tarkastelu- ja muokkaustoiminnot samalla sivulla. Tarvitsimme lopulta useampaa kuin yhtä lomaketta sivulla. Ei iso, paitsi silloin emme käytä pääsivumme. Meidän oli uudistettava se, jotta sekä verkkolomakesivut että MVC-sivut voisivat käyttää samaa pääsivua yhteiseen ulkoasuun. Nyt meillä on ylimääräinen pesäkerros.

Meidän oli luotava kokonaan uusi kansiorakenne näille sivuille, jotta se seurasi asianmukaista MVC-erottelua.

Minusta tuntui, että tiedostoja oli liikaa 3 sivua varten, mutta se on minun henkilökohtainen mielipide.

Mielestäni valitset verkkolomakkeet MVC: n sijaan, jos sinulla ei ole aikaa / rahaa sijoittaa sivustosi päivittämiseen MVC: n käyttämistä varten. Jos suhtaudut tähän puoliomaisesti, se ei tule olemaan parempi kuin sinulla nyt olevat verkkolomakkeet. Mikä pahempaa, voit jopa asettaa tämän tekniikan epäonnistumiseen yrityksessäsi, jos se on sekaisin, koska ylimmän johdon mielestä se voi olla jotain huonompaa kuin mitä he tietävät.

Kommentit

• Tämä on hyvä vastaus. Annoin sinulle +1, koska henkilökohtaisia kokemuksiasi arvostetaan. Mutta tämä on epäonnistuminen johtuen kehittäjien kokemuksen / taitopaketin puutteesta, jota pyysin välttämään . En ole vakuuttunut siitä, että Microsoft päättäisi olla merkitsemättä vanhentunutta tekniikkaa pelkästään MVC: n oppimiskäyrän pelon takia. Näin voi olla, mutta en ’ en vielä vakuuttunut.
• @ P.Brian.Mackey – En sanonut ’ t, että lomakekehitys on nopeampaa kuin MVC. Pyysit jättämään tuon argumentin pois. Ajan ja rahan väittäminen henkilöstön kouluttamiseksi on erilainen argumentti. MS ei ’ merkitse verkkolomakkeita vanhentuneiksi yhdestä suuresta syystä: Yritysasiakkaat ovat vuosien ajan kehittäneet verkkoasiakkaita verkkolomakkeissa ja voittaneet ’ älä odota, että sinun on investoitava aikaa ja rahaa päivitykseen.
• @Raynos – Jos kaikki tiimin jäsenet olivat taitavia MVC: ssä ja yrityksesi aloitti uutta projektia, ainoa syy, miksi näin jonkun valitsevan verkkolomakkeita, on henkilökohtainen valinta.
• Tunnen molemmat tekniikat läheisesti. Kaikki verkkoprojektini tehdään mvc: llä ja työskentelen yrityksessä, jossa minulla on vapaa hallituskaika tehdä mikä tahansa paras tapa. Valitsen aina MVC: n.
• Aloitin Webformsilla ja kun löysin MVC: n, vaihdoin siihen. En tiedä ’ en tiedä kuinka kukaan voisi puolustaa verkkolomakkeita. Sivun elinkaari ja yksi lomake koko sivulle? Vitsailetko? Yahoo sitebuilder oli luultavasti tarkoitettu asiakas sille, mutta edes he eivät halunneet ’ halua roskaa.

Kehitin ASP .Net WebForms -sovelluksia 3 vuoden ajan, ja yhden päivän tekemisen jälkeen MVC-opetusohjelma myytiin. MVC on melkein aina parempi ratkaisu. Miksi?

• Sivun elinkaari on yksinkertaisempi ja tehokkaampi
• HTML-ohjausobjektien lisäksi ei ole olemassa mitään muuta kuin ohjausobjekteja. Sinun ei tarvitse debugata lähtöäsi nähdäksesi, mitä ASP .Net luo.
• ViewModels antaa sinulle valtavan voiman ja poistaa tarpeen manuaalisen ohjauksen sidonnasta, ja se eliminoi monia sidontaan liittyviä virheitä.
• Sivulla voi olla useita lomakkeita. Tämä oli WebFormien vakava rajoitus.
• Verkko on valtioton ja MVC vastaa tarkemmin verkon arkkitehtuuria. Web-lomakkeet esittävät tilan ja virheet sinulla on mukana ottamalla käyttöön ViewState. ViewState on automaattinen ja toimii taustalla, joten se ei aina toimi haluamallasi tavalla.
• Verkkosovellusten on toimittava ajaxin kanssa näinä päivinä. Ei ole hyväksyttävää, että täyttä sivua ladataan enää enempää. MVC tekee ajaxista niin paljon paremman, helpomman ja tehokkaamman JQueryn kanssa.
• Koska sivulla voi olla useita lomakkeita ja koska arkkitehtuuri on URL-kutsujen ohjaamana voit tehdä hauskoja asioita, kuten ajax, ladata JQueryn avulla muunlaisen lomakkeen, kuten muokkauslomakkeen nykyiselle sivullesi. Kun huomaat, mitä tämän avulla voit tehdä, voit tehdä upeita asioita helposti.
• ASP .Net WebForms ei ole vain abstraktio html: n kautta, se on erittäin monimutkainen. Joskus saatat saada oudon virheen ja taistella sen kanssa paljon kauemmin kuin tarvitsee. Monissa tapauksissa voit todella nähdä, mitä se teki väärin. mutta et pysty tekemään mitään asialle. Loppujen lopuksi teet outoja kiertotapoja.
• WebForms ei ole hyvä tekniikka suunnittelijoille. Suunnittelijat haluavat työskennellä suoraan html: n kanssa. MVC: ssä se on näkymä, WebForms on puolen päivän työ.
• Koska verkkoalusta kehittyy nopeasti, WebForms ei pysy mukana. Se ei tietoinen HTML5: n uusista tunnisteista tai ominaisuuksista, se näyttää edelleen samat asiat, ellet saa (usein) kalliita kolmannen osapuolen ohjaimia tai odota, että Microsoft julkaisee päivityksen.
• WebFormien ohjausobjektit rajoittavat sinua monin tavoin. MVC: ssä voit vain napata JQuery-kirjaston ja integroida sen malleihisi.

Tiedän, että joitain yllä mainituista asioista on käsitelty jossain määrin WebFormien kehittyessä, mutta se oli alkuperäinen kokemukseni. Kaiken kaikkiaan minusta on erittäin vaikeaa löytää WebFormsin liiketalous, ellei projekti jo käytä sitä.

Kommentit

• +1 käyttäjälle osoittamalla useita lomakkeita. Lisäksi se, että HTML-verkkolomakkeet luovat, ei useimmiten ole kovin SEO-ystävällistä (kuten: suuret palat näkymän sivun päällä)
• Minun on hyväksyttävä 100% tämän vastauksen kanssa. Päivän lopussa WebForms tekee asioita asiakkaan puolella (html / selain) niin paljon vaikeammaksi. Sinun on kirjaimellisesti taisteltava kehyksiä saadaksesi aikaan jotakin. Aspx-sivulla on palvelinohjaimien takia paljon enemmän koodia kuin cshtml-sivulla. @ šljaker Jos aloitat ViewState-ohjelman sammuttamisen ja vältät palvelimen ohjaimet, ’ olet hylännyt suuren osan WebFormeista siinä vaiheessa. En näe ’ sitä, että argumentti olisi erityisen vakuuttava.
• WebFormeissa voi olla yksinkertaisia html-ohjausobjekteja. Sinulla voi olla täysi valtioton verkkolomake, kukaan ei pakota sinua käyttämään ViewStatea. Voit käyttää täyttä ajaxia ja jQueryä Web-lomakkeissa, kukaan ei estä sinua käyttämästä jQueryä. Voit ottaa käyttöön URL-reitityksen, kukaan ei pakota sinua käyttämään staattista tiedostopohjan URL-osoitetta. Sivun manuaalinen piirtäminen CSS: llä kuluttaa aikaa niin paljon kuin MVC tarvitsi. Voit suunnitella HTML-sivun suoraan Webformiin.
• @mjb: Jos et ’ käytä palvelimen ohjaimia, ViewState-sovellusta ja niin edelleen, miksi käyttää WebFormeja ollenkaan MVC on lähempänä sitä, mitä ’ teet? Se ’ haluaa ajaa traktorin töihin, mutta ei aja maastossa tai käytä lapiota / kuokkaa tai tukijalkaa. Miksi et käytä vain autoa?
• @Tjaart Ei ole oikein, että sinulla ei ole useita lomakkeita ASPNET-sivulla.Sinulla voi olla niin monta lomaketta kuin haluat ASPNET-sivulla, mutta sinulla voi olla vain yksi palvelinlomake – lomake, jossa on runat = ” palvelin ” attribuutti.

Lähetin sähköpostia Scott Guthrie , MVC-asiantuntija Microsoftilta. Ja luultavasti pätevin mies vastaamaan tähän kysymykseen. Hän oli kiltti vastaamaan:

”Eri asiakkaat etsivät erilaisia ohjelmointitapoja, ja monet rakastavat WebFormeja ja pitävät sitä hienona. Toiset rakastavat MVC: tä ja mielestäni se on hienoa. Siksi investoimme molempiin. ”

Joten minulle tämä tarkoittaa, että se ei ole tekninen asia. Se on enemmän ”pehmeä asia”, jos haluat. Yksi henkilökohtaisista mieltymyksistä. Tämä on linjassa sen kanssa, mitä monet teistä ovat sanoneet.

Kiitos kaikista vastauksista.

Kommentit

• Scott Guthrie keksi ASC.NET: n MVC-kehys lennon aikana Lontoosta Seattleen vuosina 2006/7. Kun ajatellaan sitä, hän keksi melkoisen myös .NETin ( fi.wikipedia.org/wiki/Scott_Guthrie ). Kutsuminen häntä ” asiantuntijaksi ” on valtava aliarviointi 😉
• Että ’ on mukava poliittinen vastaus Scott Guthrie. Jos hän itse investoi omaa verkkosovellustaan, ’ näette MVC-projektin ja kaikkeen, mitä ’ ei voida tehdä MVC: ssä, Silverlight olisi varavara. Älä ’ pidä tätä negatiivisena kommenttina WebFormsiin nähden, mielestäni WebFormit sopivat erinomaisesti pienempiin sisäisiin sovelluksiin, jotka voivat hyötyä kolmansien osapuolten komponenteista, kuten Telerikin luomista komponenteista. Olen ’ iloinen siitä, että Microsoft etenee molempien tekniikoiden kanssa.
• ” Scott Guthrie keksi MVC-kehyksen ASP: lle .NET lennon aikana ” mielestäni se pienentää MVC: tä. En tunne ’ en tunne Scott Guthrieä, mutta olen ’ halukas lyödä vetoa siitä, että hän oli spekuloinut, kuinka MVC voidaan toteuttaa ASP.NET: ssä jonkin aikaa, ja käytti sitä pitkää lentoa toteuttaakseen paljaiden luiden prototyypin todisteena konseptista.
• ” Siksi investoimme molempiin. ” Ja kun näemme, että verkkolomakkeet alkavat heikentyä, pudotamme sen armottomasti, koska sijoittaminen lopulta kuolleeseen tuotteeseen ei ole liiketoiminnan edun mukaista.
• Ennen sitä ei enää opeta kouluissa, monien vuosien ajan, sitä sovelletaan aina liike-elämässä. Korkeakoulut ja lukiot tarjoavat edelleen intro- ja jatkokursseja vb.netissä. Se EI mene mihinkään !!!

Tämä on vanhentunut kysymys, jossa on paljon vastauksia, mutta ei yhtään oli vastaus, jonka olisin odottanut olevan listalla.

Lyhyt vastaus on:

• Käytä ASP.NET MVC: tä, jos aiot rakentaa web-sovelluksen oikein nykyaikaisella ohjelmoinnilla yleissopimukset ja teollisuus omaksuvat mallit ASP.NET-alustalle. Alemman puolen sinun odotetaan tietävän, kuinka HTML ja asiakaspuolen resurssit (Javascript, CSS) toimivat, sekä lisäämään MVC-ohjelmointi-ajattelutapaa, jolla on jyrkkä oppimiskäyrä, mutta saavuttaa äkillisen lopun ymmärtämisen jälkeen.
• Käytä ASP.NET-verkkolomakkeita, jos käytät tai haluat käyttää GUI -keskusta, RAD (nopea sovelluskehitys) , vedä ja pudota -tekniikka prototyyppien tekemiseksi hyvin nopeasti, eli painike- / dataruudukon toiminta johdotetaan 15 minuutissa, eikä ratkaisua ole tarkoitettu tukemaan jotain kehittäjät. Tai, käytä ASP.NET-verkkolomakkeita, jos sinulla on tausta -käyttöliittymässä tai Windows Forms -kehityksessä ja haluat siirtää tietoa verkkoon.

Mutta jotta voisit tarkastella tätä oikein, sinun on ymmärrettävä kunkin historia.

ASP.NET-verkkolomakkeet olivat Microsoftin vastaus ne, jotka olivat rakentaneet dynaamisia verkkosovelluksia Visual Basic 6 Ac: n avulla tiveX-ohjaimet, palvelimen VB6-DLL: t ja ASP Classic. Tuolloin web-kehitys näiden Microsoftin työkalujen avulla oli todellinen sotku. Yhdessä koko .NET Frameworkin kanssa, joka oli Microsoftin lähde, palasi pohjimmiltaan piirustuspöydälle siitä, miten tehdä tuottava liiketoiminnan ohjelmointi Windows-pinossa, ASP.NET Web Forms oli omana aikanaan hämmästyttävä ja kaunis.

Koko lähestymistavan tarkoituksena oli antaa kehittäjille molempien maailmojen parhaat puolet jotain hyvin samanlaista kuin Windows-sovelluskehitys, mutta Internet-palveluiden voimalla.Ajatuksena oli, että samoin kuin VB6 / WinForms ”Form” (ikkuna), myös verkkosivu on muoto (aivan kuten ikkuna, katso) , ja tällä lomakkeella voit vetää ja pudottaa tarroja, tekstiruutuja, tietoruudukoita, painikkeita ja muita asioita, joihin VB / WinForms-käyttöliittymäkehittäjät olivat tottuneet.

Jotta painike tekisi jotain, vedä ja pudota sen jälkeen vain kaksoisnapsauta sitä suunnittelijassa ja puomi olet koodieditorissa ja kerro lomakkeelle, mitä tehdä, kun tämä napsauttaa ”tapahtuma tapahtuu. Juuri näin Windows-käyttöliittymän kehittäjät loivat ohjelmiston käyttämällä VB6: n -käyttöliittymää ja kilpailevia työkaluja, paitsi nyt koodi suorittaa palvelimella! Vau!

Tämä oli vuoden 2002 tekniikka. Hämmästyttävä ja kaunis omana aikanaan vastauksena Internetiin

Olen täydellinen ja täydellinen kääntäjä ASP.NET MVC: lle, enkä ole katsonut taaksepäin, että minun on silti ylläpidettävä useita erittäin suuria WebForms-sovelluksia. Otan sen käyttöön:

Verkkolomakkeet
Käytä näitä, kun sinulla on vakava raskas elämä verkkojen kanssa. Ruudukko-ohjaimet ovat todella mukavia, kun sinulla on yksinkertainen tietojoukko, joka sopii hienosti taulukkomuodossa ja haluat tarjota käyttäjille yksinkertaisen tavan päivittää tietueet. Kyllä, tiedän, että MVC 4: llä on todella kiva Ajax-luettelotyyppinen asia, jota voit käyttää ja joka toimii hyvin, mutta liiketoiminnassamme meidän on usein saatava jotain käynnissä eilen ja hyvät vanhanaikaiset verkkot toimivat hyvin ja käyttäjät ovat iloisia voidessaan olla pystyy siirtymään ruudukon yli iloisesti. Minulle tämä on todella paras asia WebFormeissa minulle; mutta kuten Ryan huomautti, WebFormit voivat olla iso aika sotku, koska pelaat molempia puolia aidan hienosta koodin takana olevasta tiedostosta. Se voi olla sekä ruusu että piikki samanaikaisesti, kun kaikki ohjaintyyppiset jutut sekoitetaan näkymiisi.

MVC
Käytä tätä, kun haluat todella luoda oman ja sinulla on mahdollisuus käynnistää sovellus tyhjästä. Selkeästi määritellyn MVC-sovelluksen käyttö on vähän enemmän työtä aloittaessa, mutta sen edut ylläpidettävyydessä ylittävät alkuperäiset asennuskustannukset. Jos haluat tehdä mielenkiintoisia Ajax-vuorovaikutuksia, kirjoita mieluummin malli koodilla, kuten puhtaat URL-osoitteet ja reitit, ja pysty hallitsemaan sovelluksesi koko kulkua, tämä on ehdottomasti oikea tapa. Tuntuminen vie jonkin verran. aluksi, mutta mielestäni se on parempi vaihtoehto greenfield -sovelluksille.

Lopuksi totean, että se tulee minulle ruudukoille ja!-ruudukoille. 🙂

Kommentit

• +1 mukavasta kuvasta, jonka ” toistaa aita hienosta koodin takana olevasta tiedostosta ”.
• Tämä on erittäin hyödyllinen. Olen ’ m tekemässä erittäin raskasta ruudukkopohjaista sovellusta ja olen ’ sulkenut pois Silverlightin, xbapin ja se oli esillä välillä nämä kaksi.

Kokemukseni:

• Kirjoitin CakePHP-projekteja yhden vuoden ajan.
• Suoritettu keskikokoinen Webforms-projekti kuuden kuukauden ajan.
• Työskennellyt Windows Forms -projektissa kolme vuotta.

Sen jälkeen Tämän kokemuksen vuoksi yritin kirjoittaa toista sovellusta verkkolomakkeiden avulla ja turhautuin sen jälkeen, kun kamppailin noin päivän ajan siitä, kuinka verkkolomakkeet yrittävät suojata kehittäjää todellisuudelta, että he kehittävät uudelleen sovellusta, joka käyttää html: tä, javascriptia ja css: tä.

Kokeilin sitten MVC: tä ja pystyin suoraan hallitsemaan lähtöä (ja jonkin verran kokemusta CakePHP: n MVC-paradigmasta), että pystyin suorittamaan tämän yksinkertaisen sovelluksen täsmälleen haluamallani tavalla noin puolessa päivässä.

Tehokkaiden käyttöliittymäkehysten, kuten jQuery, saatavuus erittäin hyvin eli vie vetoomuksen tuotannon välittömästä hallinnasta luopumisesta usein suurten valmiiden käyttöliittymäkomponenttien käytön hyväksi.

Kommentit

• @JimG – Uhh , kaikki, mikä merkitsee sitä, että henkilö syöttää tietueisiin tietueita ilman mielenkiintoisia assosiaatioita, ja sen, että kyseinen henkilö tai joku muu lukee / tulostaa niitä jossain muussa vaiheessa, voidaan periaatteessa rakentaa MVC-kehyksellä. Myönnetään, että se ei ole ’ t useimmissa sovelluksissa, mutta se ’ on helvetti paljon enemmän kuin voit tehdä Lomakkeiden kanssa. Luulen, että -1 todistaa mielipiteeni.
• Tämä ’ on 1/4 päivästä.
• Mutta jos vaatimukset ovat ” Tarvitsen sovelluksen, jolla on kaksi roolia, yksi tallentamaan tietoja, toinen tarkastelemaan sitä, enkä todellakaan ’ ole oikeastaan välitä miltä se näyttää. ” Sitten, kyllä, se ’ on melko toteutettavissa.
• anteeksi, mutta verkkolomakesovelluksen kehittäminen tietojen syöttämiseksi ja tietojen tarkastelemiseksi on niin yksinkertaista, että se voidaan tehdä muutamassa tunnissa. MVC-sovelluksen rakenteen, ohjaimet, näkymät ja toiminnot, luominen vie saman ajan, mutta ei vie sinua valmiiseen tuotteeseen.
• @Dementic Tavallisesti yksinkertaiselle MVC-sovellukselle rakennetaan malleja, sitten rakennustelineet ohjaimet ja näkymät ja / tai luodaan rakennustelineet ohjaimet / näkymät. Mikään ei ole oikeastaan aikaavievää.

Pidän parempana verkkolomakkeista, koska taustani on Windowsin kehitys.

Kehityksen nopeus on keskeinen asia, ja voin helposti välittää ongelman jollekin intialaiselle korjaamaan yön yli lomakkeilla, myös, jos minulla on sivulla nopeusongelma, todella hyvä kirja asp.netista nopeus on kätevä (Rick Kiessig on mies).

verkkolomakkeet on tarkoitettu ex windows -käyttäjille mvc on tarkoitettu verkkohenkilöille

mutta nykymaailmassa, jossa Rick on kirjoittanut mahtavan kirjan , palvelimien nopeuden kasvaessa päivittäin ja halpojen koodereiden Intiassa, verkkolomakkeilla on reuna

2 senttini on käyttää aina ASP.NET MVC: tä uusissa projekteissa, jos sinulla on siihen mahdollisuus. Mielestäni verkkolomakkeet eivät ole hyvä tapa kehittää verkkosovelluksia, ajanjakso.

Mielestäni REST-perustietojen poistaminen on huono, koko postback-malli on huono, tapa, jolla html / css-tiedostoja luotetaan graafisen käyttöliittymän muokkausohjelmassa on huono, ohjattujen toimintojen ja käyttöliittymien painottaminen tavaroiden asettamiseksi on huono, URL-osoitteet ovat huonot.

Kommentit

• voisitko selittää tarkemmin, miksi luulet niin?
• luulen, että perus-RESTin poistaminen on palannut, koko postback-malli on palannut, tapa, jolla html / css: ää luovutetaan luottamalla GUI-editoriin, on huono , tavaroiden asettamiseen liittyvien asioiden kuten ohjattujen toimintojen ja käyttöliittymien painottaminen on huono, URL-osoitteet ovat huonoja jne. ja niin edelleen.

En ole vielä nähnyt tätä harkintaa tämän ketjun nykyisten 15 vastauksen joukossa, mutta luulen sen ”harkitsemisen arvoinen.

Kokemukseni mukaan Web Forms muistuttaa enemmän Win Formsia ja WPF: tä kuin MVC. Tämän vuoksi luulen, että Web-lomakkeiden valitsemista voidaan harkita, kun tiimillä on eniten kokemusta tällaisesta tekniikasta, tai kun Web-lomakkeet-projekti toimittaa käyttöliittymän samaan tietojoukkoon kuin nykyinen (tai samanaikaisesti kehitetty) Win-lomake tai WPF-projekti. Tällöin kehittäjät voivat siirtyä hankkeiden välillä helpommin, koska sovelluslogiikka voi olla melko samanlainen näiden kahden välillä.

Kuten muut vastaukset ovat osoittaneet, MVC-kehyksen kehittäminen muistuttaa enemmän Rubyn verkkokehitystä, PHP, Python jne. Kuin Microsoftin kollegansa; joten luonnollisesti MVC: n valintaan voi vaikuttaa joukkueiden kokemus kyseisillä alueilla, samoin kuin muissa vastauksissa esitetyt tekijät.

Kommentit

• + 1 Varmasti kohtuullinen argumentti Web-lomakkeille. Pelkään, että joukkueet seuraavat tätä ajattelutapaa välttääkseen uusia asioita. MVC on täynnä monia malleja, jotka saattavat olla tuntemattomia joukkueelle. Tämäntyyppisten mallien oppiminen ja toteuttaminen johtaa parempaan SOLID-periaatteiden noudattamiseen, mikä tarkoittaa parempaa yleistä ylläpidettävyyttä. Nämä todistetut tekniikat ovat myös todellinen avain uudelleenkäytettävyyteen.

Syömme olla menemättä muutama vuosi sitten MVC: lle, se oli Microsoftin kehittymätön tekniikka. Viime vuosien aikana olemme nyt kypsemmässä versiossa (4), ja MS näyttää olevan selvittänyt, mihin he menevät tämän kanssa.Olemme kuitenkin edelleen haluttomia kehittämään suuria LOB-sovelluksia, joissa käytetään MVC: tä, koska ominaisuudet, joita haluamme käyttää versiossa 4, edellyttävät Windows 2012 -palvelinta (verkkopistorasiat uudelleen IIS8: n kautta). Uskon vielä yhden vuoden kuluttua, että otamme MVC: n paremmin vastaan, koska toivottavasti lisää kolmansien osapuolten ohjauksia on käytettävissä, tekniikka on asettunut ja meillä on infrastruktuuri sitä tukemaan.

Kommentit

• Haluatko luetella joitain näistä ominaisuuksista, joiden sanot tarvitsevasi Windows Server 2012: ta?

Tämä päätös riippuu mieltymyksistäsi, vaatimuksistasi tai jopa tiedostasi ja kokemuksestasi.

MVC: n harjoittelun aika tai aika saada toimitus. Kaikilla näillä asioilla on merkitystä yhden tai toisen esityksen valitsemisessa.

Eikö se ole parempi kuin toinen, yksinkertaisesti molemmilla esityksillä tai kehyksillä on hyviä ja huonoja puolia.

Henkilökohtaisesti kannatan MVC 3: ta, Suosittelen sinua kokeilemaan omaa kokemustasi, mutta minun on sanottava, että MVC: n ohjelma on puhdas, hauska, joustava, laajennettavissa, turvallinen ja jäsennelty tapa.

Terveisin

Ainoa syy, miksi valitsisin Web-lomakkeet MVC: n sijasta, on se, että sinulla on paljon enemmän kolmannen osapuolen käyttöliittymän ohjaimia WebFormeille kuin MVC: lle. Valitsin MVC: n, koska olen työskennellyt liikaa WebFormien kanssa ja haluan työskennellä jotain uutta / uutta, mutta silti MS shopista 🙂

Mikään ei estä sinua poistamasta WebFormsin näkymää käytöstä ja käyttämästä ViewModelsia ja if / for -silmukat mallin sidonnan ja palvelinpuolen ohjainten sijaan.

Onko tämä WebForms- tai MVC-koodi:

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

Ainoa rajoitus, jonka löysin WebFormseista, on se, että jos käytät riippuvuuden injektiota / inversiota Ohjaus, et voi saada konstruktorinsyöttöä, koska WebForms-sivuilla on oltava parametrittomat konstruktorit, joten sinun on käytettävä ominaisuusinjektiota. Onko tämä todella iso juttu?

ASP.NET MVC on oikeastaan vastaus Rubyyn, ja uusi, trendikäs ja (IMO) parempi tapa irrottaa selain (asiakas) palvelimesta mahdollisimman paljon.

ASP.NET-verkkolomakkeet antaa sinulle suuren hallinnan asiakkaan palvelinpuolelta, suoralla pääsyllä melkein kaikkeen. Pohjimmiltaan näkymäsi ja ohjaimesi ovat yksi ja sama, mikä antaa sinulle paljon voimaa ja useimmiten paljon sotkua.

ASP.NET MVC erottaa näkymän ja ohjaimen irrottamalla .aspx-tiedosto ja .aspx.cs-tiedosto, joka seuraa niitä verkkolomakkeissa.

Erona on, että käsittelystäsi paljon enemmän (yleensä kaikki) näyttää tietoja tarkastelutiedostoon ja jättämällä liiketoimintalogiikka ja loput ohjaimeen pitäen ne molemmat puhtaampina sopimuksen mukaan, mutta myös siten, että niillä on vähemmän pääsyä toisiinsa kuin verkkolomakkeet sallivat.

Kommentit

• Joten MIKSI verkkolomakkeita tulisi suosia MVC: hen nähden? Tämä ei vastaa alkuperäiseen julistekysymykseen.
• @WeekendWarrior – Jos verkkohakemuksia halutaan lisätä palvelinpuolella asiakkaalle, valitse verkkolomakkeet. Jos haluat, että asiakas / palvelin erotetaan enemmän koodistasi, valitse MVC. Päivän lopussa he molemmat tekevät täsmälleen saman asian. Reitityssuodattimet tekevät saman asian kuin MVC-URL-osoitteet, ja voit siirtää verkkolomakekoodin taaksepäin erilliseen keskitasoon sen irrottamiseksi toisistaan. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Kolmannesta näkökulmastasi tämä liiketoimintalogiikka pääsee .aspx.cs-tiedostoon – mielestäni tämä on kehittäjien vika. Sen ’ ei ole / sen pitäisi olla siellä. Web-lomakkeissa .aspx on ” -näkymä ”, .aspx.cs on ” controller ” vastaava, tarkoitettu käsittelemään vain käyttöliittymään suoraan liittyvää koodia kyselemällä yrityskerrosta tai karkearakeista yritysjulkisivukerrosta. Se, että ihmiset asettavat liiketoimintalogiikan .aspx.cs-tiedostoon, on vain huono ohjelmointi. He voivat myös asettaa liiketoimintalogiikan MVC: n näkymään! MVC ’ ei pakota näiden asioiden erottamista toisistaan.
• Hän on pohjimmiltaan oikeampi kuin muut tähän lähetetyt vastaukset. ASP.net on Microsoftin luoman modulaarisen verkkoteknologiaperheen perusidea. ASP.net MVC -moduuli saattaa olla ajallinen hype, mutta varmasti se ei ole viimeinen, kaikki alkaa ASP.net: stä, joten milloin valita ASP.net, jos et usko, että MVC ei ole sinun juttusi, ehkä enemmän jotain muuten OWIN tai …, jotain edistyneempää, tai teet oman kehyksen tehtäviisi. Et ehkä tarvitse edes ASP.MVC: tä ja ohita se ja mene Owin tai Katana, mutta kunnes käytät siellä aspia.verkko

Mielestäni ne ovat tarpeeksi toisiinsa yhteydessä ja niillä on suunnilleen samat ominaisuudet kuin sen pitäisi tulla etusijalle.

Suuri WebForms-kehittäjä voi tuottaa yhtä tehokkaan tuotteen kuin suuri MVC-kehittäjä. Mutta suuri WebForms-kehittäjä, joka yrittää pakottaa itsensä hyväksymään MVC: n, tulee olemaan lyhyt. Sama koskee upeaa MVC-kehittäjää, joka antaa WebFormsiin kuvan.

Ne eivät ole täysin erillisiä kokonaisuuksia, ja niin kauan kuin Microsoft tukee molempia, uskon, että näette edelleen sekoitetun ryhmän poikkeuksellisia kehittäjiä kullekin.

Kyse on henkilökohtaisesta valinnasta, olettaen, että olemme kaikki perehtyneitä käyttämäämme tekniikoihin. Olen käyttänyt WebForms-suunnittelumenetelmää monien vuosien ajan, ja minun on sanottava, että ainoa haittapuoli on, että sen yksinkertaistetun lähestymistavan takia monet ihmiset eivät viettää aikaa löytääkseen sen suuria ominaisuuksia.

Käytin äskettäin MVC: tä projektin loppuunsaattamiseen, ja vaikka pidän aivan suunnittelun lähestymistavasta sovelluskehitykseen (joka antaa sinulle enemmän hallintaa, puhtaita URL-osoitteita, SOC: ia jne.), se ei todellakaan ole paljoa , että WebFormit eivät voi ”t. Itse asiassa jQueryn syntyminen ja sen toiminta WebFormsien (sekä MVC: n) kanssa on tehnyt näistä argumenteista vähemmän ongelman. Ja kun ihmiset puhuvat huolenaiheiden erottamisesta MVC: n etuna MVP: hen nähden, kysyn heiltä, kuinka paljon he tietävät objektisuuntautuneesta ohjelmoinnista ja siitä, kuinka paljon he käyttävät abstraktion ja polymorfismin periaatetta.

Olen tällä hetkellä mukava käyttää molempia tekniikoita ja valitsen tilanteen mukaan. Suoraan sanottuna se on sinulle, mutta totuus on, että kaikki eivät vie aikaa oppia perusteellisesti mihin tietty tekniikka kykenee.

Kommentit

• Sama pätee verkkolomakkeiden valtavat ominaisuudet. Suurin osa ihmisistä näkee verkkolomakkeiden harjoituspyörät ja vertaa niitä MVC: hen.
• HTML-koodin ja Javascriptin lisäksi abstraktin oppimiseen ei ole juurikaan merkitystä tänä päivänä (jopa 2013). Se ’ ei tee sinulle mitään hyötyä tulevaisuuden mahdollisuuksillesi. HTML ja Javas käsikirjoitus on hieno tapa. Taistelu on häviävä taistelu.

Kun kohtaan ohjelmointiongelmaa, katson usein Internetiä vastauksia varten. Web-lomakkeilla on paljon tietoa / komponentteja, jotka tekevät melkein mitä tahansa. MVC: ssä, koska verkossa on vähemmän lähteitä ja jonkin toiminnan aikaansaamiseksi tarvittavat abstraktiokerrokset, ovat asettaneet rajan asioille, jotka voisin kerran tehdä. MVC tappaa tuottavuuteni kehittäjänä, kun taas Webformsilla se ei ole. Joten toistaiseksi pidän kiinni verkkolomakkeista, kunnes MVC on kypsynyt tarpeeksi korvaamaan sen.

WebFormeilla on enemmän oppimisresursseja (yksinkertaisesti johtuen siitä, että se on vanhempi), joten uudet ohjelmoijat, jotka eivät ole ”t” tiedossa, löytävät todennäköisemmin tietoa tästä vanhemmasta tekniikasta, toisin kuin uudemmat asiat, kuten MVC.

Vanhemmat / kokeneet ohjelmoijat ovat vanhempia ja osaavat vanhempaa tekniikkaa, koska he ovat ohjelmoineet siihen kauemmin kuin he on uudemmassa.

Ellet pysty käyttämään rahaa ja vaivaa saadaksesi kaverisi yhtä taitavaksi MVC: ssä kuin he WebForms-sovelluksissa, yrität epäilemättä pitää päivitystä uuteen alustalle niin kauan kuin mahdollista.

Joten se tuo esiin useita logistisia ongelmia: Ovatko MVC: n edut kustannusten huonompia ja käyttöönottoaika? Jos minulla on sivusto, joka on kirjoitettu kokonaan WebFormsiin, kannattaako vaivaa ja rahaa integroida MVC siihen?

Kuten edellinen kommentaattori totesi, MVC estää myös sinua saavuttamasta samaa käyttöliittymää ohjainta kuten pystyt WebFormsin kanssa. Vaikka pidän kaikkia asioiden ”Pidä käyttäjää täynnä asioita / oppimasta” -puolella, joukkueille voi silti olla kohtuuttoman hankalaa ottaa käyttöön / toteuttaa ohjelma, joka pitää fanaattisesti kiinni kaikesta kirjoittamastaan paradigmasta.

Luulen, että näiden kahden tekniikan välinen kuilu ei ole niin suuri kuin ennen.

• Verkkolomakkeet voivat käyttää MVC: n käyttämää reititysmoottoria (tai jotain hyvin samanlaista).
• Komentosarjan hallinta voi yhdistää komentosarjoja, ladata CDN: stä ja jopa viivästyttää komentosarjojen lataamista.

Mielestäni kysymys on mielestäni ensisijainen. ja / tai mikä projekti on. Molemmat suhtautuvat kehitykseen huomattavasti eri tavalla. Henkilökohtaisesti olen työskennellyt siirtymässä kohti MVC: tä, mutta nautin silti työskentelystä Webformsin kanssa. Mielestäni vastaus MVC: n tai Webformsin käyttämiseen on, että päätät molempien tekniikoiden kautta.

kommentit

• Verkkolomakkeet ja MVC suosittelevat oletusarvoisesti täysin erilaista verkkokehitysasennetta. ” -oletusarvosta ”. Molempia voidaan käyttää saman asian saavuttamiseen.