How do you manage data in memory? Row as result-set? Rational like in a database? As domain objects? If you need to map data to objects the easiest solution seems to be an O/R-Mapper. The thin red line lays between losing control over data handling and performance and applying developer convenience and flexibility. This session introduces a solution from a customer project that reduces code duplicates in data access code, still provides flexibility and control as well as performant data access. See how you can develop a transparent and reusable data access layer which comes with O/R-Mapping functionality by just making intensive use of object oriented principles.

1. Data Access Layers
Convenience vs. Control and
Performance?
Daniel Fisher(lennybacon)
Software Architect

2. Objectives
 You know what Data is
 You know what a database is (not)
 You know what OOP is
 You know what N-Tier means

3. Background
 Most Applications out there need a data store
 My Opinion ;-)
 Databases are intended to serve data in
multithreaded and multi client access
scenarios
 XML is just File IO
 Access is NOT a database

4. Database vs. Memory
 Different data store
 Behavior
 Persistence
 Transactions
 Data (types)
 Database Automation Types vs.
 Development platform Type System

5. Moving to Memory
 Raw Data from SQL Server
 Result Set
 (Raw) Data
 Untyped
 Tabular Data
 DataSet/DataTable
 Business Objects
 Domain Model

6. (Raw) Data
 Command & Connection
 DataReader & Scalar execution

7. (Raw) Objects
 Code it all on your own
 Forget Strong Types
 Forget OOP
 Forget Calculations
 ... And so on
 NOT an option for complex data!

8. Tabular Data
 DataSet and DataTable
 Adapter in the middle

9. Tabular Data
 Great IDE Support
 Easy to use
 Internally uses a DataReader
 Stores data as:
 DOM
 DiffGram
 NOOOP
 Violates N-Tier architecture priciples

11. I‘m Sorry
 I wanted to show a console application that fills a
DataTable with 100000 rows of the customer
database and profile it‘s memory...
 I killed dotTrace 2.0 process after 2 hours
 My box is a 2 Ghz dual core with 2 Gigs RAM
 Wow!

12. Business Objects
 Some mapping mechanism

13. Mapping mechanisms
 Declarative Attributes
 Mapping Configuration
 Code

14. Mapping conflicts
 DesignTime vs. RunTime
 Performance vs. Convinience
 Hmmmm?

15. N-Tier: Top Down vs. Star

16. Motivations of the code
 Nice OOP
 Simply work with „natural“ objects
 Clean N-Tier
 Never use „System.Data“ in your logical code
 No SQL?
 Reduce code duplicates
 Data access methods

17.  Codewalk
 DataAccess
 Object Model
 Client code

18. Topographical Tiers
 What if you need to spread your application
across multiple boxes
 Architectural requirements
 Scalability requirements
 Infrastructural requirements

19. Adding a Tier
Client Server
Manager code
- Forwards calls service
- Converts messages to types
Manager code
- Access database
- Converts data to types

20. Summary
 Write less code
 Use the left lines to build reusable modules and
increase developer expirience
 Autonomy
 Write code that is independent to prevent scale
out issues
 Disconneced
 Connect only if you need data (get/set)
 Define concurrency strategies

21. Call to action
 It‘s not hard to write such things on your own
 Controled performance
 Controled memory usage
 The developer expirience you want
 Add-in
 Custom tool
 MsBuild Task
 ...