Data Access LayersConvenience 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

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?

N-Tier: Top Down vs. Star

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