Udi Dahan – The Software Simplist Session Code: ARC 304.
-
Upload
quentin-martin -
Category
Documents
-
view
218 -
download
0
Transcript of Udi Dahan – The Software Simplist Session Code: ARC 304.
What will you see here?
Distributed Systems ArchitectureUI DesignDomain Model
What won’t you see here?
Code
Why transform between tiers?
Use EF to map from tables to domain objects
Map from DTOs and WS to domain object
Map from DTOs & WS to view model
DBWS
UI
Cache
Keep it simple - 2-Tier
Persistent View Model
UI
Query only
For each view in the UI, have a view in the DB
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
stateWhat the user saw is irrelevant
Transaction
Command Processing Tiers
DBWSInput
Validation Validation
Command
Get current state
Rules
Persist
Traditional User Interfaces
ID Total Date Shipped Account etc etc etc
317 $37.87 1/9/09 Yes A17T5
318 $99.99 3/7/09 Yes A17T5
319 $100.11 4/8/09 Yes P313Z
320 $69.47 9/9/09 No P599Z
Orders
CancelSave
Capturing user intent
Why is it important? Differentiating between:
Correcting a mistyped shipping addressThe user moved – reroute shipments underway
Sometimes users accidentally modify fields when tabbing between columns
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 happensSomebody else got in first on one of the seats
Try to find a block of seats somewhere else
Capturing user intent
Group reservation:Small group – sitting togetherLarge group – several small groups
Enter number of peopleEnter preferred seat type – indicates cost
System emails back when reservation can be filledInclude waiting list functionality
Scalability benefitsThousands of seats, hundreds of thousands of requests
No need to show actual status
What’s a good command?
The kind you can reply with:
“Thank you. Your confirmation email will arrive shortly”
Inherently asynchronousNot really related to an entity
Commands versus Entities
It’s easier to validate the commandLess dataMore specific
Is this potentially good
Validating large entities is complex
What aren’t they for?
Validation
Commands are validated before the domain model is called
Queries
Entity relationships for reading are unnecessary
What are they for?
Answering the question:
Should I do what this valid command is asking?
If the answer is yes, change its state
Queries
CommandsDB
WSInput
Validation Validation
Rules
Queries
For better scalability, add pub/sub
View Model
CacheUpdater
Publish
Summary
Keep queries simple – 2-Tier if possibleNo data transfer objects
Have commands reflect user intentAdjust UI design to capture intent
Get the benefits of asynchronous programmingSimple validation, focused business rules
Thank youUdi Dahan – The Software SimplistEnterprise Development Expert & SOA Specialist
www.UdiDahan.com
www.microsoft.com/teched
Sessions On-Demand & Community
http://microsoft.com/technet
Resources for IT Professionals
http://microsoft.com/msdn
Resources for Developers
www.microsoft.com/learning
Microsoft Certification & Training Resources
Resources
© 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.