In this session, we will discuss the Great Simplification Architecture, instead of creating abstract towers of babel, we will see how we can create agile, maintainable and easy to work with architectures and systems that allow you to just go in and start working, rather than spend a lot of time an effort hammering everything in sight, looking for the nail that the architecture diagram's page 239 says must be there.

1. Hard Coding as a design
approach
Oren Eini aka Ayende Rahien
http://ayende.com
ayende@ayende.com

3. e

4. Why building traditional 3 layers, repository
laden, abstractions heavy applications is like
drowning puppies.

5. A bit of history
• A long time ago….

6. But it got better

7. Typical architecture?
• Disconnected apps
• No network
• 1 user

8. Then came the network…
• Concurrent users (low number)
• One server *
• Many clients

9. What is a server…
• A database

10. Problems with this approach
• Clients have direct access to db.
• Can modify data at will.
• Solutions?

11. Create an API
• Server is still a DB.
• API built using Stored Procedure.
• Security via controlling access to those sprocs.

12. Typical architecture?
Clients – Stored Procs
Database
Windows apps, “API”

13. Then came the web…
• Many users
• How to deal?

14. If it ain’t borken….

15. Minimum modifications
Clients – Actual Server – Stored Procs
Database
Windows apps, BL goes here “API”

16. 3 Tiered Architecture
• Actually all about connection pools
• Later..
– Security
– Robustness
– This is how you DO it

18. Today?
• 3 tiered systems rarely required.
• Usually
– 2 tier (web / db)
– Multi tier ( web farm / db farm)
– System broken to multiple apps

19. Why the history lesson?

21. In software…
• Long time ago…
• Direct DB access
• Then SP…

22. How did it look like?
• usp_FindCustomerById(@id)
• usp_FindCustomersByName(@name)
• usp_FindCustomersByNameSortLatest()

23. Let the years roll

24. Now?
OR/M •
Customers
Repository Database •
Customers
Service
Customers
Controller

25. Do you want to see it in action?

27. Controller calls…

28. Business Logic!

29. DAL

31. What I think of this

32. Good architecture?
• Maintainable?
• Easy to work with?
• Easy to change?

34. But we use an OR/M…
• And we have repositories and services and IoC
and Linq and goodness and spice.

35. My precious…

36. Typically…

37. Implemented as…

38. Usage

39. Digging down..

40. Spot the differences
• ITaskService.GetTaskById() • usp_GetTaskById

43. Controller calls…

44. Why so cruel?

45. Half way there…

46. The truth about reusable code…

47. What do I suggest?

48. Simplicity, part I

49. Simplicity, Part II

50. Limit your abstractions
• Very small number, 4 – 8 in most apps
• Possible abstractions:
– Controllers
– Views
– Entities
– Commands
– Tasks
– Events
– Queries

51. Small infrastructure
• Enough to give you context for running
• < 5% of your app, or you lose
• Allow to make assumption about where you
run

52. Forget your testing instincts
• Code that makes assumptions about where it
is running is good code.*
– I have a way to access db
– I have a way to get current context info
• * for a given set of assumptions

53. For that matter, what about testing?

55. Most tests end up here…

56. Unit testing?
• Do you actually care about the unit?
• I care about the system, not the unit.
• What happen when I need to refactor?
– Unit Tests make assumptions about
implementation.
• You’ll have a User Service

57. Unit testing, my way…

58. And the test…

59. What you end up with?
• A lot of classes, following same patterns.
• Cookie cutter code.
• Easy to get into
• Easy to understand
• Major decisions in infrastructure (when to
run, how to run, what is the context)

60. How to ensure it works?
• Tests
• System tests, actually testing meaningful stuff

61. Summary
• Reduce abstractions
• Limit scope of actions
– As few code / layers between input & reaction
• Avoid the buzz

62. Question & Lynching