This document discusses patterns for website development including: - Using domain models as pure POCO objects with no behavior that are shared across layers - Having view models that are optimized for views with validation and helper methods - Having controllers call tasks to retrieve data and map between domain and view models - Implementing business logic in tasks that work with domain objects and call repositories - Having repositories that encapsulate data access and transactions for domain aggregates

1. Website Patterns

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

12. ENTITY FRAMEWORK
REPOSITORIES

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.