ASP.NET MVC - BAD PRACTICES                               Radu Vunvulea                    vunvulearadu.blogspot.com
Radu VunvuleaMail: vunvulear@gmail.comBlog: vunvulearadu.blogspot.com/
Agenda•   ASP.NET MVC Introduction•   Why “BAD PRACTICES”•   Some bad practices•   More bad practices•   And more bad prac...
MVC - Model View Controller             ModelController           View
De ce “BAD PRACTICES”?
De ce “BAD PRACTICES”?           2 km
De ce “BAD PRACTICES”?           20 km
De ce “BAD PRACTICES”?           900 km
View Model = Domain modelRepository          View       Domain Model
View Model = Domain model•   In view o sa ajunga mai multe date decat este necesar•   Entitatea o sa fie poluata cu diferi...
View Model = Domain model
View-ul contine logica
View-ul contine logica•   In view modelul este procesat•   Modelul nu contine date in stare finala•   View-ul ar trebui do...
Controller si dependintele exterioare
Controller si dependintele exterioare•   Controller-ul nu ar trebui sa acceseze direct HttpContext, baza de    date sau or...
Controller si dependintele exterioare
Controller si dependintele exterioare
Nu folositi “magic words”
Nu folositi “magic words”•   Cand se acceseaza sesiunea, ViewData, ViewBag, etc•   Pot sa apara foarte usor greseli de scr...
Nu folositi “magic words”
Nu hardcodati RouteUrl-urile•   Evitati sa folosti Html.ActionLink in view•   Evitati sa folosti RedirectToAction in contr...
Repopulare date comune in Model• 2 sau mai multe modele contin aceleasi date• Creati o structura de clase  (BaseUserModel,...
Repopulare date comune in Model• 2 sau mai multe modele contin aceleasi date• Creati o structura de clase (BaseUserModel, ...
Agregare date pentru o actiune• Daca avem nevoie de acelasi ActionFilter in mai multe actiuni, atunci  incercati sa le pun...
Fat Controller•   Apeleaza direct baza de date•   Proceseaza informatia•   Logica din el este foarte complexa – toata part...
Fat Controller• Un controller per functionalitate si nu per entitate• Fiecare functionalitate care este oferita de catre a...
Actiunile apelate des nu sunt cache-uite• Daca avem actiuni care sunt apelate des, iar continutul ramane la  fel, atunci p...
Framework-ul de DI este apelat direct• In anumite factory-uri (ControllerFactory) se apeleaza direct clase care  tin de fr...
HtmlHelper - overused• Nu creati un extension method la un HtmlHelper daca nu este folosit  cel putin in doua locuri• Ince...
JavaScript in View• Oricat de scurt este JavaScript-ul nu il puneti in view• JavaScript-ul o sa polueze view-ul si o sa il...
View-uri foarte lungi• Cat de normal este sa ai un view de 100 de randuri, iar codul sa se  repete?• Cat de normal este ca...
Q&A
vunvulear@gmail.comvunvulearadu.blogspot.com/
Upcoming SlideShare
Loading in …5
×

Asp.net mvc bad practices

1,211 views
1,162 views

Published on

An overview over the most common bad practices in ASP.NET MVC 3. In this session we will discuss about some mistakes that are made in an ASP.NET MVC 3 applications and what we can do to avoid them.

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,211
On SlideShare
0
From Embeds
0
Number of Embeds
290
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Asp.net mvc bad practices

  1. 1. ASP.NET MVC - BAD PRACTICES Radu Vunvulea vunvulearadu.blogspot.com
  2. 2. Radu VunvuleaMail: vunvulear@gmail.comBlog: vunvulearadu.blogspot.com/
  3. 3. Agenda• ASP.NET MVC Introduction• Why “BAD PRACTICES”• Some bad practices• More bad practices• And more bad practices• Q&A• Bibliography
  4. 4. MVC - Model View Controller ModelController View
  5. 5. De ce “BAD PRACTICES”?
  6. 6. De ce “BAD PRACTICES”? 2 km
  7. 7. De ce “BAD PRACTICES”? 20 km
  8. 8. De ce “BAD PRACTICES”? 900 km
  9. 9. View Model = Domain modelRepository View Domain Model
  10. 10. View Model = Domain model• In view o sa ajunga mai multe date decat este necesar• Entitatea o sa fie poluata cu diferite atribute ce tin de UI• Nu exista o separare clara a fiecarui layer• Modelul este un DTO (Data Transfer Object) si ar putea sa fie compus doar din string-uri• Un convertor se poate folosi pentru a obtine un model dintr-o entitate (intr-un sens, in doua sensuri)• Un framework pentru maparea entitatilor (AutoMapper)• Codul care face conversia nu se duplica• Controller-ul nu creste ca si complexitate din cauza conversiei
  11. 11. View Model = Domain model
  12. 12. View-ul contine logica
  13. 13. View-ul contine logica• In view modelul este procesat• Modelul nu contine date in stare finala• View-ul ar trebui doar sa afiseze modelul• Logica de procesare nu are ce cauta in view• Din view nu se apeleaza clase exterioare• Un view poate sa contina IF si FOR (FOREACH)• SWITCH – chiar avem nevoie de el?• Daca populam modelul corect, IF-ul poate sa fie inlocuit cu un HtmlHelper
  14. 14. Controller si dependintele exterioare
  15. 15. Controller si dependintele exterioare• Controller-ul nu ar trebui sa acceseze direct HttpContext, baza de date sau orice alta resursa• Setarile din web.config nu trebuie accesate direct• Este mai greu de testat• Nu este flexibil• Orice schimbare poate sa genereze foarte multe modificari• Se poate construi un wrapper peste aceste dependinte• Wrapperul poate sa grupeze datele din punct de vedere logic si nu in functie de sursa lor• ActionFilter care sa ne ofere aceste date
  16. 16. Controller si dependintele exterioare
  17. 17. Controller si dependintele exterioare
  18. 18. Nu folositi “magic words”
  19. 19. Nu folositi “magic words”• Cand se acceseaza sesiunea, ViewData, ViewBag, etc• Pot sa apara foarte usor greseli de scriere (misspelling)• Duplicarea informatiei – aceiasi informatie in mai multe locuri• Aceiasi conversie de date se face in mai multe locuri• Nu o sa stiti cauza pentru care view-ul crapa (misspelling sau datele nu au fost puse unde trebuie)• Wrapper• Extension methods• Datele de care avem nevoie in view se pot trimite prin model si nu prin alte mecanisme
  20. 20. Nu folositi “magic words”
  21. 21. Nu hardcodati RouteUrl-urile• Evitati sa folosti Html.ActionLink in view• Evitati sa folosti RedirectToAction in controller• Puteti crea extension methods pentru fiecare url• Le puteti refolosi in mai multe locatii (atat in view cat si in controller)• Creati extension methods si pentru locatiile la resurse (image path, JavaScript path, CSS files path)
  22. 22. Repopulare date comune in Model• 2 sau mai multe modele contin aceleasi date• Creati o structura de clase (BaseUserModel, CustomerUserModel, AdminUserModel)• Populati modelul de baza dintr-un singur loc
  23. 23. Repopulare date comune in Model• 2 sau mai multe modele contin aceleasi date• Creati o structura de clase (BaseUserModel, CustomerUserModel, AdminUserModel)• Populati modelul de baza dintr-un singur loc ?
  24. 24. Agregare date pentru o actiune• Daca avem nevoie de acelasi ActionFilter in mai multe actiuni, atunci incercati sa le puneti intr-un sigur loc (intr-un BaseController)• Folositi ActionFilter pentru a transforma datele care vin din diferite locatii in parametri pentru actiune
  25. 25. Fat Controller• Apeleaza direct baza de date• Proceseaza informatia• Logica din el este foarte complexa – toata partea fun este in controller• Are foarte multe actiuni• Multe entitati sunt cuplate prin intermediul controller-ului• Greu de inteles, modificat si testat• Controller-ul nu trebuie sa fie strans legat de domeniu• Nu el trebuie sa fie dirijorul aplicatiei noastre• Un controller per functionalitate si nu per entitate
  26. 26. Fat Controller• Un controller per functionalitate si nu per entitate• Fiecare functionalitate care este oferita de catre aplicatia noastra poate sa fie reprezentata de catre un controller• Un controller per use case – nu este mereu posibil
  27. 27. Actiunile apelate des nu sunt cache-uite• Daca avem actiuni care sunt apelate des, iar continutul ramane la fel, atunci putem sa folosim OutputCache• Nu poluati controller-ul cu configurarea cache-ului• Cache-ul trebuie configurat din web.config si nu din controller
  28. 28. Framework-ul de DI este apelat direct• In anumite factory-uri (ControllerFactory) se apeleaza direct clase care tin de framework-ul de DI• Diferite proiecte folosesc diferite DI• Creati un wrapper peste acestea, care sa abstractizeze API-ul• Folositi Common Service Locator • Este o abstractizare peste mecanismul de DI, care iti permite sa folosesti acelasi API indiferent de ce framework de DI folosesti
  29. 29. HtmlHelper - overused• Nu creati un extension method la un HtmlHelper daca nu este folosit cel putin in doua locuri• Incercati sa grupati aceste metode sub un nod comun daca se poate • O sa fie mai usor de folosit si de inteles HtmlHelper .Table() .BoxList() .Pivot .Product() – returneaza ProductHtmlHelper .FormatPrice() .Stock() … …
  30. 30. JavaScript in View• Oricat de scurt este JavaScript-ul nu il puneti in view• JavaScript-ul o sa polueze view-ul si o sa il faca greu de inteles• Nu faceti apeluri AJAX din View• Nu hardcodati adresa url pentru AJAX in JS – use UrlHelper • Ce se intampla daca o actiune se redenumeste ? • Ce se intampla daca locatia unei resurse se schimba? • Trebuie facute in mai multe locuri modificari
  31. 31. View-uri foarte lungi• Cat de normal este sa ai un view de 100 de randuri, iar codul sa se repete?• Cat de normal este ca intr-un FOR dintr-un view sa se afiseze contintul unui “sub-model” direct?• Pentru aceste cazuri se poate folosi Partial View• Nu conteaza daca acesta are doar 2 randuri sau 10 • Reutilizarea codului creste • Devine mai clar • Mai usor de citit si testat
  32. 32. Q&A
  33. 33. vunvulear@gmail.comvunvulearadu.blogspot.com/

×