Your SlideShare is downloading. ×
0
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Dat336
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
278
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 06/01/11 04:23
  • Transcript

    • 1. DAT336 Connected vs Disconnected Data Access in ADO.NET Pablo Castro Program Manager – ADO.NET Team Microsoft Corporation
    • 2. Agenda
      • Disconnected is good
        • Some connected bits can help
      • Balancing connected/disconnected
        • Scrolling and streaming
        • Custom aggregation
        • Incremental load
      • Summary
    • 3. Disconnected?
      • In the context of this talk:
        • “Disconnected” apps are online applications that don’t keep database connections open for long periods of time such as the lifetime of a session
          • Usually 3-tier applications
        • We’re not going to discuss “off-line” applications where a user can operate an application even if the server is not available
    • 4. Disconnected is Good
      • Simpler to design
        • 3-tier applications follow the disconnected model naturally
      • Simpler to code once the pieces are set
        • i.e. data binding, marshalling in 3-tier apps, no connection management for long-lived business objects
      • Simpler to make apps scale
        • Middle-tier layer easy to scale-out
          • It’s harder to scale-up/out database servers
    • 5. Disconnected ADO.NET
      • ADO.NET has first-class disconnected apps support
        • DataSet as a relational data cache
          • Plays well with remoting & web services
          • Single implementation, no database-specific behavior
        • DataAdapter/DataSet provide services for getting, updating and merging data
      • Custom types for non-relational
    • 6. …but too disconnected…
      • Handling large volumes of data
        • Batch processing
        • Reporting
        • Custom aggregation
      • Performance-sensitive code-paths
        • ASP.NET pages in apps without heavy business logic
        • Gateway applications
      Avoid buffering large portions of data Avoid data-shipping costs
    • 7. Discrete Objects Scenarios
      • This is the “easy part”
        • Stand-alone business objects
      • Business object state representation
        • DataSets – ADO.NET helps with retrieval, update and change tracking
        • Custom objects – model your business entity state using regular classes
      • Remoting or webservices enable this scenario easily
    • 8. Sessions in the Middle Tier Scenarios
      • Per-session state can’t be avoided sometimes
        • If needed, keep only in-memory state
        • No database connections if at all possible
      • Quite common in ASP/ASP.NET apps
      • “Sticky sessions” take care of scale-out
        • So it’s not that bad if you don’t keep connections or other external resources
    • 9. Scrolling and Streaming Scenarios
      • In general, handling large results in pieces
        • UI: scrolling, paging
        • Batch processing: chunking, scanning large results
        • Custom aggregation
      • Options change depending on each case
    • 10. Scrolling, Paging
      • Goal is to fetch rows from a large result, a few at a time
        • Cursors
        • DataAdapter.Fill method
        • SQL-based solutions
    • 11. Scrolling, Paging: Cursors
      • Not available in all databases
      • Provide scrolling support
        • Sometimes even bi-directional
        • No need for extra logic in the application
      • Scalability issues
        • Require to maintain state
          • Database connections, keyset or temporary tables in the database
        • Cursor escalation
          • Server may need to materialize some/all data
    • 12. Scrolling, Paging: Cursors
      • Design issues
        • Hard to include in 3-tier applications
        • Need to keep connection/cursor objects alive in middle tier
        • How is data propagated to the presentation layer?
          • Tends to be a chatty interface
      • Result stability
        • Need to use transactions or static cursors if stability is required
    • 13. Scrolling, Paging: Fill()
      • ADO.NET DataAdapter.Fill() method
        • There’s an overload that takes first row and number of rows
        • Under the covers, this method:
          • Skips rows as needed
          • Copies as many rows as requested to the target DataTable
          • Scans and discards the rest of the rows
        •  Don’t use it for paging in large result-sets
    • 14. Scrolling, Paging: SQL
      • If at all possible, use SQL constructs for paging
        • Stored-procedures
          • if you know the table schema and sort order
        • SQL can help in other cases
          • where the query is not known but constrained
      • Scalability/performance issues
        • Time taken to execute query is not amortized across requests
    • 15. Scrolling, Paging: SQL
      • Design issues
        • Fits nicely for 3-tier apps
          • Each page is an independent database operation
          • No state held between hits
        • Ad-hoc queries are hard to handle
      • Result stability
        • Need to use transactions if stability is required
    • 16. Streaming
      • Goal is to handle very large result-sets
        • No buffering proportional to size of data
        • Concurrency issues
        • Interleaving
      • Common scenarios for streaming
        • Batch processing
        • Reporting
        • Custom aggregation
    • 17. Streaming: DataReaders
      • ADO.NET providers have an streaming interface
        • DataReader class exposes a row at a time
          • Some minor buffering might happen internally
        • Can scan millions of rows without taking much resources
      • Scalability issues
        • Usually large scans happen in batch processes
        • Not many at the same time
    • 18. Streaming: DataReaders
      • Design issues
        • DataReaders cannot be marshaled across tiers
          • Move the batch process code to the middle tier
          • Send the data in chunks to the next tier (too much overhead in most cases)
        • Contention can be high
      • Result stability
        • Depends on the isolation level
    • 19. Custom Aggregate Logic
      • Similar case: scan lots of rows
        • But end-result is a small result-set
      • No need to ship the data out of the server
        • Cursors can help here
        • Scan and aggregate inside the server
        • Ship only the aggregated information to the client
      • Avoids moving lots of data across tiers
    • 20. Incremental Load Scenarios
      • Present first bit of data in UI quick
      • Incrementally load the rest in the background
        • DataSet merge support is great here
        • Be aware of multi-threading issues
    • 21. Incremental Load & Merge
      • ADO.NET DataSet can merge results
      • Incremental load UI
        • Chunking API in the middle tier
        • Bring down the first DataSet and display it
        • As more data comes, merge the DataSets and update UI
          • This even preserves changes in existing data
      • Multi-threading issues
        • DataSet is not thread-safe
        • Same for WinForms UI controls
    • 22. Summary
      • Disconnected is good
        • ADO.NET has great support for it
        • Good to start disconnected by default
      • You will need some connected pieces
        • ADO.NET also helps there
        • You can add connected parts as needed
      • Extremes can hurt your app performance or scalability
    • 23. Attend a free chat or web cast http://www.microsoft.com/communities/chats/default.mspx http://www.microsoft.com/usa/webcasts/default.asp List of newsgroups http://communities2.microsoft.com/ communities/newsgroups/en-us/default.aspx MS Community Sites http://www.microsoft.com/communities/default.mspx Locate Local User Groups http://www.microsoft.com/communities/usergroups/default.mspx Community sites http://www.microsoft.com/communities/related/default.mspx
    • 24. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

    ×