Date post: | 04-Jul-2015 |
Category: |
Technology |
Upload: | simon-smith |
View: | 45 times |
Download: | 0 times |
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...