Modele de design – Exemple de modele MVC pentru începători

Publicat: 2016-04-15

Acesta explică ce este MVC Pattern și ce este ASP.NET MVC Framework cum funcționează. De asemenea, explică ciclul de viață al paginii ASP.NET MVC și caracteristicile ASP.NET MVC în funcție de versiune.

Exemplele au furnizat pași înțelepți pentru a ajuta începătorii să înțeleagă cu ușurință și să devină competenți în ASP.NET MVC.

După cum știm cu toții multe modele de design și le folosim în implementarea componentelor și serviciilor de afaceri în aplicațiile noastre, dar totuși ne vom confrunta cu probleme/provocări cu aplicațiile noastre. De asemenea, zi de zi nevoile și prioritățile de afaceri se vor schimba. Dacă observăm îndeaproape o serie de probleme, defecte și provocări cu care ne confruntăm este în UI și straturile de prezentare. Deși unele defecte sunt legate de logica de afaceri și de regulile de afaceri, este posibil să fie nevoie să le remediem în straturile de UI și de prezentare, deoarece am putea integra strâns logica de afaceri în UI și nivelurile de prezentare. Motivul din spatele acestui lucru este că nu ne-am concentrat pe implementarea modelului corect de design în aplicațiile noastre. Să parcurgem pas cu pas și să înțelegem cum să implementăm și să folosim modelul de prezentare în aplicațiile noastre.

Declarație problemă:
  1. Folosind deja modele diferite în aplicare, dar menținerea aplicării este dificilă.
  2. Utilizarea VS Test, NUnit, MBUnit etc pentru a testa stratul logic de afaceri, dar există totuși unele defecte în aplicație ca logica de afaceri implicată în stratul de prezentare.
  3. Folosit Stratul de prezentare, Stratul de logică de afaceri, Stratul de acces la date în aplicație, dar uneori trebuie să scrie cod redundant în stratul de prezentare pentru a consuma sau a apela alte module sau alte cazuri de utilizare.
  4. Defecte de integrare sunt injectate atunci când facem unele modificări în modulele integrate.
  5. Remedierea defectelor și îmbunătățirile necesită mai mult timp pentru a analiza logica nivelului de prezentare și dependențele sale de integrare și provoacă deschiderea de noi defecte.
  6. ASP.NET MVC nu poate fi ales deoarece UI este complex de construit.
Cauza principală a problemei:

În stratul Prezentare,

  1. O pagină sau un formular conține controale care afișează datele domeniului aplicației. Un utilizator poate modifica datele și poate trimite modificările. Pagina preia datele de domeniu, gestionează evenimentele utilizatorului, modifică alte controale de pe pagină ca răspuns la evenimente și trimite datele de domeniu modificate. Includerea codului care îndeplinește aceste funcții în pagina Web În plus, este dificil să partajați codul între paginile Web care necesită același comportament. complexul clasei, greu de întreținut și greu de testat.
  2. UI Layer, UI Logic, Presentation Logic, Business Logic sunt strâns cuplate.
  3. Stratul de prezentare se ocupă de integrarea modulelor sau a cazurilor de utilizare.
Soluţie:
  1. Alegeți cel mai bun model de strat de prezentare pentru a separa stratul UI, logica UI și logica prezentării și logica de afaceri ca straturi separate pentru a face codul mai ușor de înțeles și de întreținut.
  2. Activați cuplarea liberă în timpul dezvoltării modulelor sau a oricăror cazuri de utilizare.
  3. Maximizați codul care poate fi testat cu automatizare. (Vizualizările sunt greu de testat.)
  4. Partajați codul între paginile care necesită același comportament.
  5. Separați responsabilitățile pentru afișarea vizuală și comportamentul de gestionare a evenimentelor în diferite clase numite, respectiv, vizualizare și prezentator sau controlor sau ViewModel.
Beneficiile utilizării modelului de prezentare:
  1. Modularitate
  2. Abordare bazată pe testare – maximizați codul care poate fi testat cu automatizare
  3. Separarea preocupărilor
  4. Partajarea codului între pagini și formulare
  5. Usor de intretinut

Care sunt modelele de strat de prezentare disponibile?

MVC (model View controller)

MVP (Model View Prezentator) sau (Model Passive View, Supervisor Controller)

MVVM (Model View ViewModel)

