MVC Website Pattern The Controller, Task, Repository, Command Pattern


Published on

Pattern for MVC website

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MVC Website Pattern The Controller, Task, Repository, Command Pattern

  1. 1. Website Patterns
  2. 2. Agenda
  3. 3. Core Engineering Principles• DRY – Don’t Repeat Yourself• SOLID – Single Responsibility – Open Closed – Liskov Substitution – Interface Segregation – Dependency Inversion
  4. 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. 5. Pattern
  6. 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. 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. 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. 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. 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. 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. 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. 14. Entity Framework Repositories• Encapsulates DbContext use• Use Commands to Encapsulate LINQ to Entities queries• Object Disposal handled via Using declarations
  15. 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.