2006 DDD4: Data access layers - Convenience vs. Control and Performance?

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

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

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

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

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

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

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

Tabular Data
 DataSet and DataTable
 Adapter in the middle

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

2006 DDD4: Data access layers - Convenience vs. Control and Performance?

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!

Business Objects
 Some mapping mechanism

Mapping mechanisms
 Declarative Attributes
 Mapping Configuration
 Code

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

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

 Codewalk
 DataAccess
 Object Model
 Client code

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

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

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

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
 ...

2006 DDD4: Data access layers - Convenience vs. Control and Performance?

More Related Content

Viewers also liked (20)

Similar to 2006 DDD4: Data access layers - Convenience vs. Control and Performance? (20)

More from Daniel Fisher (15)

Recently uploaded (20)

2006 DDD4: Data access layers - Convenience vs. Control and Performance?