MVC vs MVP vs MVVM:

  1. Model și View reprezintă același lucru în toate cele 3 modele de mai sus?

    da

  2. Scopul controlerului, prezentatorului și modelului de vizualizare este același în toate cele 3 modele de mai sus?

    da

  3. Comunicarea și fluxul de model, vizualizare cu controler, prezentator și model de vizualizare sunt aceleași?

    Nu , acesta este motivul pentru care există aceste 3 modele.

  4. Aceste modele înlocuiesc PL (Presentation Layer), BLL (Business Logic Layer) și DAL (Data Access Layer)

    Nu , aceste modele sunt pentru a separa UI și UI Logic de Presentation Logic și permit cuplarea liberă.

Alegeți cel mai bun model de strat de prezentare:

MVP

  1. Legarea printr-un context de date nu este posibilă
  2. Design UI complex
  3. Cel mai bun pentru Windows Forms, ASP.NET Web Forms și aplicații Sharepoint

MVC

  1. Cel mai bun pentru ASP.NET cu UI simplă
  2. Model deconectat (Vedeți separarea de toate celelalte straturi)

Notă: Aici nu mă concentrez pe MVC VM (MVC ViewModel din MVC3) și ASP.NET MVVM cu Dependency Injection.

MVVM

  1. Este posibilă legarea printr-un context de date
  2. Model conectat
  3. Cel mai bun pentru aplicațiile WPF și Silverlight
ASP.NET Web Forms vs ASP.NET MVC:

Formulare Web ASP.NET

  1. RAD
  2. Dezvoltare mai ușoară
  3. Bogatul controlează ecosistemul
  4. Familiar ca abordarea de dezvoltare a dezvoltării Windows Forms
  5. Fără ViewState și fără suport pentru postback

ASP.NET MVC

  1. Separarea curată a preocupărilor (SoC)
  2. Control complet al marcajului
  3. Activați TDD (dezvoltare bazată pe teste)
  4. Activați și faceți cu ușurință REST
  5. Integrare mai ușoară pe partea clientului (Javascript)
  6. Multi View Engine (acesta este foarte tare!)
  7. Fără ViewState și fără suport pentru postback
  8. Extensibil și WEB 2.0 activat

Model, vizualizări și controler

  • Model : obiectele model sunt părțile aplicației care implementează logica pentru domeniul de date al aplicației. Adesea, obiectele model preiau și stochează starea modelului într-o bază de date. De exemplu, un obiect Product poate prelua informații dintr-o bază de date, poate opera pe aceasta și apoi scrie informații actualizate înapoi într-un tabel Products din SQL Server.
  • Vizualizări : Vizualizările sunt componentele care afișează interfața cu utilizatorul (UI) a aplicației. De obicei, această interfață de utilizare este creată din datele modelului. Un exemplu ar fi o vizualizare de editare a unui tabel Produse care afișează casete de text, liste derulante și casete de selectare bazate pe starea curentă a unui obiect Produse.
  • Controler : Controlerele sunt componentele care se ocupă de interacțiunea utilizatorului, lucrează cu modelul și, în cele din urmă, selectează o vizualizare pentru a reda care afișează interfața de utilizare. Într-o aplicație MVC, vizualizarea afișează doar informații; controlerul gestionează și răspunde la intrarea și interacțiunea utilizatorului. De exemplu, controlerul gestionează valorile șirului de interogări și transmite aceste valori modelului, care, la rândul său, interogează baza de date utilizând valorile.
Ciclul de viață al paginii de nivel înalt ASP.NET MVC?

ASP.NET MVC High Level Page Life Cycle

Ciclul de viață al paginii de nivel scăzut ASP.NET MVC?

ASP.NET MVC Low Level Page Life Cycle

MVC2.0 Caracteristici noi

1. Ajutoare modelate:

Templated Helpers ne ajută să asociem automat elemente HTML pentru editare și afișare cu tipuri de date.

De exemplu, atunci când datele de tip System.DateTime sunt afișate într-o vizualizare, un element de interfață de selectare a datei poate fi redat automat.

Acest lucru este similar cu modul în care șabloanele de câmp funcționează în ASP.NET Dynamic Data.

2. Domenii:

Utilizarea zonelor Putem organiza un proiect mare în mai multe secțiuni mai mici pentru a gestiona complexitatea unei aplicații Web mari.

Fiecare secțiune („zonă”) reprezintă de obicei o secțiune separată a unui site Web mare și este utilizată pentru a grupa seturi de controlere și vizualizări înrudite.

De exemplu

[xhtml]
Zone
Admin
Controlori
Modele
Vizualizări
Iniala Revendicari
Controlori
Modele
Vizualizări
[/xhtml]

