Object relational mapping (ORM) is modern technique used to make incompatible type systems collaborate. Dapper is a micro ORM, specially known for its efficiency and simplicity.
6. Types of Databases
● Relational Database Management Systems (RDBMS)
● NoSQL and Object-Oriented (OODBMS)
7. RDBMS
Data Storage
– Rows and columns (Tabular Form)
Features
– Simple, better performance of managing data
– Mathematical foundation (Relational Algebra)
– Flattening and scattering -> unnatural
– Limitations: everything doesn't fit in relations
– Conversion needed (impedance mismatch)
8. NoSQL and OODBMS
Data Storage
– Object Form
Features
– No conversion needed (no impedance mismatch)
– Relationships are directly represented, rather than requiring
join tables/operations
– Better at modeling complex objects
– No mathematical foundation
– Don’t have maturity of RDBMS yet
9. Incompatible Type Systems
● During systems collaboration if systems found having
different type systems, they are said to be Incompatible
Type Systems and can't interact with each other without an
interface. E.g. OO Applications and RDBMS.
● A mechanism/solution is needed to overcome this
incompatibility gap for proper collaboration.
11. What is an ORM?
● It is a programming technique for converting data between
incompatible type systems in object-oriented programming
languages.
12. Why to use ORM?
● Many popular database products such as structured query
language database management systems (SQL DBMS) can
only store and manipulate scalar values such as integers
and strings organized within tables. The programmer must
convert the object values for storage in the database into
groups of simpler values (and convert them back upon
retrieval).
● For most of the data-access code that developers usually
need to write, it eliminates.
13. Problems with ORM
● Object-Relational Impedance Mismatch (paradigm
mismatch) is a way of saying that object models and
relational models do not work very well together. Loading
and storing graphs of objects using a tabular relational
database exposes 5 mismatch problems.
– Granularity
– Subtypes (inheritance)
– Identity
– Associations
– Data navigation
14. Types of ORM
● Entity-based relational mapping
– Change tracking, Lazy-loading, Eager fetching, Cascades, Identity map, Unit of work
tracking
● Result-set-based relational mapping
– Map straight to DTOs and skip needing to configure mapping
● DML-based relational mapping (micro ORMs)
– SQL is brought to the forefront, mapping on the fly and only need a connection
● Bulk loading tools
– Limited to INSERT and SELECT
17. Why Dapper ?
● Simple object mapper for .Net
● Performance is a key feature
18. Why Dapper is Simple/ Lightweight?
● Many feature that ORMs ship with are stripped out, there is
no identity map, there are no helpers for update/select
and so on.
● Dapper does not manage your connection's life cycle, it
assumes the connection it gets is open AND has no existing
data readers enumerating.
21. Dapper in Action
● Dapper is a “single file” (SqlMapper.cs) that will extend
your IDbConnection interface.
● It provides 3 helpers:
– Execute a query and map the results to a strongly typed
List
– Execute a query and map it to a list of dynamic objects
– Execute a Command that returns no results
28. Limitations of Dapper?
● Many feature that ORMs ship with are stripped out, there is
no identity map, there are no helpers for update/select and
so on.
● Dapper does not manage your connection's life cycle, it
assumes the connection it gets is open.
30. Configurations (Most hectic activity)?
Surprisingly!!! No configuration needed in project, just add
reference to the library and you are done.
– Reasons
● It uses existing db connection (extends IDbConnection).
● It just does object mapping, nothing else as mentioned in
features.
32. Dapper and DB providers
● Dapper has no DB specific implementation details, it works
across all .Net ADO providers including sqlite, sqlce,
firebird, oracle, MySQL, PostgreSQL and SQL Server.
33. Conclusion
● Simple and lightweight to implement / use.
● Provide enough helpers/ support to do ORM activities.
● Doesn't suppress developers SQL skills.
34. Recommendation (Hybrid Approach)
● Dapper was written with speed (not features) as a priority.
● Using Dapper felt like writing SQL, which majority of developers
avoid when possible.
● For Entity Framework slowness issue, replace queries with
either a view or a stored procedure, depending on the
situation.
● Hybrid approach: Use EF for normal cases due to ease and use
Dapper where performance boost in needed.