Real-world software design practices when developing ASP.NET web systems by Bojan Veljanovski
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,206 vues
Topics of discussion: - Evolving Architectures - Command & Query Implementation - Component Oriented Single Page Modules - Evolutionary database development and migrations
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (17)
Similaire à Real-world software design practices when developing ASP.NET web systems by Bojan Veljanovski
Similaire à Real-world software design practices when developing ASP.NET web systems by Bojan Veljanovski (20)
Dernier
Dernier (20)
Real-world software design practices when developing ASP.NET web systems by Bojan Veljanovski
- 1. Bojan Veljanovski Software Development Engineer | Technical Architect HASELT Ready Real-world software design practices when developing ASP.NET web systems
- 2. General Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors Bronze Sponsors Promoters Ready
- 3. A quick chat • Users interact with apps by INTENT • Server processes ACTIONS • Who triggers those ACTIONS? Ready
- 4. Example of User Intent in medical institution • Actor: Patient Ready – Request an appointment with the doctor – Cancel appointment – Re-schedule appointment • Actor: Doctor – Confirm requested patient’s appointment – Deny requested patient’s appointment – Check schedule – Look into historical medical records for the patient
- 5. Example of a System Action • Patient Actions Ready – RequestNewAppointment – CancelRequestedAppointment – RequestAppointmentReschedule • Doctor Actions – ConfirmRequestedAppointment – DenyRequestedAppointment – GetSchedule – GetHistoricalRecordsForPatient
- 6. Example of a System Action • Patient Actions Ready – RequestNewAppointment – CancelRequestedAppointment – RequestAppointmentReschedule • Doctor Actions – ConfirmRequestedAppointment – DenyRequestedAppointment – GetSchedule – GetHistoricalRecordsForPatient • WRITE • WRITE • WRITE • WRITE • WRITE • READ • READ
- 7. Example of a System Action • Patient Actions Ready – RequestNewAppointment – CancelRequestedAppointment – RequestAppointmentReschedule • Doctor Actions – ConfirmRequestedAppointment – DenyRequestedAppointment – GetSchedule – GetHistoricalRecordsForPatient • Command • Command • Command • Command • Command • Query • Query
- 8. Evolving Architecture Users work with apps by INTENT. Your UI should capture it! Your system should process it! Ready
- 9. Agenda • Evolving Architectures • Command & Query Implementation • Component Oriented Single Page Modules • Evolutionary database development • Summary Ready
- 10. Bojan Veljanovski Ready • Software Development Engineer and Technical Architect at HASELT • HyperLAB Coordinator • Technical Speaker • Microsoft Certified Professional • Former Microsoft Student Partner Favorite topics: – Software Architectures and Design – Code. Code. Code. – Emerging technologies
- 11. Evolving Architectures (from high-level perspective) Ready
- 12. Evolving Architecture Classical Layered Architecture Ready UI DTO ASP.NET DTO App Services Domain Object Data Access Logic Data Structure DB Validation Business Logic Data Reads Data Writes
- 13. Evolving Architecture Adding Query Ready UI DTO ASP.NET DTO App Services Domain Object Data Access Logic Data Structure DB Validation Business Logic Some Data Reads Data Writes Query Handler Data Reads Query Result Domain Object
- 14. Evolving Architecture Going further with the Query Data Reads Ready UI DTO ASP.NET DTO App Services Domain Object Data Access Logic Data Structure DB Validation Business Logic Some Data Reads Data Writes Query Result Query Handler Denorm Structure
- 15. Evolving Architecture Adding Command Data Reads Ready UI DTO ASP.NET DTO App Services Domain Object Data Access Logic Data Structure DB Validation Business Logic Some Reads Writes Query Result Query Handler Denorm Structure Command Command Handler Domain Object
- 16. Evolving Architecture Some cleaning Data Reads Ready UI ASP.NET Data Access Logic Data Structure DB Validation Business Logic Some Reads Writes Query Result Query Handler Denorm Structure Command Command Handler Domain Object
- 17. Evolving Architecture Some cleaning Data Reads Ready UI ASP.NET Data Access Logic Data Structure DB Validation Business Logic Some Reads Writes Query Result Query Handler Denorm Structure Command Command Handler Domain Object Query Result Command
- 18. Evolving Architecture What about collaborative systems, real-time and stuff? Ready
- 19. Evolving Architecture Look ma’, real-time Ready UI ASP.NET DAL DB Query Handler Socket: PUSH Command Handler Event Handler Event
- 20. Evolving Architecture Full-Featured CQRS (overview) Ready
- 21. Command & Query Implementation Command & Query Implementation Ready
- 22. Demo: Implementing CQS Ready
- 23. Component Oriented Single Page Modules Ready
- 24. Component Oriented Single Page Modules Common seen SPA structure • Controllers • Models • ViewModels • Views • Modules • Components • Utils • Services Ready
- 25. Component Oriented Single Page Modules There is a better way • Modules • Components Ready – View – ViewModel • Shared – Events (message constant) – Actions (message constant) – MessageBus (pub/sub) • Data Services – API Calls – LocalStorage
- 26. Component Oriented Single Page Modules Rules of thumb • One Module per Page • Focused modules • Cohesive components Ready – Not *everything* should be reusable • Components don’t TALK they: – REACT (to messages) – EMIT (messages) • Message types – Event – Action
- 27. Component Oriented Single Page Modules Ready Message Bus Data Services API Module A Module B Module C pub sub pub sub pub sub
- 28. Component Oriented Single Page Modules Flux Architecture Ready
- 29. Demo COSPM Ready
- 30. Evolutionary Database Development Ready
- 31. Evolutionary Database Development Evolutionary Database Development • A DB consist of Schema and Test Data • Schema is Source Code • Schema changes are tracked over-time • Version it in GIT • Every dev gets its own db instance • Devs make frequent integrations into shared master db • FluentMigration mechanisms help us build our db in any RDMS system we want Ready
- 32. Demo Fluent Migration Ready
- 33. Summary • Users work with apps by INTENT • System processes ACTION triggered by INTENT • READS are different from WRITES Ready – Treat them as so, in your code, yo • Components are simple, inter-components communication is hard • Database schema is source code too – it evolves – Version it • Don’t fall into the tech hype hole – Think • There are no ‘best practices’, only ‘good practices in context’
- 34. Questions Ready Complete the evaluation and earn the chance to win valuable prizes from our sponsors
- 35. Thank you Ready