Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ASP.NET MVC Solution Best Practices aspConf2012


Published on

Developers choose ASP.NET MVC because it provides for more control over the resulting HTML, better separation of concerns, and better testability. But these benefits are only fully realized if the project and solution is set up properly. Otherwise, it's very possible to create a tightly coupled Big Ball of Mud solution that's difficult to test and change. In this session, we'll create a 'Walking Skeleton' solution of a simple web application using ASP.NET MVC 4 that shows off certain best practices of creating maintainable, loosely coupled solutions.

Published in: Technology

ASP.NET MVC Solution Best Practices aspConf2012

  1. 1. ASP.NET MVC Solution Best Practices or, a Solution to the Solution Problem Steve Smith @ardalis | Telerik, Inc.
  2. 2.
  3. 3. The Problem
  4. 4. Solution Level Pain• Too Many Projects• Too Few Projects• Incorrect Abstraction• The “Goldilocks” Solution – “Just right”
  5. 5. Relevant Principles• Common Closure Principle• Common Reuse Principle• Stable Dependencies Principle• Stable Abstractions Principle• Separation of Concerns• Dependency Inversion Principle
  6. 6. Principles• Common ClosureClasses that change together are packagedtogether.
  7. 7. Principles• Common ReuseClasses that are used together are packagedtogether.
  8. 8. Principles• Stable DependenciesDepend in the direction of stability.
  9. 9. Principles• Stable AbstractionsAbstractness increases with stability. Abstractness Stability
  10. 10. Principles• Separation of ConcernsEstablish boundaries to separate behaviors andresponsibilities within a system.• Dependency InversionDepend on abstractions, not concreteimplementations.
  11. 11. A Simple Guestbook ApplicationDEMO
  12. 12. Testability• Testability correlates with: – Loose coupling – Separation of Concerns – Maintainability• You don’t have to have unit tests to have testable code! – Unit tests prove (or disprove) testability
  13. 13. Adding “Unit” TestsDEMO
  14. 14.
  15. 15. Incremental Improvement• From a Single Project – Separate responsibilities using folders – Add Project(s)• From Many Projects – Create a new Solution with only what you need – Spin off separate applications into own solutions
  16. 16. Separation via Folders (still 1 project)DEMO
  17. 17. Problems• Tests are still not unit tests – Tight coupling – Static Cling – Dependence on Data and Email Infrastructure concerns• Nothing to prevent improper referencing of classes – e.g. UI code can call DAL code directly and bypass business logic• UI Content Folders mixed with Application Code Folders
  18. 18. Onion Architecture• aka Ports and Adapters,• aka Hexagonal Architecture• Core models and interfaces at center• Infrastructure and Implementation depends on Core• UI depends on Core and has access to Infrastructure
  19. 19. Onion Architecture
  20. 20. Introduce Abstractions and Invert Dependencies (in folders)DEMO
  21. 21. Results• Yay! Unit Tests that work!• Boo! Still nothing to prevent improper referencing of classes – e.g. UI code can call DAL code directly and bypass business logic• Boo! Still mixing content and code folders
  22. 22. Refactor into ProjectsDEMO
  23. 23. Results• Testable Code• Separation of Concerns• Loose Coupling• Minimal logic in UI layer A solid foundation for a maintainable application!
  24. 24. Automate• One Click Build• One Click Test
  25. 25. Solution Automation – Build ScriptsDEMO
  26. 26. More TestsDEMO
  27. 27. References• Separation of Concerns -• Hexagonal Architecture -• Onion Architecture -• More Onion Architecture -• New is Glue - Resources• N-Tier Application Design in C#• Design Patterns Library• SOLID Principles of OO Design
  28. 28. Thanks!• Find me at• We’re hiring developers and trainers at Telerik!•