ASP .NET MVC - best practices
•Download as PPTX, PDF•
1 like•399 views
This document provides 11 best practices for ASP.NET MVC architecture and development. It recommends deleting unused account controller code, isolating controllers from external dependencies, using an inversion of control container, avoiding magic strings, following the POST-REDIRECT-GET pattern, separating domain and view models, not using code behind in views, bundling and minifying scripts/CSS, leveraging areas, caching data, and questions the use of repositories on top of a unit of work. It also outlines common MVC layers including models, data access with repositories, a service layer, and presentation layer.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ASP .NET MVC - best practices
Similar to ASP .NET MVC - best practices (20)
More from Bohdan Pashkovskyi
Recently uploaded
Recently uploaded (20)
ASP .NET MVC - best practices
- 1. ASP.NET MVC - best practices Bohdan Pashkovskyi CoreValue
- 2. What is ASP .NET MVC is? This is .NET developers meetup… You should already know
- 3. Just in case
- 4. Delete “Account Controller” Best practice №1 - You will probably never use these account management pages - Keeping demo code in production application is EVIL - Just delete it!
- 5. Isolate controllers from the external world Best practice №2 - HttpContext - Data Access Classes - Configuration Management - Logging - Etc… Otherwise - It is not testable application - It is not flexible application
- 6. Use an IoC container Best practice №3 - StructureMap - Spring - Unit - Windsor - Ninject - …
- 7. No magic strings Best practice №4 - Never use ViewData[“key”] - Never use Request[“key”] - Always create a ViewModel for each view
- 8. Use PRG pattern Best practice №5 - View sends data in POST - Controller validates (renders the View with errors (POST) or Redirect in GET - View renders the results in GET
- 9. DomainModel != ViewModel Best practice №6 - Domain Model (data + behavior, hierarchical, complex types) - View Model (only data, flat, only strings) - Use AutoMapper
- 10. Do not use code behind in Views Best practice №7 NEVER!!!
- 11. Use Bundling and minifying the script and CSS files Best practice №8 - You should group resources your application needs to use like CSS files into one downloadable resource. This process is also known as bundling. You should also minify the scripts and CSS files you would use to remove the unnecessary characters, comments and white space characters.
- 12. Use Area Best practice №9
- 13. Cache your data Best practice №10 - To improve the performance and responsiveness of your application, you can take advantage of caching. Caching is a technique that enables you to store relatively stale data in the memory so as to reduce the network bandwidth consumption.
- 14. Do not use ASP .NET MVC Best practice №11 - Here is only 10 best practices
- 15. ASP .NET MVC Architecture
- 16. Models
- 17. Data Access Layer and Repositories - The purpose of this layer, is the direct access to the database. It’s the only layer responsible to communicate with the database. If some other layer wants to access the database, then this will be done through some of the classes (repositories) we will define in this project.
- 18. Data Access Layer and Repositories
- 19. Service Layer - What operations do you want to expose your MVC Controllers? Where is the business logic is going to be implemented? Yeap.. you have guessed right, in this very layer.
- 20. Service Layer
- 23. Repository???
- 24. REPOSITORIES ON TOP UNITOFWORK ARE NOT A GOOD IDEA – ROB CONERY - WHY NOT?
- 25. The Rationale - This class can’t exist without the SchoolContext – so what exactly did we decouple here? Nothing. - In this code, from MSDN, what we have is a reimplentation of LINQ, with the classic problem of the “ever-spiraling Repository API”. By “spiraling API” I mean fun things like “GetStudentByEmail, GetStudentByBirthday, GetStudentByOrderNumber” etc. - But that’s not the primary problem here. The primary problem is the Save() routine. It saves a Student… I think. What else does it save? Can you tell?
- 26. The Only Thing You Could Do Worse: Repository <T> - Do You Know Where That DbContext Has Been? - No, you don’t. It’s getting injected and you have no idea which method opened it, nor for what reason. The idea behind Repository is code “reuse” so you’ll probably be calling it from a Registration routine, maybe a new order transaction, or from an API call – who knows? Certainly not your Repository – and this is the main selling point of this pattern!.
- 28. Questions?