Den forklarer om hva som er MVC Pattern og hva som er ASP.NET MVC Framework hvordan det fungerer. Forklarer også ASP.NET MVC-sidens livssyklus og ASP.NET MVC-funksjoner versjonsmessig.

Eksempler gitt trinnvise kloke for å hjelpe nybegynnere til å forstå enkelt og bli dyktige i ASP.NET MVC.

Som vi alle kjenner til mange designmønstre og bruk av dem til å implementere forretningskomponenter og tjenester i applikasjonene våre, men likevel vil vi stå overfor problemer/utfordringer med applikasjonene våre. Også dag for dag forretningsbehov og prioriteringer vil endre seg. Hvis vi nøye observerer en rekke problemer, er defekter og utfordringer vi står overfor i UI og presentasjonslag. Selv om noen mangler er relatert til forretningslogikk og forretningsregler, kan det hende vi må fikse dem i brukergrensesnitt og presentasjonslag, da vi kan tett integrerte forretningslogikk i brukergrensesnitt og presentasjonsnivåer. Årsaken bak dette er at vi ikke har fokusert på å implementere riktig designmønster i applikasjonene våre. La oss gå gjennom trinn for trinn og forstå hvordan vi implementerer og bruker presentasjonsmønster i applikasjonene våre.

Problemstilling:

Bruker allerede forskjellige mønstre i applikasjonen, men det er fortsatt vanskelig å opprettholde applikasjonen.
Bruker VS Test, NUnit, MBUnit etc for å teste forretningslogikklag, men fortsatt finnes det noen defekter i applikasjonen som forretningslogikk involvert i presentasjonslaget.
Brukte Presentation Layer, Business Logic Layer, Data Access Layer i applikasjonen, men trenger fortsatt noen ganger å skrive redundant kode i presentasjonslaget for å konsumere eller kalle andre moduler eller andre brukstilfeller.
Integrasjonsfeil blir injisert når vi gjør noen endringer i integrerte moduler.
Feilfiksing og forbedringer tar mer tid å analysere presentasjonsnivålogikken og dens integrasjonsavhengigheter og årsaker til å åpne nye defekter.
ASP.NET MVC kan ikke velges da brukergrensesnittet er komplisert å bygge.

Hovedårsaken til problemet:

I presentasjonslaget,

En side eller et skjema inneholder kontroller som viser applikasjonsdomenedata. En bruker kan endre dataene og sende inn endringene. Siden henter domenedataene, håndterer brukerhendelser, endrer andre kontroller på siden som svar på hendelsene, og sender inn de endrede domenedataene. Inkludere koden som utfører disse funksjonene på nettsiden I tillegg er det vanskelig å dele kode mellom nettsider som krever samme oppførsel. klassekomplekset, vanskelig å vedlikeholde og vanskelig å teste.
UI Layer, UI Logic, Presentation Logic, Business Logic er tett koblet sammen.
Presentasjonslaget tar seg av integrering av moduler eller brukstilfeller.

Løsning:

Velg det beste presentasjonslagmønsteret for å skille UI-laget, UI-logikk og presentasjonslogikk og forretningslogikk som separate lag for å gjøre koden enklere å forstå og vedlikeholde.
Aktiver løs kobling mens du utvikler moduler eller bruksområder.
Maksimer koden som kan testes med automatisering. (Visninger er vanskelig å teste.)
Del kode mellom sider som krever samme oppførsel.
Del ansvaret for den visuelle visningen og hendelseshåndteringsatferden i forskjellige klasser som heter henholdsvis visningen og presentatøren eller kontrolleren eller ViewModel.

Fordeler med å bruke presentasjonsmønster:

Modularitet
Testdrevet tilnærming – maksimer koden som kan testes med automatisering
Separasjon av bekymringer
Kodedeling mellom sider og skjemaer
Enkel å vedlikeholde

Hva er tilgjengelige presentasjonslagsmønstre?

MVC (Model View Controller)

MVP (Model View Presenter) eller (Model Passive View, Supervisor Controller)

MVVM (Model View ViewModel)

