Designmönster – MVC-mönsterprover för nybörjare

0

Den förklarar vad som är MVC Pattern och vad som är ASP.NET MVC Framework hur det fungerar. Förklarar också ASP.NET MVC-sidans livscykel och ASP.NET MVC-funktioner versionsmässigt.

Exempel tillhandahåller steg kloka för att hjälpa nybörjare att enkelt förstå och bli skickliga i ASP.NET MVC.

Som vi alla känner till många designmönster och att använda dem för att implementera affärskomponenter och tjänster i våra applikationer, men ändå kommer vi att möta problem/utmaningar med våra applikationer. Också dag för dag affärsbehov och prioriteringar kommer att förändras. Om vi ​​noga observerar ett antal problem, är defekter och utmaningar vi står inför i användargränssnitt och presentationslager. Även om vissa defekter är relaterade till affärslogik och affärsregler kan vi behöva fixa dem i användargränssnitt och presentationslager eftersom vi kan integrera affärslogik i användargränssnitt och presentationsnivåer. Anledningen till detta är att vi inte har fokuserat på att implementera rätt designmönster i våra applikationer. Låt oss gå igenom steg för steg och förstå hur man implementerar och använder presentationsmönster i våra applikationer.

Problembeskrivning:
  1. Använder redan olika mönster i applikationen men ändå är det svårt att behålla applikationen.
  2. Använder VS Test, NUnit, MBUnit etc för att testa affärslogikskiktet, men det finns fortfarande några defekter i applikationen som affärslogik involverad i presentationslagret.
  3. Använder Presentation Layer, Business Logic Layer, Data Access Layer i applikationen men behöver fortfarande ibland skriva redundant kod i presentationslagret för att konsumera eller anropa andra moduler eller andra användningsfall.
  4. Integrationsdefekter injiceras när vi gör några ändringar i integrerade moduler.
  5. Felkorrigering och förbättringar tar längre tid att analysera presentationsnivålogiken och dess integrationsberoenden och orsaker till att nya defekter öppnas.
  6. ASP.NET MVC kan inte väljas eftersom användargränssnittet är komplicerat att bygga.
Grundorsaken till problemet:

I presentationslagret,

  1. En sida eller ett formulär innehåller kontroller som visar programdomändata. En användare kan ändra uppgifterna och skicka in ändringarna. Sidan hämtar domändata, hanterar användarhändelser, ändrar andra kontroller på sidan som svar på händelserna och skickar den ändrade domändatan. Inkludera koden som utför dessa funktioner på webbsidan. Dessutom är det svårt att dela kod mellan webbsidor som kräver samma beteende. klasskomplexet, svårt att underhålla och svårt att testa.
  2. UI Layer, UI Logic, Presentation Logic, Business Logic är tätt kopplade.
  3. Presentationsskiktet tar hand om att integrera moduler eller användningsfall.
Lösning:
  1. Välj ett bästa presentationslagermönster för att separera UI-lagret, UI-logik och presentationslogik och affärslogik som separata lager för att göra koden lättare att förstå och underhålla.
  2. Aktivera lös koppling vid utveckling av moduler eller andra användningsfall.
  3. Maximera koden som kan testas med automatisering. (Visningar är svåra att testa.)
  4. Dela kod mellan sidor som kräver samma beteende.
  5. Dela upp ansvaret för den visuella displayen och händelsehanteringsbeteendet i olika klasser som heter vyn respektive presentatören eller styrenheten eller ViewModel.
Fördelar med att använda presentationsmönster:
  1. Modularitet
  2. Testdrivet tillvägagångssätt – maximera koden som kan testas med automatisering
  3. Dela upp problemen
  4. Koddelning mellan sidor och formulär
  5. Lätt att underhålla

Vilka är tillgängliga presentationslagermönster?

MVC (Model View Controller)

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

MVVM (Model View ViewModel)

MVC vs MVP vs MVVM:
  1. Modell och vy representerar samma i alla ovanstående 3 mönster?

    Ja

  2. Controller, Presenter och ViewModel är syftet samma i alla ovanstående 3 mönster?

    Ja

  3. Kommunikation och flöde av Model, View med Controller, Presenter och ViewModel är samma?

    Nej, det är anledningen till att dessa 3 mönster finns.

  4. Ersätter dessa mönster PL (Presentation Layer), BLL (Business Logic Layer) och DAL (Data Access Layer)

    Nej, dessa mönster är till för att separera UI och UI Logic från Presentation Logic och möjliggör den lösa kopplingen.

Välj det bästa presentationslagermönstret:

MVP

  1. Bindning via en datakontext är inte möjlig
  2. Komplex UI-design
  3. Bäst för Windows Forms, ASP.NET Web Forms & Sharepoint Applications

MVC

  1. Bäst för ASP.NET med Simple UI
  2. Frånkopplad modell (Visa separation från alla andra lager)

