1. Data Access in Your Code Thinking Outside the Framework
David West
Data Access in Your Code
Thinking Outside the Framework

2. About Me .NET Developer since late 2012
Now happily making magic at Envoc
Former audio recording engineer
Passion for solving challenging problems

3. Alternative data access strategies?
i.e. “I use Entity Framework (NHibernate, etc.). Why should I change anything?”
The fast answer: you probably shouldn’t.
Most line of business apps are a good fit with the out-of-box capabilities of large, fully-featured ORMs.
But..

4. “Big” ORMS : what’s bad Performance
Improvements made over the years, but can still create severe bottlenecks in some situations.
Look familiar?
context.Configuration.AutoDetectChangesEnabled = false;
context.Configuration.ValidateOnSaveEnabled = false;
context.Widgets.AddRange(newWidgets);
But things are still slow....

5. “Big” ORMS : what’s bad Highly Opinionated
What constitutes a POCO is defined in terms of the framework
e.g. EF doesn’t do nested value objects (complex types)
Public getters and setters - no state is encapsulated and everything (including collections) is mutable.
As a result, what passes for “domain models” are really just data models. Behavior is put somewhere else.

6. “Big” ORMS : what’s good
Ubiquitous presence
Support
Documentation
Productivity
IQueryable anyone?
Migrations
Unit of Work magic

7. “Big” ORMS : what’s good
Highly opinionated
Homogenizing effect
Keeps everyone on the same page, (if you’re in to that kind of thing.)

8. “Micro” ORMS : the emerging middle class
Provide an assistive management layer over ADO.NET without the trappings of a framework.
Most promote a healthy proximity to SQL which can aid in performance.
Many features of large ORMs are not present.

9. “Micro” ORMS : some popular ones
Dapper
Simple.Data
Massive
PetaPoco

10. New kid on the block : FluidDbClient
SHAMELESS PLUG ALERT
Developed by me in 2016
Proudly violates the #1 rule of ORMs: “Don’t build your own.”
Heavily influenced by Dapper but with some tricks up its sleeves.
.NET Standard 1.3 and .NET 4.5/4.5.1

11. Domain Driven Design (DDD)
A philosophy I can get behind
Promotes deep understanding of an application’s business domain
Promotes a codebase that mirrors the “ubiquitous language” of the domain, not (just) CRUD.

12. Domain Driven Design (DDD)
DDD practices include:
Behavior-rich models
Small aggregates that reflect the data model frequently but align more strongly with use cases.
Defining different contexts in which an entity exists (bounded contexts), resulting in potentially overlapping but highly focused models.
Persistence ignorance

13. Domain Driven Design (DDD)
It’s all about tradeoffs

14. THE CODE

15. The Code Agenda: Show tooling primitives in FluidDbClient
Show a tiny application that uses this tooling for CRUD, including a Unit of Work.

16. The Code
Goals:
Help illustrate the (sometimes excruciating) technical complexities you face when going with a lightweight ORM.
Show ways to leverage unique SQL Server features for performance
Raise questions about cost vs. benefit and entertaining a more CQRS mindset.

17. CONTACT