Why we use ORM EF NHibernate ???

We are using Data Mapper + Domain Model + Service Layer + Repository + UOW from MF Patterns of EAA in the modern OCH based Applications and Frameworks. 

Why we use ORM EF NHibernate?
What advantages they give us?

ORMs are used to do the complex work of OR mappings. It started out this way. 

Now a days ORM do much more than ORM, it also solves the problems DDD. 

For example it also do the Code First Migrations and sync. the Domain Model with the DB Schema.

According to DDD, we do not touch the DB Schema, is derived by the Domain Model Data Part.

ORM support Data Annotations, Conventions over Configurations, and Fluent APIs to map the Domain Model to the DB Schema.

It does the Dirt Low Level ADO.NET level work. 

It does the Dirty Work of Transactions Management and Concurrency and Locks and Inconsistent Reads, Tracking of Changes in the in memory Data. 

In the end of the day, ORM present us with the OO Version of the Database Data wrapped inside an OO Domain Model API.

We play with this API like the OO API, in-memory collection of objects

Benefits of ORMs or Repositories

EF vs. ADO.NET based Data Source Patterns

Data Source Patterns are used to encapsulate the Data Access Code.

Data source patterns

·       Table Data Gateway Pattern

·       Row Data Gateway Pattern

·       Active Record Pattern

·       Data Mapper Pattern

Previously we have

Table Data Gateway è Data Access API è Relational Database

DAO/DTO è ADO.NET è SQL Server

Now days, every Enterprise Application is leveraging some ORM based Repositories to do the dirty work of Relational Data Access. NHibernate, EF, Dapper etc.

Repository è ORM è Data Access API è Relational Database

Repository è EF è ADO.NET è SQL Server

EF is layer of abstraction on the top of ADO.NET

It provides its own Object based Query language to query the DB

EF is totally Repository and UOW based, it provides whole DB as the in-memory collections.

Whole DB is mimicked as the in memory collections and we change them and call save as we are saving them in the memory, but at runtime query is generated and data is also saved in DB as well. Data is saved in both DB and memory.

In Microsoft world, Asp.net MVC, EF is the default way to go. No one seems to do the ADO.NET. It saves us from the lot of dirty data access code like

·       Making Connection

·       Closing Connection

·       Exception handling in the Data access layer

·       Error messaging in the Data Access Layer

·       SQL Queries

·       Transactions Management

·       Fetching the Data from ResultSets and mapping them to DTOs.

·       Changing the DAL when the schema changes and changing all above stuff.

This whole stuff is now abstracted under the EF/ORM. We lose flexibility but gained a lot by saving us from such a dirty work of ADO.NET.

Previously,           Data Source Patterns è ADO.NET

Now,                     Data Source Patterns è EF

Now, the Data Source Pattern Classes used to encapsulate the Data Access Code are much more simplified and with very less code.

Also these ORMs help us to the DDD with Code First Migrations

DDD help us separate the Domain Model

ORM help us sync the Domain Model and Database Schema by Code First Migrations

How DDD and ORMs are related?

How ORM support the DDD?

How ORM, DDD and Code First Migrations are related to each other?

According to DDD, Domain Model is core to the EA.

Domain Model should drive the Database Schema.

Latest ORMs support these phenomena by supporting the Code First Migrations.

C# Language also supports the Data Annotations to decorate the Domain Model with elements those help in translating Domain Model to the Database Schema

 C# Language also supports the Default Conventions, Data Annotations and Fluent APIs to specify the Database Schema elements in the Domain Model.

It is not primary job of ORM to update the Database Schema.

Primary job of ORM is, at runtime, to map Table Data to the Objects and vice versa. (OR Data Mapping)

Secondary job of ORM is to map Object Structure to the Database Schema and vice versa. (OR Structure Mapping/ OR Schema Mapping)

EF is he layer of Abstraction on the top of ADO.NET.

EF is an ORM. There are many.

There is no objection on the ORM libs.

EF was criticized of being a poor ORM that was poorly designed and was misfit at that time against the matured ORMs libs.

These ORMS/EF save us from the dirty, repeative, low level work of Connection management, SQL Queries, Fecting Data in the Data Containers. We have to write lot lot code. Previously in 2005 our Data Access layers were too much bulky and huge. Although generated but still they were messy.

Now Data Access Layers are at higher level of abstraction. They are clean nice and short and succinct. They are now easy to generate. Due to functional programming and Templates, they are even more easy to code.