Notera: Här fokuserar jag inte på MVC VM (MVC ViewModel från MVC3) och ASP.NET MVVM med Dependency Injection.

MVVM

  1. Bindning via en datakontext är möjlig
  2. Ansluten modell
  3. Bäst för WPF- och Silverlight-applikationer
ASP.NET Web Forms vs ASP.NET MVC:

ASP.NET webbformulär

  1. RAD
  2. Enklare utveckling
  3. Rik styr ekosystemet
  4. Bekant som utvecklingssättet för Windows Forms-utveckling
  5. Nej ViewState& Inget stöd för postback

ASP.NET MVC

  1. Clean Separation of Concern (SoC)
  2. Full uppmärkningskontroll
  3. Aktivera TDD (Testdriven Development)
  4. Aktivera och gör enkelt REST
  5. Enklare integration på klientsidan (Javascript)
  6. Multi View Engine (det här är riktigt coolt!)
  7. Inget ViewState & Inget stöd för postback
  8. Utökningsbar och WEB 2.0-aktiverad

Modell, vyer och styrenhet

  • Modell: Modellobjekt är de delar av applikationen som implementerar logiken för applikationens datadomän. Ofta hämtar och lagrar modellobjekt modelltillstånd i en databas. Till exempel kan ett produktobjekt hämta information från en databas, arbeta på den och sedan skriva uppdaterad information tillbaka till en produkttabell i SQL Server.
  • Vyer: Vyer är de komponenter som visar programmets användargränssnitt (UI). Vanligtvis skapas detta användargränssnitt från modelldata. Ett exempel skulle vara en redigeringsvy av en produkttabell som visar textrutor, rullgardinslistor och kryssrutor baserat på det aktuella tillståndet för ett produktobjekt.
  • Controller: Controllers är de komponenter som hanterar användarinteraktion, arbetar med modellen och i slutändan väljer en vy att rendera som visar UI. I en MVC-applikation visar vyn bara information; regulatorn hanterar och reagerar på användarinput och interaktion. Till exempel hanterar styrenheten frågesträngsvärden och skickar dessa värden till modellen, som i sin tur frågar databasen genom att använda värdena.
ASP.NET MVC högnivå sidlivscykel?
ASP.NET MVC Lågnivå Sidlivscykel?

MVC2.0 Nya funktioner

1 mall för hjälpare:

Templated Helpers hjälper oss att automatiskt associera HTML-element för redigering och visning med datatyper.

T.ex. när data av typen System.DateTimevisas i en vy, kan ett datepicker UI-element renderas automatiskt.

Detta liknar hur fältmallar fungerar i ASP.NET Dynamic Data.

2 områden:

Använda områden Vi kan organisera ett stort projekt i flera mindre sektioner för att hantera komplexiteten i en stor webbapplikation.

Varje sektion ("område") representerar vanligtvis en separat sektion av en stor webbplats och används för att gruppera relaterade uppsättningar av kontroller och vyer.

T.ex

Areas
    Admin
    Controllers
    Models
    Views
    Iniala Claims
    Controllers
    Models
    Views
3 Stöd för asynkrona styrenheter:

ASP.NET MVC2 tillåter styrenheter att behandla förfrågningar asynkront.

Detta kan leda till prestandaförbättringar genom att tillåta servrar som ofta anropar blockeringsoperationer (som nätverksförfrågningar) att istället ringa icke-blockerande motparter.

4 Stöd för DefaultValueAttributein Action-Method-parametrar:

Klassen System.ComponentModel.DefaultValueAttributetillåter att ett standardvärde anges för argumentparametern till en åtgärdsmetod.

Anta till exempel att följande standardrutt är definierad:

{controller}/{action}/{id}

Anta också att följande styrenhet och åtgärdsmetod är definierad:

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

Någon av följande webbadresser för begäran anropar åtgärdsmetoden Visa som definieras i föregående exempel.

  • /Artikel/Visa/123
  • /Article/View/123?page=1 (Faktiskt samma som föregående begäran)
  • /Artikel/Visa/123?page=2
5 Stöd för bindning av binära data med modellbindare:

Det finns två nya överbelastningar av Html.Hiddenhjälparen som kodar binära värden som bas-64-kodade strängar:

public static string Hidden(this HtmlHelper htmlHelper, string name, Binary value);
public static string Hidden(this HtmlHelper htmlHelper, string name, byte[] value);
6 Stöd för DataAnnotationsattribut:

Använda RangeAttribute, RequiredAttribute, StringLengthAttribute, och RegexAttributevalideringsattribut (definierade i System.ComponentModel.DataAnnotationsnamnområdet) när vi binder till en modell för att tillhandahålla indatavalidering.

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 modellvalideringsleverantörer:

Klassen modellvalideringsleverantör representerar en abstraktion som tillhandahåller valideringslogik för modellen.

ASP.NET MVC inkluderar en standardleverantör baserad på valideringsattribut som ingår i System.ComponentModel.DataAnnotationsnamnområdet.

