The document discusses issues with traditional ASP.NET application architectures and how the introduction of MVC helped address some problems. It then describes how the presenter implemented the Unit of Work pattern to help with testing and database consistency in their application. However, this implementation violated SOLID principles. The presenter improved the design by separating concerns into distinct layers and implementing generic repositories. This made the code more testable and decoupled from Entity Framework while better adhering to object-oriented design principles. In the end, the presenter advocates evaluating design patterns critically and continuously challenging accepted approaches.

1. Steve Westgarth
Entity Framework - to the Unit of Work Design Pattern and Beyond
Software Developer

2. Lets start at the beginning
Classic ASP

3. Lets start at the beginning
ASP.NET Web Forms

4. Major Issues
• Undefined Application Architecture with lack of Separation of
Concerns (SoC)
• Complex Pages with Performance issues.
• Lack of abstraction with least control over HTML.
• Limited support for testing and SEO.
• Lack of Re-usability and minimal parallel Development.

5. 13th March 2009 – A great day for developers

6. Model
View
Controller
Release of .NET MVC 1.0

8. var MVC = new MassiveViewController();

9. Demo

10. Major Issues
• Limited Programming / Coding Standards / Agreed Best Practice
• Difficult to Unit Test
• View Controller Bloat
• Difficult to debug
• Difficult to maintain
• Working together is challenging
• Code slow and not responsive
• ….

12. We Need a Design Pattern!

13. Separation of Concerns

14. DAL
Presentation Layer
Model
View
Controller

15. Improvements We Made
• Strongly Typed Models
• Static Helper Methods for Transforming Model Objects
• DAL Extension Methods
• Model Annotations
• Introduction of a Base Controller
• Agreed Folder Structure
• Dependency Injection

16. Demo

17. DAL
(With Repository Pattern?)
Presentation Layer
Model
View
Controller

18. What’s the Purpose of a Repository Pattern?
• Good for Testing
• Loose Coupling (Easy to Upgrade to New Framework Versions)
• Easily Extend Database Functionality
• Clean Architecture – Independent of Frameworks
• Ability to remove some abilities / features of EF

19. We Still Had Problems
• Customer Ordering Application
Each DB Context has its own in memory set of changes
If Save() on one Context Succeeds and the Other Fails their can be Database Inconsistency

20. DAL
With Unit of Work Design Pattern
Presentation Layer
Model
View
Controller

22. Unit of Work Design Pattern
• Single Transaction – Minimizing Database Calls
• Creates an abstraction layer between the database and the
application
• Facilitates Automated Unit Testing

23. Demo

25. SOLID Principles
The first 5 principles of Object Orientated Design

26. S ingle Responsibility
Each class has one job to do
Open / Closed
Open for Extension but Closed for Modification
L iskov substitution
If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the
desirable properties of T
I nterface Segregation
No client should be forced to depend on methods it does not use
Dependency Inversion
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

27. Unit of Work Violates a Number of SOLID
Principles
• Nominal Abstraction – Its still closely coupled with Entity Framework
• The DBContext Entity makes it all the way into the application layer
• Violates the Single Responsibility Principle
• Leads to Opaque Dependancies, all dependancies are hard coded into
the UnitOfWork Class making it difficult to extend.
• Violates the Open / Closed Principle

28. DAL
Presentation Layer
Model
View
Controller
Business Logic Layer
Our Solution

29. Key Principles
• Data is transformed in each layer into a layer specific model
• A Generic Repositories is Implemented which is then extended for
individual Models – this minimizes code duplication
• Business Logic is totally divorced from the Application Layer – no
database logic operations are performed in the controller or
application classes
• Minimizes View Controller Bloat making code readable
• Encourages adherence to agreed coding standards

30. Advantages
• Totally Decouples Entity Framework from Presentation Layer
• Makes it possible to adhere easily to the Single Responsibility
Principle
• Adheres to Liskovs Substitution Principle
• Total Interface Segregation
• Adheres to Dependency Inversion
• Entity Framework could be entirely placed with no modification to the
Application Code.

31. Issues?
• Open / Closed Principle
• The repositories are still hard coded into the Unit of Work Class
• It is possible to extend Unit Of Work as a series of partial classes but it isn’t a
true implementation of the principle.

32. To Summarise
• Do you have an agreed Design Pattern In Your Company? When did
you last challenge the accepted norm?
• Adhere to the Solid Principles, it makes for cleaner code
• If you use Unit of Work – consider how you can make it better
• If you don’t use Unit of Work explore its merits …. And then consider
how you can make it better.

33. Steve Westgarth
Entity Framework - to the Unit of Work Design Pattern and Beyond
Code @ github.com/stephenwestgarth/DesignPattern.git
@stevewestgarth on Twitter
Software Developer

34. Android and iOS Conference
www.codemobile.co.uk
Use Discount Code DOTNETNOTTS to get 25% off