Uploaded byOren Eini
Hard Coding as a design approach
The document discusses the evolution of software architecture from direct database access to a more structured approach using APIs and stored procedures. It emphasizes the importance of simplicity and limiting abstractions in application design, advocating for a focus on maintainability and meaningful testing. The key takeaway is to reduce unnecessary complexity while ensuring that the code remains understandable and manageable.
More Related Content
Similar to Hard Coding as a design approach
Hard Coding as a design approach
- 1. Hard Coding asa design approach Oren Eini aka Ayende Rahien http://ayende.com ayende@ayende.com
- 3.
- 4. Why building traditional3 layers, repository laden, abstractions heavy applications is like drowning puppies.
- 5. A bit ofhistory • A long time ago….
- 6. But it gotbetter
- 7. Typical architecture? • Disconnectedapps • No network • 1 user
- 8. Then came thenetwork… • Concurrent users (low number) • One server * • Many clients
- 9. What is aserver… • A database
- 10. Problems with thisapproach • 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 theweb… • Many users • How to deal?
- 14. If it ain’tborken….
- 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 tieredsystems rarely required. • Usually – 2 tier (web / db) – Multi tier ( web farm / db farm) – System broken to multiple apps
- 19. Why the historylesson?
- 21. In software… • Longtime ago… • Direct DB access • Then SP…
- 22. How did itlook like? • usp_FindCustomerById(@id) • usp_FindCustomersByName(@name) • usp_FindCustomersByNameSortLatest()
- 23. Let the yearsroll
- 24. Now? OR/M • Customers Repository Database • Customers Service Customers Controller
- 25. Do you wantto see it in action?
- 27.
- 28.
- 29.
- 31. What I thinkof this
- 32. Good architecture? • Maintainable? •Easy to work with? • Easy to change?
- 34. But we usean OR/M… • And we have repositories and services and IoC and Linq and goodness and spice.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. Spot the differences •ITaskService.GetTaskById() • usp_GetTaskById
- 43.
- 44.
- 45.
- 46. The truth aboutreusable code…
- 47. What do Isuggest?
- 48.
- 49.
- 50. Limit your abstractions •Very small number, 4 – 8 in most apps • Possible abstractions: – Controllers – Views – Entities – Commands – Tasks – Events – Queries
- 51. Small infrastructure • Enoughto give you context for running • < 5% of your app, or you lose • Allow to make assumption about where you run
- 52. Forget your testinginstincts • 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 endup here…
- 56. Unit testing? • Doyou 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, myway…
- 58.
- 59. What you endup 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 ensureit 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.