3. Suport pentru controlere asincrone:

ASP.NET MVC2 permite controlorilor să proceseze cererile în mod asincron.

Acest lucru poate duce la câștiguri de performanță, permițând serverelor care frecvent operațiuni de blocare a apelurilor (cum ar fi solicitările de rețea) să apeleze în schimb omologii care nu blochează.

4. Suport pentru DefaultValueAttribute în parametrii metodei de acțiune:

Clasa System.ComponentModel.DefaultValueAttribute permite furnizarea unei valori implicite pentru parametrul argument unei metode de acțiune.

De exemplu, să presupunem că este definită următoarea rută implicită:

[cod]
{controller}/{acțiune}/{id}
[/cod]

De asemenea, presupunem că următorul controler și metoda de acțiune sunt definite:

[cod]
Public class ArticleController
{
public ActionResult View(int id, [DefaultValue(1)]int pagina)
{
}
}
[/cod]

Oricare dintre următoarele adrese URL de solicitare va invoca metoda de acțiune View care este definită în exemplul precedent.

  • /Articol/Vizualizare/123
  • /Article/View/123?page=1 (Efectiv la fel ca solicitarea anterioară)
  • /Article/View/123?page=2
5. Suport pentru legarea datelor binare cu modele de legare:

Există două supraîncărcări noi ale ajutorului Html.Hidden care codifică valori binare ca șiruri codificate în bază 64:

[cod]
public static șir Ascuns (acest HtmlHelper htmlHelper, nume șir, valoare binară);
public static șir Ascuns (acest HtmlHelper htmlHelper, nume șir, byte[] valoare);
[/cod]

6. Suport pentru atributele DataAnnotations :

Folosind atributele de validare RangeAttribute , RequiredAttribute , StringLengthAttribute și RegexAttribute (definite în spațiul de nume System.ComponentModel.DataAnnotations ) atunci când ne legăm la un model pentru a furniza validarea intrării.

[cod]
folosind System.ComponentModel.DataAnnotations;
spațiu de nume MvcTmpHlprs
{
[MetadataType(typeof(ProductMD))]
Clasa parțială publică Produs
{
Public class ProductMD
{
obiect public SellStartDate { get; a stabilit; }
[UIHint("rbDate")]
obiect public SellEndDate { get; a stabilit; }
[DataType(DataType.Date)]
obiect public DiscontinuedDate { get; a stabilit; }
[ScaffoldColumn(fals)]
obiect public ModifiedDate { get; a stabilit; }
[ScaffoldColumn(fals)]
obiect public rowguid { get; a stabilit; }
[ScaffoldColumn(fals)]
obiect public ThumbnailPhotoFileName { get; a stabilit; }
}
}
}
[/cod]

7. Furnizori de validatori de model:

Clasa furnizorului de validare a modelului reprezintă o abstractizare care oferă logica de validare a modelului.

ASP.NET MVC include un furnizor implicit bazat pe atributele de validare care sunt incluse în spațiul de nume System.ComponentModel.DataAnnotations .

8. Validare la nivelul clientului:

Clasa de furnizor de validator de model expune metadatele de validare către browser sub formă de date seriale JSON care pot fi consumate de o bibliotecă de validare la nivelul clientului.

ASP.NET MVC 2 include o bibliotecă de validare a clientului și un adaptor care acceptă atributele de validare a spațiului de nume DataAnnotations menționate mai devreme.

9. Noul filtru de acțiune RequireHttpsAttribute :

ASP.NET MVC 2 include o nouă clasă RequireHttpsAttribute care poate fi aplicată metodelor de acțiune și controlerelor.

În mod implicit, filtrul redirecționează o solicitare non-SSL (HTTP) către echivalentul SSL activat (HTTPS).

10. Suprascrierea verbului metodei HTTP:

Când construim un site web utilizând stilul arhitectural REST, verbele HTTP sunt folosite pentru a determina ce acțiune trebuie efectuată pentru o resursă.

REST necesită ca aplicațiile să accepte întreaga gamă de verbe HTTP comune, inclusiv GET , PUT , POST și DELETE .

ASP.NET MVC 2 include noi atribute pe care le putem aplica metodelor de acțiune și care au o sintaxă compactă.

Aceste atribute permit ASP.NET MVC să selecteze o metodă de acțiune bazată pe verbul HTTP.