8 Verifiering på klientsidan:

Modellvalideringsleverantörsklassen exponerar valideringsmetadata för webbläsaren i form av JSON-serialiserad data som kan konsumeras av ett valideringsbibliotek på klientsidan.

ASP.NET MVC 2 innehåller ett klientvalideringsbibliotek och en adapter som stöder de DataAnnotationsnamnområdesvalideringsattribut som noterats tidigare.

9 Nytt RequireHttpsAttributeåtgärdsfilter:

ASP.NET MVC 2 innehåller en ny RequireHttpsAttributeklass som kan appliceras på åtgärdsmetoder och kontroller.

Som standard omdirigerar filtret en icke-SSL (HTTP) begäran till den SSL-aktiverade (HTTPS) motsvarigheten.

10 Åsidosätt HTTP-metodens verb:

När vi bygger en webbplats med hjälp av REST-arkitektonisk stil, används HTTP-verb för att bestämma vilken åtgärd som ska utföras för en resurs.

REST kräver att applikationer stöder alla vanliga HTTP-verb, inklusive GET, PUT, POST, och DELETE.

ASP.NET MVC 2 innehåller nya attribut som vi kan tillämpa på åtgärdsmetoder och som har kompakt syntax.

Dessa attribut gör det möjligt för ASP.NET MVC att välja en åtgärdsmetod baserat på HTTP-verbet.

Till exempel kommer en POSTbegäran att anropa den första åtgärdsmetoden och en PUTbegäran kommer att anropa den andra åtgärdsmetoden.

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

I tidigare versioner av ASP.NET MVC krävde dessa åtgärdsmetoder mer utförlig syntax, som visas i följande exempel:

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

Eftersom webbläsare endast stöder verben GEToch POSTHTTP, är det inte möjligt att skicka till en åtgärd som kräver ett annat verb. Det är alltså inte möjligt att stödja alla RESTfulförfrågningar.

Men för att stödja RESTfulförfrågningar under POSTdrift, introducerar ASP.NET MVC 2 en ny HttpMethodOverrideHTML-hjälparmetod.

Den här metoden återger ett dolt inmatningselement som gör att formuläret effektivt emulerar vilken HTTP-metod som helst.

Till exempel, genom att använda HttpMethodOverrideHTML-hjälpmetoden kan vi få en formulärinlämning att visas som en PUTeller DELETEbegäran.

Beteendet hos HttpMethodOverridepåverkar följande attribut:

  • HttpPostAttribute
  • HttpPutAttribute
  • HttpGetAttribute
  • HttpDeleteAttribute
  • AcceptVerbsAttribute
11 ny HiddenInputAttributeklass för mallhjälpare:

Vi kan tillämpa det nya HiddenInputAttributeattributet på en modellegenskap för att indikera om ett dolt indataelement ska renderas när modellen visas i en editormall (Attributet sätter ett implicit UIHintvärde på HiddenInput).

Attributets DisplayValueegenskap låter oss ange om värdet ska visas i redigerings- och visningslägen.

När DisplayValueär inställt på false visas ingenting, inte ens HTML-uppmärkningen som normalt omger ett fält.

Standardvärdet för DisplayValueär sant.

Vi kan använda HiddenInputAttributeattribut i följande scenarier:

  • När en vy låter användare redigera ett objekts ID och det är nödvändigt att visa värdet samt att tillhandahålla ett dolt inmatningselement som innehåller det gamla ID:t så att det kan skickas tillbaka till kontrollenheten.
  • När en vy låter användare redigera en binär egenskap som aldrig ska visas, till exempel en tidsstämpel.

I så fall visas inte värdet och den omgivande HTML-uppmärkningen (som etiketten och värdet).

T.ex:

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.ValidationSummaryhjälpmetoder kan visa fel på modellnivå:

Istället för att alltid visa alla valideringsfel har Html.ValidationSummaryhjälpmetoden ett nytt alternativ att endast visa fel på modellnivå.

Detta gör att fel på modellnivå kan visas i valideringssammanfattningen och fältspecifika fel kan visas bredvid varje fält.

13 T4-mallar i Visual Studio Generera kod som är specifik för målversionen av .NET Framework:

En ny egenskap är tillgänglig för T4-filer från ASP.NET MVC T4-värden som anger versionen av .NET Framework som används av programmet.

Detta gör det möjligt för T4-mallar att generera kod och uppmärkning som är specifik för en version av .NET Framework.

I Visual Studio 2008 är värdet alltid .NET 3.5. I Visual Studio 2010 är värdet antingen .NET 3.5 eller .NET4.

14 API-förbättringar:

Lade till en skyddad virtuell CreateActionInvokermetod i klassen Controller.

Den här metoden anropas av ActionInvokerControllers egendom och möjliggör lat instansiering av anroparen om ingen anropare redan är inställd.

Inspelningskälla: instantshift.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More