Why Architecture in Web Development matters
•Télécharger en tant que KEY, PDF•
6 j'aime•2,123 vues
Choosing the right software architecture for your project is very important. Besides the framework decision there are many other key issues you need to take into account and which have an impact on such things like maintainability, scalability and also the frequency of possible deployments. In this session you will to learn how to avoid the common pitfalls and traps during your project.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Why Architecture in Web Development matters
Similaire à Why Architecture in Web Development matters (20)
Plus de Lars Jankowfsky
Plus de Lars Jankowfsky (8)
Dernier
Dernier (20)
Why Architecture in Web Development matters
- 1. Why Architecture Lars matters Jankowfsky, swoodoo.com
- 2. Lars Jankowfsky • CTO and (Co-)Founder swoodoo AG • (Co-)Founder OXID eSales AG • XP, agile development fanatic • developing since 15+ years • php since php/fi • Software Architect > 10 years Lars Jankowfsky,
- 3. Architectur e
- 5. Zend Framework symfony cakePHP ezComponent s
- 6. (c) istockphoto success (c) aboutpixel.de
- 7. Scale!
- 8. Speed!
- 9. Deploy!
- 12. (c) istockphoto big ball of mud
- 14. „For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.“ Blaine Cook, Twitter's lead architect Lars Jankowfsky,
- 15. Principles of success
- 16. D.R.Y. Do Not Repeat Yourself
- 17. Single responsibility quot;if it generates XML then it should not gene principle
- 18. K.I.S.S. don‘t think too complex
- 19. (c) spackletoe http://www.flickr.com/photos/spackletoe/90811910/) (c) aboutpixel.de
- 21. Developing
- 22. Art
- 23. (c) dasbeibi @ aboutpixel.de
- 25. Y.A.G.N.I. You Ain‘t Gonna Need it
- 27. (c) istockphoto
- 30. Bad smells? • Do maintenance cost keep increasing? Lars Jankowfsky,
- 31. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented Lars Jankowfsky,
- 32. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented • Small changes ripple through your system Lars Jankowfsky,
- 34. dead code
- 36. comments „what not why“ dead code data classes
- 37. comments „what not why“ long methods dead code data classes
- 38. • http://martinfowler.com/bliki/CodeSmell.html • http://www.codinghorror.com/blog/archives/ 000589.html Lars Jankowfsky,
- 39. Architecture?
- 41. Layered Architecture • separation of concerns Lars Jankowfsky,
- 42. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? Lars Jankowfsky,
- 43. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. Lars Jankowfsky,
- 44. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. • Do not bypass any layer! Lars Jankowfsky,
- 45. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. • Do not bypass any layer! • Separate modules/classes or go SOA Lars Jankowfsky,
- 47. SOA • Pro: makes scaling very easy Lars Jankowfsky,
- 48. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible Lars Jankowfsky,
- 49. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring Lars Jankowfsky,
- 50. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits Lars Jankowfsky,
- 51. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits • Con: integration testing gets more difficult Lars Jankowfsky,
- 54. Database
- 56. ZendDb ADOdb PDO doctrine propel
- 58. Database • you might use a database access layer Lars Jankowfsky,
- 59. Database • you might use a database access layer • go ORM if you want (performance!) Lars Jankowfsky,
- 60. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer Lars Jankowfsky,
- 61. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer • let‘s call it Data Access Object Lars Jankowfsky,
- 62. DB Abstraction Layer PDO, ADOdb, ZendDb....
- 63. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern
- 64. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer
- 65. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer function giveMeMyData()
- 66. MVC
- 68. Controller • Common mistake: business logic in controller Lars Jankowfsky,
- 69. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller Lars Jankowfsky,
- 70. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only Lars Jankowfsky,
- 71. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only • Kick Ass! Lars Jankowfsky,
- 73. View • Use a template engine. Watch performance! Lars Jankowfsky,
- 74. View • Use a template engine. Watch performance! • No business logic in the template/html Lars Jankowfsky,
- 75. View • Use a template engine. Watch performance! • No business logic in the template/html • Kick Ass! Lars Jankowfsky,
- 76. (c) istockphoto
- 77. TDD
- 78. Enforces layered Architecture
- 82. use continuous integration e.g. cruise con
- 84. Unit Tests
- 85. Integration Tests Unit Tests
- 86. Acceptance Tests Integration Tests Unit Tests
- 87. what if fixture/mock preparation are much larger than tests?
- 88. what if your tests run for hours ?
- 89. (c) istockphoto
- 90. framework !== software architecture
- 92. split your application into layers
- 93. enforce proper usage of MVC
- 95. utilize test driven development
- 96. (c) dasbeibi @ aboutpixel.de
- 97. lars.jankowfsky@swoodoo.com Lars Jankowfsky / Thorsten all pictures (c) iStockPhoto if not stated different
- 98. C M V
- 99. C M V
- 100. C M V
- 101. C M V
- 102. Project structure • Remember? Find Boundaries and cut. • quot;Services/Layersquot; - at least on a directory level • use Framework structure • more ??? Lars Jankowfsky,
- 105. scaling? • web Lars Jankowfsky,
- 106. scaling? • web • database Lars Jankowfsky,
- 107. scaling? • web • database • services (ext./int.) Lars Jankowfsky,
Notes de l'éditeur
- strong dependency -> „co-dependency“
- \"if you want to serialize to xml do not create \"toxml\" Method, instead pass $this to the XMLExporter\"
- think in advance but don‘t think too complex before making any generalisation have at least two cases the more abstractions the easier you can change it later
- nobody said it will be easy
- tightrope walk
- preparing fixtures/Mocks difficult
- preparing fixtures/Mocks difficult
- preparing fixtures/Mocks difficult
- preparing fixtures/Mocks difficult
- preparing fixtures/Mocks difficult
- do not spread db calls through your code one function or object generates one „business“ result data access object
- do not spread db calls through your code one function or object generates one „business“ result data access object
- do not spread db calls through your code one function or object generates one „business“ result data access object
- lazy loading ok in Ruby all Variables from controller are accessable.
- lazy loading ok in Ruby all Variables from controller are accessable.
- lazy loading ok in Ruby all Variables from controller are accessable.
- Do not reinvent the wheel. Use frameworks
- at least daily
- test a single class do not touch database, network, (files) use mocks/stubs and provide fast feedback
- test several classes test communication between classes/modules they test full components
- test functionality from „outside“ often build from „user stories“ usually done with Selenium -> not only selenium example openapi