MVC Website Pattern The Controller, Task, Repository, Command Pattern
- 2. Agenda
- 3. Core Engineering Principles • DRY – Don’t Repeat Yourself • SOLID – Single Responsibility – Open Closed – Liskov Substitution – Interface Segregation – Dependency Inversion
- 4. Top 5 Web Debt Causes • Controllers doing too much • Domain Model Issues – Incomplete – Lack of constraints / incorrect cardinality – Circular Dependencies • View Issues – Inconsistent use of Domain and View Models – View code is doing too much • Database Generation • Unnecessary WCF Service Layers
- 5. Pattern
- 6. Domain Model • The domain model is pure POCO • The domain model holds state and no behaviour. • The domain model is the currency for all layers of the website from the controller to the repositories.
- 7. View Model • The View Model is the state required to be bound to a View • The view model object graph is in a format most appropriate for a View • Validation should occur against the view model via Data Annotations. • View Models are extended with helper method to assist the flow of View code.
- 8. Controllers • Controllers should only have dependencies on Tasks • Controllers should be responsible for calling the required task actions to get / save the data required • Controllers call mappers to map between domain objects and view models
- 9. Views • A view should only be bound to a ViewModel object and never expose a domain object directly as its model • Logic required for views should be implemented as extension methods of the ViewModel and not directly within the view itself
- 10. Tasks • A task can be viewed as the business layer for a domain aggregate. • A tasks is where the behaviour for a aggregate domain object is implemented • Tasks deal only with domain objects • Tasks can make one or more repository calls to a Repository for the same domain aggregate.
- 11. Repository • A single repository exists for each domain aggregate • A repository will normally map 1-2-1 with tasks. • The repository is responsible for transactional boundaries and compensation if required. • A repository does not have to be solely for communication with a database but can be used for any means of data access such as communicating with services
- 13. Domain Model • Model First Domain using EF 4.1 – Auto Generated POCO Entities – Visualisation of object relationships – Build time validation • Database Generation done in SQL Scripts
- 14. Entity Framework Repositories • Encapsulates DbContext use • Use Commands to Encapsulate LINQ to Entities queries • Object Disposal handled via Using declarations
- 15. Entity Framework Commands • The command class is a single location where all commands against a database context are encapsulated. • Promotes LINQ reuse across all repositories • Centralised location of all database use of IQueryable • Decorated with multiple interfaces to restrict access from repositories. • Commands are the transaction boundary.