MVC vs MVP vs MVVM:

Representerer modell og visning det samme i alle de tre ovennevnte mønstrene?

Ja
Kontroller, presentatør og ViewModel er formålet det samme i alle de tre ovennevnte mønstrene?

Ja
Kommunikasjon og flyt av modell, visning med kontroller, presentator og visningsmodell er den samme?

Nei, det er grunnen til at disse tre mønstrene eksisterer.
Er disse mønstrene erstatning for PL (Presentation Layer), BLL (Business Logic Layer) og DAL (Data Access Layer)

Nei, disse mønstrene er for å skille UI og UI Logic fra Presentation Logic og aktiverer den løse koblingen.

Velg det beste presentasjonslagmønsteret:

MVP

Binding via en datakontekst er ikke mulig
Kompleks UI-design
Best for Windows Forms, ASP.NET Web Forms og Sharepoint-applikasjoner

MVC

Best for ASP.NET med Simple UI
Frakoblet modell (se separasjon fra alle andre lag)

Merk: Her fokuserer jeg ikke på MVC VM (MVC ViewModel fra MVC3) og ASP.NET MVVM med Dependency Injection.

MVVM

Binding via en datakontekst er mulig
Tilkoblet modell
Best for WPF- og Silverlight-applikasjoner

ASP.NET Web Forms vs ASP.NET MVC:

ASP.NET webskjemaer

RAD
Enklere utvikling
Rik kontrollerer økosystemet
Kjent som utviklingstilnærmingen til Windows Forms-utvikling
Ingen ViewStateog ingen postback-støtte

ASP.NET MVC

Clean Separation of Concern (SoC)
Full markup kontroll
Aktiver TDD (Test Driven Development)
Aktiver og gjør enkelt REST
Enklere integrering på klientsiden (Javascript)
Multi View Engine (dette er veldig kult!)
Ingen ViewState og ingen postback-støtte
Utvidbar og WEB 2.0 aktivert

Modell, visninger og kontroller

Modell: Modellobjekter er delene av applikasjonen som implementerer logikken for applikasjonens datadomene. Ofte henter og lagrer modellobjekter modelltilstand i en database. Et produktobjekt kan for eksempel hente informasjon fra en database, operere på den og deretter skrive oppdatert informasjon tilbake til en produkttabell i SQL Server.
Visninger: Visninger er komponentene som viser applikasjonens brukergrensesnitt (UI). Vanligvis er dette brukergrensesnittet opprettet fra modelldataene. Et eksempel kan være en redigeringsvisning av en produkttabell som viser tekstbokser, rullegardinlister og avmerkingsbokser basert på gjeldende tilstand til et produktobjekt.
Kontroller: Kontrollere er komponentene som håndterer brukerinteraksjon, jobber med modellen og til slutt velger en visning som skal gjengis som viser brukergrensesnittet. I en MVC-applikasjon viser visningen kun informasjon; kontrolleren håndterer og reagerer på brukerinnspill og interaksjon. For eksempel håndterer kontrolleren spørrestrengverdier, og sender disse verdiene til modellen, som igjen spør databasen ved å bruke verdiene.

ASP.NET MVC sidelivssyklus på høyt nivå?

ASP.NET MVC-sidelivssyklus på lavt nivå?

MVC2.0 Nye funksjoner

1 maler for hjelpere:

Templated Helpers hjelper oss å automatisk knytte HTML-elementer for redigering og visning med datatyper.

For eksempel når data av typen System.DateTimevises i en visning, kan et datepicker UI-element gjengis automatisk.

Dette ligner på hvordan feltmaler fungerer i ASP.NET Dynamic Data.

2 områder:

Bruke områder Vi kan organisere et stort prosjekt i flere mindre seksjoner for å håndtere kompleksiteten til en stor nettapplikasjon.

Hver seksjon ("område") representerer vanligvis en separat seksjon av et stort nettsted og brukes til å gruppere relaterte sett med kontroller og visninger.

F.eks

Areas
    Admin
    Controllers
    Models
    Views
    Iniala Claims
    Controllers
    Models
    Views

