MVC Website Pattern The Controller, Task, Repository, Command Pattern
Upcoming SlideShare
Loading in...5

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



Pattern for MVC website

Pattern for MVC website



Total Views
Views on SlideShare
Embed Views



2 Embeds 3 2 1


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

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

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