De exemplu, o solicitare POST va apela prima metodă de acțiune, iar o solicitare PUT va apela a doua metodă de acțiune.

[cod]
[HttpPost]
Public ActionResult Edit(int id)

[HttpPut]
Public ActionResult Edit(int id, tag tag)
[/cod]

În versiunile anterioare ale ASP.NET MVC, aceste metode de acțiune necesitau o sintaxă mai detaliată, așa cum se arată în următorul exemplu:

[cod]
[AcceptVerbs(HttpVerbs.Post)]
Public ActionResult Edit(int id)

[AcceptVerbs(HttpVerbs.Put)]
Public ActionResult Edit(int id, tag tag)
[/cod]

Deoarece browserele acceptă numai verbele HTTP GET și POST , nu este posibil să postezi la o acțiune care necesită un verb diferit. Astfel, nu este posibil să se suporte nativ toate solicitările RESTful .

Cu toate acestea, pentru a accepta cererile RESTful în timpul operațiunilor POST , ASP.NET MVC 2 introduce o nouă metodă de ajutor HTML HttpMethodOverride .

Această metodă redă un element de intrare ascuns care face ca formularul să emuleze eficient orice metodă HTTP.

De exemplu, prin utilizarea metodei de ajutor HTML HttpMethodOverride , putem face ca trimiterea unui formular să apară fie o solicitare PUT sau DELETE .

Comportamentul HttpMethodOverride afectează următoarele atribute:

  • HttpPostAttribute
  • HttpPutAttribute
  • HttpGetAttribute
  • HttpDeleteAttribute
  • AcceptVerbsAttribute
11. Noua clasă HiddenInputAttribute pentru ajutoare cu șablon:

Putem aplica noul atribut HiddenInputAttribute unei proprietăți de model pentru a indica dacă un element de intrare ascuns trebuie randat atunci când se afișează modelul într-un șablon de editor (Atributul setează o valoare UIHint implicită a HiddenInput ).

Proprietatea DisplayValue a atributului ne permite să specificăm dacă valoarea este afișată în modurile editor și afișare.

Când DisplayValue este setat la false, nu este afișat nimic, nici măcar marcajul HTML care înconjoară în mod normal un câmp.

Valoarea implicită pentru DisplayValue este adevărată.

Am putea folosi atributul HiddenInputAttribute în următoarele scenarii:

  • Când o vizualizare permite utilizatorilor să editeze ID-ul unui obiect și este necesar să se afișeze valoarea, precum și să furnizeze un element de intrare ascuns care conține vechiul ID, astfel încât acesta să poată fi transmis înapoi controlerului.
  • Când o vizualizare permite utilizatorilor să editeze o proprietate binară care nu ar trebui să fie afișată niciodată, cum ar fi o proprietate de marcaj temporal.

În acest caz, valoarea și marcajul HTML din jur (cum ar fi eticheta și valoarea) nu sunt afișate.

De exemplu:

[cod]
clasa publică ProductViewModel
{
[HiddenInput] // echivalent cu [HiddenInput(DisplayValue=true)]
public int Id { get; a stabilit; }

public string Nume { get; a stabilit; }

[HiddenInput(DisplayValue=false)]
octet public[] TimeStamp { get; a stabilit; }
}
[/cod]

12. Metoda de ajutor Html.ValidationSummary poate afișa erori la nivel de model:

În loc să afișeze întotdeauna toate erorile de validare, metoda de ajutor Html.ValidationSummary are o nouă opțiune pentru a afișa numai erorile la nivel de model.

Acest lucru permite ca erorile la nivel de model să fie afișate în rezumatul de validare și erorile specifice câmpului să fie afișate lângă fiecare câmp.

13. Șabloanele T4 din Visual Studio generează cod specific versiunii țintă a .NET Framework:

O nouă proprietate este disponibilă pentru fișierele T4 de la gazda ASP.NET MVC T4 care specifică versiunea .NET Framework care este utilizată de aplicație.

Acest lucru permite șabloanele T4 să genereze cod și markup care sunt specifice unei versiuni a .NET Framework.

În Visual Studio 2008, valoarea este întotdeauna .NET 3.5. În Visual Studio 2010, valoarea este fie .NET 3.5, fie .NET4.

14. Îmbunătățiri API:

S-a adăugat o metodă virtuală protejată CreateActionInvoker în clasa Controller.

Această metodă este invocată de proprietatea ActionInvoker a Controllerului și permite instanțierea leneșă a invocatorului dacă nu este deja setat niciun invocator.