3 Støtte for asynkrone kontrollere:

ASP.NET MVC2 lar kontrollere behandle forespørsler asynkront.

Dette kan føre til ytelsesgevinster ved å la servere som ofte kaller blokkeringsoperasjoner (som nettverksforespørsler) ringe til ikke-blokkerende motparter i stedet.

4 Støtte for `DefaultValueAttribute`in Action-Method-parametre:

Klassen System.ComponentModel.DefaultValueAttributelar en standardverdi angis for argumentparameteren til en handlingsmetode.

Anta for eksempel at følgende standardrute er definert:

{controller}/{action}/{id}

Anta også at følgende kontroller og handlingsmetode er definert:

public class ArticleController
{
  public ActionResult View(int id, [DefaultValue(1)]int page)
  {
  }
}

Enhver av de følgende forespørsels-URLene vil påkalle View-handlingsmetoden som er definert i det foregående eksempelet.

/Artikkel/Visning/123
/Article/View/123?page=1 (Faktisk det samme som forrige forespørsel)
/Artikel/Vis/123?page=2

5 Støtte for binding av binære data med modellbindere:

Det er to nye overbelastninger av Html.Hiddenhjelperen som koder binære verdier som base-64-kodede strenger:

public static string Hidden(this HtmlHelper htmlHelper, string name, Binary value);
public static string Hidden(this HtmlHelper htmlHelper, string name, byte[] value);

6 Støtte for `DataAnnotations`attributter:

Ved å bruke RangeAttribute, RequiredAttribute, StringLengthAttribute, og RegexAttributevalideringsattributtene (definert i System.ComponentModel.DataAnnotationsnavneområdet) når vi binder oss til en modell for å gi inndatavalidering.

using System.ComponentModel.DataAnnotations;
namespace MvcTmpHlprs
{
    [MetadataType(typeof(ProductMD))]
    public partial class Product
    {
        public class ProductMD
        {
            public object SellStartDate { get; set; }
            [UIHint("rbDate")]
            public object SellEndDate { get; set; }
            [DataType(DataType.Date)]
            public object DiscontinuedDate { get; set; }
            [ScaffoldColumn(false)]
            public object ModifiedDate { get; set; }
            [ScaffoldColumn(false)]
            public object rowguid { get; set; }
            [ScaffoldColumn(false)]
            public object ThumbnailPhotoFileName { get; set; }
        }
    }
}

7 leverandører av modellvalidering:

Modellvalideringsleverandørklassen representerer en abstraksjon som gir valideringslogikk for modellen.

ASP.NET MVC inkluderer en standardleverandør basert på valideringsattributter som er inkludert i navneområdet System.ComponentModel.DataAnnotations.

8 validering på klientsiden:

Modellvalidatorleverandørklassen eksponerer valideringsmetadata for nettleseren i form av JSON-serialiserte data som kan konsumeres av et valideringsbibliotek på klientsiden.

ASP.NET MVC 2 inkluderer et klientvalideringsbibliotek og -adapter som støtter navneområdevalideringsattributtene DataAnnotationsnevnt tidligere.

9 nytt `RequireHttpsAttribute`handlingsfilter:

ASP.NET MVC 2 inkluderer en ny RequireHttpsAttributeklasse som kan brukes på handlingsmetoder og kontrollere.

Som standard omdirigerer filteret en ikke-SSL (HTTP)-forespørsel til den SSL-aktiverte (HTTPS) ekvivalenten.

10 Overstyre HTTP-metodeverbet:

Når vi bygger et nettsted ved å bruke REST-arkitektonisk stil, brukes HTTP-verb for å bestemme hvilken handling som skal utføres for en ressurs.

REST krever at applikasjoner støtter hele spekteret av vanlige HTTP-verb, inkludert GET, PUT, POST, og DELETE.

ASP.NET MVC 2 inkluderer nye attributter som vi kan bruke på handlingsmetoder og som har kompakt syntaks.

Disse attributtene gjør det mulig for ASP.NET MVC å velge en handlingsmetode basert på HTTP-verbet.

