ASP.NET vNext er vertskap agnostiker, hva betyr det dypt mener?

stemmer
36

Ifølge ASP.NET vNext tutorial :vNext is host agnostic . You can host your app in IIS, or self-host in a custom process

Kan noen hjelpe meg å forstå dette i deepth med å vise forskjellen mellom nåværende asp.net vert og ny?

Publisert på 21/08/2014 klokken 16:51
kilden bruker
På andre språk...                            


2 svar

stemmer
65

Historien om ASP.NET hosting

Tilbake i 2002, var det i utgangspunktet en webserver for .NET-plattformen, og det var IIS. Noen år senere Visual Studio Utvikling Web Server ( "Cassini", tidligere en del av den opprinnelige Web Matrix) kom sammen som en dev-only server. Men alle disse pengene brukes System.Web som hosting lag mellom applikasjonen og webserveren. Den System.Web Verten er tett koplet til IIS og er svært vanskelig å drive på andre verter. Selv gjennomføringen på VS Dev Web Server var begrenset fordi det støttes bare enkelte funksjoner. Så som sådan, var det fortsatt bare en produksjonskvalitet "host" for typiske ASP.NET applikasjoner som var avhengig av System.Web.

Spol frem om et tiår og OWIN kom rundt som et grensesnitt mellom programmer og webservere. Dette gjorde noen OWIN-kompatibelt program for å snakke gjennom OWIN til en webserver som hadde en OWIN-kompatibel hosting lag. Microsoft skrev Katana som en OWIN implementering som kan være vert for ASP.NET Web API, ASP.NET SignalR, og mange 3. parts rammer på toppen av flere servere, inkludert IIS (og IIS Express), Katana selvvertsserver, og egendefinerte verter ( dvs. kjøre Katana fantas i en tilpasset app). Det er en annen OWIN implementering kalt nowin som bør være i stand til å kjøre de samme programmene som Katana. Dette er et eksempel på verts agnostisisme.

Nå Spol frem et par år til, og det er ASP.NET vNext , som følger en modell svært lik OWIN i form av å ha mellomvare og har vert agnostisisme. ASP.NET vNext har kompatibilitets lag for OWIN mellomvare app-komponenter i tillegg.

ASP.NET vNext host agnostisisme

ASP.NET vNext er vertskap agnostiker på samme måte som Katana og OWIN. Applikasjoner skrevet med ASP.NET vNext bare vet om en rekke Abstraction Layer, som IApplicationBuilder(tidligere IBuilder) grensesnitt. Søknader ikke snakke direkte til webserveren. Mye av dette abstraksjon er gjort gjennom "har grensesnitt" slik at noen servere kan implementere funksjoner og andre kan velge å ikke.

Web hosting alternativer

ASP.NET vNext programmer kan ligge på IIS, IIS Express, dine egne EXE, i den nye kryssplattform Kestrel server, og ingen tvil om flere verter i fremtiden.

Verken Katana eller ASP.NET vNext er erstatninger for IIS eller andre maskiner, selv om de begge har alternative webservere. IIS støtter noen mer avanserte funksjoner i forhold til Katana og ASP.NET vNext, for eksempel søknad warm-up, rikere søknad livstid management (dvs. hva de skal gjøre når appen krasjer, kontrollere hvor mye minne den bruker, og andre typer struping) ekstern styring, og så videre.

Fordeler med OWIN, ASP.NET vNext, og være vertskap agnostiker

Jeg kan ikke snakke til motivasjon for å lage OWIN fordi jeg var aldri en del av den gruppen. Men fordelene ved å ha en web server host abstraksjon er mange:

  • Kan bytte mellom vertene relativt enkelt. For eksempel er det vanlig å kjøre lokalt på en utvikling som bare server som kan kjøre med minimale rettigheter. Deretter ved distribusjon til produksjonen, er kanskje en mer fullverdig vert som IIS brukt. IIS krever imidlertid administrative tillatelser til å installere, som ikke alle har på sine arbeidsstasjoner.
  • Flere hosting alternativer kan eksistere. Vei tilbake i dag på grunn av den nære avhengighet av ASP.NET på IIS bare én vert kunne eksistere, så det var effektivt ingen "markedet" for andre verter.
  • Visse typer tester er lettere å skrive ved å ha en in-memory test vert. Dette brukes ofte til å teste hele bunken med en web-applikasjon, men uten nettverk samtaler.

Motivasjonene for ASP.NET vNext er oppført delvis på den offisielle ASP.NET vNext nettstedet i Komme i gang opplæringen. En kort oppsummering er: å ha en cross-platform, åpen kildekode, side-by-side, pay-as-you-go, vert-agnostisk plattform for å bygge web apps og tjenester. Høres ut som noen markedsføring ting, men disse er alle viktige aspekter av systemet. NodeJS tilbyr ganske mye den samme eksakte sett av funksjoner, men selvfølgelig når du ser på detaljene, er det selvfølgelig mange implementerings forskjeller og ingen tvil om noen dypere filosofiske forskjeller også. Motivasjon for å støtte disse funksjonene er generelt selvforklarende.

Målgruppe for ASP.NET

Merk at dette er om publikum av ASP.NET generelt, som omfatter alt fra ASP.NET Web Forms, til MVC, Web API, SignalR, Katana, og ASP.NET vNext. Noen av disse rammene er egnet for alle størrelser prosjekt og skal kunne brukes av enhver rimelig dyktig utvikler. Dette er tydelig ved å se på størrelsen på prosjekter som bruker dem. Denne svært hotellet (StackOverflow.com) er bygget delvis med ASP.NET MVC, etter noen svært avanserte utviklere (jeg antar), men det er mange mye mindre nettsteder som bruker MVC bygget ved relative nybegynnere. ASP.NET vNext er fremtiden versjon av de fleste av de samme rammene, og slik det er rettet mot den samme type programmer og samme type utviklere.

Mer informasjon

For litt mer info om ASP.NET vNext og OWIN, sjekk ut et blogginnlegg fra en av utviklerne: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

Svarte 26/08/2014 kl. 18:17
kilden bruker

stemmer
-1

Husk at vNext er fortsatt et svært fargerike rask bevegelse objekt, som det er nå for tiden, det er slags "halv" vert agnostiker.

Mellomvare spec at den definerer og bruker tillater for en svært generisk grensesnitt for å arrangere programmer. Så måten du utvikler er den samme. Men vNext apps er selv servere og på en merkelig måte, er nå pålagt å inkludere lim biblioteker for type server du bruker.

Du kan observere dette ved å se at du må oppgi hvilken type server du vil bruke i din project.jsonfil. Hvis vNext prosjektene var virkelig agnostiker, ville du velge en server på et systemnivå og peke på, montere eller starte din app fra den valgte serveren.

Det er litt komplisert på grunn av de involverte livssykluser, når du er ferdig her, oppfordrer jeg deg til å gå over til denne github saken på vNext prosjekt der jeg prøver å argumentere for en virkelig frakoblet design.

Svarte 05/10/2014 kl. 21:22
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more