There are only 3 operations in a web app

Post on 04-Jul-2015

48 views 0 download

description

tech stuff

Transcript of There are only 3 operations in a web app

There are only 3

operations in a web

application (or maybe 2)

Worked on lots of web applications

Seems to be lots of attempts at the same

problems

Typically non-SOLID solutions

History

Without SOLID web applications are

Difficult to maintain

Buggy

Difficult to scale

History

As any other application

Identify the entities

Identify the operations these entities execute

Back to basics

Web applications have lots of entities

Customer … Order … Hotel … Basket … Page

… Section … SubSection … etc.

Back to basics

However the stateless nature of the web

plus user expectations lead to …..

Back to basics

… A limited number of operations

1. Find 0 or more entities

2. Add a new entity

3. Change an entity

The big idea.

… A limited number of operations

1. Find 0 or more entities

2. Add a new entity

3. Change an entity

Sometimes combined into a ‘Crupdate’

The big idea.

Sign up? Add item to basket? Log error?

Add new entity

Login? Get Hotel Details? View sale items ?

Find 0 or more entities

Update password?

Change an entity

The big idea.

So … can we make a framework that

abstracts away all the common parts of

these operations, allowing us to produce

SOLID software with the minimum of

changes?

The big idea

So … can we make a framework that

abstracts away all the common parts of

these operations, allowing us to produce

SOLID software with the minimum of

changes? ….. MAYBE?

The big idea

How about creating a suite of “Micro

services” for each entity.

The service contains all the (validation)

business logic for the entity, returning the

results in a consistent way. ….

The big idea.

These micro services can only be reached

through a message, making them fully

decoupled from the consuming application.

The big idea.

A POCO class whose single responsibility is

to transmit information between the

provider and the producer

The Message

A POCO class whose sole responsibility is to

update the state of the message.

Simple to test.

Simple to read.

Only place for business logic.

The Message Processor

Can be consumed by any .net framework.

As there is no business logic consuming is

simple.

Every message is consumed in the same

way, so consuming code follows a similar,

simple pattern.

Consuming with MVC

● Normalising code to its common

components reduces repeated code.

● Normalising code to its common

components reduces the amount of code

needed.

● Normalising code to its common

components encourages SOLID software.

Epilogue

Questions...