For eksempel vil en POSTforespørsel kalle den første handlingsmetoden og en PUTforespørsel kalle den andre handlingsmetoden.

[HttpPost]
 public ActionResult Edit(int id)
  
[HttpPut]
 public ActionResult Edit(int id, Tag tag)

I tidligere versjoner av ASP.NET MVC krevde disse handlingsmetodene mer detaljert syntaks, som vist i følgende eksempel:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(int id)
 
[AcceptVerbs(HttpVerbs.Put)]
public ActionResult Edit(int id, Tag tag)

Fordi nettlesere kun støtter verbene GETog POSTHTTP, er det ikke mulig å legge ut til en handling som krever et annet verb. Dermed er det ikke mulig å støtte alle RESTfulforespørsler.

For å støtte RESTfulforespørsler under POSToperasjoner, introduserer ASP.NET MVC 2 imidlertid en ny HttpMethodOverrideHTML-hjelpermetode.

Denne metoden gjengir et skjult inndataelement som får skjemaet til å emulere en hvilken som helst HTTP-metode effektivt.

For eksempel, ved å bruke HttpMethodOverrideHTML-hjelpemetoden, kan vi få en skjemainnsending til å vises som en PUTeller DELETEforespørsel.

Atferden til HttpMethodOverridepåvirker følgende attributter:

HttpPostAttribute
HttpPutAttribute
HttpGetAttribute
HttpDeleteAttribute
AcceptVerbsAttribute

11 ny `HiddenInputAttribute`klasse for malerhjelpere:

Vi kan bruke det nye HiddenInputAttributeattributtet på en modellegenskap for å indikere om et skjult inngangselement skal gjengis når modellen vises i en editormal (Attributtet setter en implisitt UIHintverdi på HiddenInput).

Attributtets DisplayValueegenskap lar oss spesifisere om verdien skal vises i redigerings- og visningsmodus.

Når DisplayValueer satt til usann, vises ingenting, ikke engang HTML-markeringen som vanligvis omgir et felt.

Standardverdien for DisplayValueer sann.

Vi kan bruke HiddenInputAttributeattributt i følgende scenarier:

Når en visning lar brukere redigere ID-en til et objekt og det er nødvendig å vise verdien samt å gi et skjult inngangselement som inneholder den gamle ID-en slik at den kan sendes tilbake til kontrolleren.
Når en visning lar brukere redigere en binær egenskap som aldri skal vises, for eksempel en tidsstempelegenskap.

I så fall vises ikke verdien og den omkringliggende HTML-oppmerkingen (som etiketten og verdien).

For eksempel:

public class ProductViewModel
{
    [HiddenInput] // equivalent to [HiddenInput(DisplayValue=true)]
    public int Id { get; set; }
  
    public string Name { get; set; }
  
    [HiddenInput(DisplayValue=false)]
    public byte[] TimeStamp { get; set; }
}

12 `Html.ValidationSummary`hjelpemetoder kan vise feil på modellnivå:

I stedet for alltid å vise alle valideringsfeil, Html.ValidationSummaryhar hjelpemetoden et nytt alternativ for å vise bare feil på modellnivå.

Dette gjør at feil på modellnivå kan vises i valideringssammendraget og feltspesifikke feil vises ved siden av hvert felt.

13 T4-maler i Visual Studio Generer kode som er spesifikk for målversjonen av .NET Framework:

En ny egenskap er tilgjengelig for T4-filer fra ASP.NET MVC T4-verten som spesifiserer versjonen av .NET Framework som brukes av applikasjonen.

Dette gjør det mulig for T4-maler å generere kode og markeringer som er spesifikke for en versjon av .NET Framework.

I Visual Studio 2008 er verdien alltid .NET 3.5. I Visual Studio 2010 er verdien enten .NET 3.5 eller .NET4.

14 API-forbedringer:

Lagt til en beskyttet virtuell CreateActionInvokermetode i Controller-klassen.

Denne metoden påkalles av ActionInvokeregenskapen til kontrolløren og tillater lat instansiering av påkalleren hvis ingen påkaller allerede er angitt.

Opptakskilde: instantshift.com