30
Lars-Erik Kindblad Senior Consultant Blog: kindblad.com Data Access – Best Practice

Data Access - Best Practice

Embed Size (px)

DESCRIPTION

Lars-Erik Kindblad presentation at the Capgemini Microsoft User Group 2012.

Citation preview

Page 1: Data Access - Best Practice

Lars-Erik KindbladSenior ConsultantBlog: kindblad.com

Data Access – Best Practice

Page 2: Data Access - Best Practice

| Sector, Alliance, Offering

Agenda

Why is Data Access so important? Common issues in many applications How to solve these issues Summary

Page 3: Data Access - Best Practice

| Sector, Alliance, Offering

Why is Data Access so important?

Retrieving, creating, updating and deleting data are core operations Affects the entire application in a bad way if done incorrectly

Page 4: Data Access - Best Practice

| Sector, Alliance, Offering

Common issues in many applications

Page 5: Data Access - Best Practice

| Sector, Alliance, Offering

Code issues

The code in the data access layer is often put into a single or a few huge classes• Hard to maintain

Database queries are constructed in the frontend or business layer• Leads to messy frontend or business code

ORM framework limitations or lack of «ORM masters»• A lot of quickfixes

Doesn’t support rollback of changes when errors occurs

Page 6: Data Access - Best Practice

| Sector, Alliance, Offering

Performance issues

The application slow• Too many database queries• Too heavy database queries• Lazy loading• Poorly generated SQL by the ORM framework

Page 7: Data Access - Best Practice

| Sector, Alliance, Offering

Security issues

Vulnerable to SQL Injection Users get access to data they should not have access too

Page 8: Data Access - Best Practice

| Sector, Alliance, Offering

Quality issues

Many bugs• No tests• ... or tests that doesn’t test the important stuff

Page 9: Data Access - Best Practice

| Sector, Alliance, Offering

How to solve these issues

Page 10: Data Access - Best Practice

| Sector, Alliance, Offering

What do we want? Well structured data access code that is easy to maintain

• Small simple classes that does only one thing - Single Responsiblity Principle The application should be fast

• Only retrieve the data that we actually need – Criteria Pattern• Do as much as possible in one query – SQL Joins• Avoid lazy loading

The application should be secure• Use an ORM framework and/or use parameters instead of concatenated strings• Always check for permissions when retrieving, creating, updating or deleting data

Rollback uncomitted changes if anything goes wrong• Transaction support

As little dependency on the ORM as possible• Gateway Pattern

Frontend, Business and Data Access Code should be separated• Logical Layering

High quality – Bug free code• Integration tests

Page 11: Data Access - Best Practice

| Sector, Alliance, Offering

Example code

Page 12: Data Access - Best Practice

| Sector, Alliance, Offering

HOW TO:REDUCE ORM DEPENDENCIESSTRICTER LAYERINGROLLBACK IF ERROR OCCURSHAVE SIMPLE DATA ACCESS CODE

Page 13: Data Access - Best Practice

| Sector, Alliance, Offering

The Common Way

Frontend Layer

Business Layer

Data Access Layer

ORM

Query the Database

Query the Database

Query the Database

Page 14: Data Access - Best Practice

| Sector, Alliance, Offering

A Better Way

Frontend Layer

Business Layer

Data Access Layer

ORM

Query the Database

Transaction Management

Rollback, CommitORM Gateway

Initialize ORMTransaction management

Page 15: Data Access - Best Practice

| Sector, Alliance, Offering

DbContexGateway for FluentData

Page 16: Data Access - Best Practice

| Sector, Alliance, Offering

Data Access Layer

Page 17: Data Access - Best Practice

| Sector, Alliance, Offering

Business Layer

Page 18: Data Access - Best Practice

| Sector, Alliance, Offering

Frontend Layer

Page 19: Data Access - Best Practice

| Sector, Alliance, Offering

EFFICIENT DATA RETRIEVAL & FILTERING

Page 20: Data Access - Best Practice

| Sector, Alliance, Offering

Overview

Business Class

Frontend Class

Data Access Class

Criteria Pattern: Decide what data to retrieve and filter on

Business logic

Construct the most optimal and secure query

Page 21: Data Access - Best Practice

| Sector, Alliance, Offering

Frontend Layer

Page 22: Data Access - Best Practice

| Sector, Alliance, Offering

Business Layer

Page 23: Data Access - Best Practice

| Sector, Alliance, Offering

Data Access Layer

Page 24: Data Access - Best Practice

| Sector, Alliance, Offering

Overview

Business Layer

Frontend Layer

Data Access Layer

Transaction managementDecide what data to retrieve and filter on

Business logic

Construct the most optimal and secure query

Page 25: Data Access - Best Practice

| Sector, Alliance, Offering

HOW TO:GET A HIGH QUALITY APPLICATIONTHROUGH INTEGRATION TESTS

Page 26: Data Access - Best Practice

| Sector, Alliance, Offering

Test - CreateProductDbCommand

Page 27: Data Access - Best Practice

| Sector, Alliance, Offering

Test - GetProductsDbCommand

Page 28: Data Access - Best Practice

| Sector, Alliance, Offering

Summary

Have small simple classes that does only one thing Use the Criteria Pattern to decide what data to retrieve Use joins to retrieve as much data as needed in one query Avoid lazy loading Use parameters instead of concatenated strings Always check for permissions when retrieving, creating, updating or

deleting data Use transactions to rollback when errors occurs Use the Gateway Pattern to reduce ORM dependency Have a strict Frontend layer, Business layer, Data Access layer Verify quality through Integration Tests

Page 29: Data Access - Best Practice

| Sector, Alliance, Offering

QUESTIONS?

Page 30: Data Access - Best Practice

www.capgemini.com

The information contained in this presentation is proprietary. ©2010 Capgemini. All rights reserved