1 / 47

Command / Query Responsibility Segregation

Command / Query Responsibility Segregation. Udi Dahan – The Software Simplist Session Code: ARC 304. What will you see here?. Distributed Systems Architecture UI Design Domain Model. What won’t you see here?. Code. Distributed Systems Architecture. Common Distributed Architecture. DB.

blithe
Télécharger la présentation

Command / Query Responsibility Segregation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Command / Query Responsibility Segregation Udi Dahan – The Software Simplist Session Code: ARC 304

  2. What will you see here? • Distributed Systems Architecture • UI Design • Domain Model What won’t you see here? • Code

  3. Distributed Systems Architecture

  4. Common Distributed Architecture DB

  5. Let’s deal with the obvious…

  6. Collaboration is good – isn’t it ? Get data Get data User is looking at stale data Change data

  7. So why go through all the layers? Cache DB

  8. Why transform between tiers? Cache UI WS DB Map from DTOs & WS to view model Map from DTOs and WS to domain object Use EF to map from tables to domain objects

  9. What was the point of all this again?

  10. Queries – showing data to the user

  11. Why not be upfront about it? List of customers Data correct as of 10 minutes ago

  12. Only data, no behavior: not an object

  13. Keep it simple - 2-Tier UI Query only Persistent View Model For each view in the UI, have a view in the DB

  14. Incrementally add from there

  15. Commands – accepting user input

  16. Can we fully trust users decisions?

  17. Validation and Business Rules • Validation: Is the input potentially good? Structured correctly? Ranges, lengths, etc • Rules: Should we do this? Based on the current system state What the user saw is irrelevant

  18. Command Processing Layers DB

  19. Command Processing Tiers Transaction Get current state Command WS Input DB Persist Validation Validation Rules

  20. Should we do what the user asks?

  21. User Interface Design

  22. Traditional User Interfaces Orders Save Cancel

  23. Capturing user intent • Why is it important? Differentiating between: Correcting a mistyped shipping address The user moved – reroute shipments underway • Sometimes users accidentally modify fields when tabbing between columns

  24. Reservation systems

  25. Reservation systems

  26. Not capturing user intent • In a traditional UI – what we have is the checkbox • Why do users select multiple seats? Because they’re reserving for a family / friends • But then, concurrency happens Somebody else got in first on one of the seats • Try to find a block of seats somewhere else

  27. Capturing user intent • Group reservation: • Small group – sitting together • Large group – several small groups • Enter number of people • Enter preferred seat type – indicates cost • System emails back when reservation can be filled Include waiting list functionality

  28. Usability benefits More users get what they want with less clicks

  29. Scalability benefits Thousands of seats, hundreds of thousands of requests No need to show actual status

  30. Revisiting the command

  31. What’s a good command? • The kind you can reply with: “Thank you. Your confirmation email will arrive shortly” • Inherently asynchronous • Not really related to an entity

  32. Commands versus Entities • It’s easier to validate the command • Less data • More specific • Is this potentially good • Validating large entities is complex

  33. Domain Models

  34. What aren’t they for? • Validation Commands are validated before the domain model is called • Queries Entity relationships for reading are unnecessary

  35. What are they for? • Answering the question: Should I do what this valid command is asking? • If the answer is yes, change its state

  36. Putting it all together

  37. Queries View Model Queries Commands WS Input DB Validation Validation Rules

  38. For better scalability, add pub/sub Queries View Model Queries Commands Publish WS Input Validation Validation Rules Cache Updater DB

  39. Summary

  40. Summary • Keep queries simple – 2-Tier if possible • No data transfer objects • Have commands reflect user intent • Adjust UI design to capture intent • Get the benefits of asynchronous programming • Simple validation, focused business rules

  41. Thank you • Udi Dahan – The Software Simplist • Enterprise Development Expert & SOA Specialist • www.UdiDahan.com • email@UdiDahan.com

  42. question & answer

  43. Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. Resources • www.microsoft.com/teched Sessions On-Demand & Community • www.microsoft.com/learning • Microsoft Certification & Training Resources • http://microsoft.com/technet • Resources for IT Professionals • http://microsoft.com/msdn Resources for Developers

  44. Complete an evaluation on CommNet and enter to win an Xbox 360 Elite!

  45. Required Slide © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

More Related