this presentation about the ORM methodology and how is works and how to select an ORM for your project

1. ORM METHODOLOGY
AHMED GOMAA
LEAD SOFTWARE ENGINEER
GOMAA86@GMAIL.COM

2. OUTLINES
1. What is ORM ?!
2. Why ORM ?!
3. What is CORBA ?
4. Problem: Object-relational impedance mismatch
5. ORM Components and Architecture
6. Disadvantages of ORM
7. Comparison
8. Choosing an ORM tool
9. Demonstration of ORM using Micro ORM
10. What Next ?!
11. Q & A
12. References

3. WHAT IS ORM ?!
in computer science is a programming technique for converting data between incompatible type
systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that
can be used from within the programming language.

4. WHY ORM ?!
• Speeds-up Development - eliminates the need for repetitive SQL code.
• Reduces Development Time.
• Reduces Development Costs.
• Overcomes vendor specific SQL differences - the ORM knows how to write vendor specific SQL so you
don't have to.
• Rich query capability. ORM tools provide an object oriented query language.

5. WHAT IS CORBA ?!
• Common Object Request Broker Architecture (CORBA)
• A standard defined by the Object Management Group (OMG)
designed to facilitate the communication of systems that are
deployed on diverse platforms.
• Enables collaboration between systems on different operating
systems, programming languages, and computing hardware.
• CORBA has many of the same design goals as object-oriented
programming: encapsulation and reuse.
• CORBA uses an object-oriented model although the systems that
utilize CORBA do not have to be object-oriented.

6. OBJECT-RELATIONAL IMPEDANCE MISMATCH
The object-relational impedance mismatch is a set of conceptual and technical difficulties that are often
encountered when a relational database management system (RDBMS) is being used by a program written
in an object-oriented programming language or style; particularly when objects or class definitions are
mapped in a straightforward way to database tables or relational schema.

7. OBJECT-RELATIONAL IMPEDANCE MISMATCH
'Object-Relational Impedance Mismatch' is just a fancy way of saying that object models and relational
models do not work very well together. RDBMSs represent data in a tabular format , whereas object-
oriented languages, such as Java, C# represent it as an interconnected graph of objects. Loading and
storing graphs of objects using a tabular relational database exposes us to 5 mismatch problems
• Granularity
• Subtypes (inheritance)
• Identity
• Associations
• Data Types

8. GRANULARITY
Sometimes you will have an object model which has more classes than the number of corresponding
tables in the database
public class Teacher{
}
public class School{
}

9. SUBTYPES (INHERITANCE)
• Inheritance is a natural paradigm in object-oriented programming languages. However, RDBMSs do not
define anything similar to Inheritance
Human
Man Woman
Inheritance

10. IDENTITY
• A RDBMS defines exactly one notion of 'sameness‘
• Java, however, defines both object identity a==b and object equality a. equals(b) .

11. ASSOCIATIONS & DATA NAVIGATION
• Associations are represented as unidirectional references in Object Oriented languages whereas
RDBMSs use the notion of foreign keys. If you need bidirectional relationships in C#, you must define
the association twice
• The way you access data in Java or C# is fundamentally different than the way you do it in a relational
database. In Java or C# you navigate from one association to an other walking the object network.
Class user_main {
Teacher teacher;
}
Class Teacher {
}

12. DATA TYPES
• When we consider about data types there a mismatches, simply String might have limited size than a
varchar data type
• String Varchar(150)
• Mismatches Between Date and time in the object world and the relational world

13. ORM COMPONENTS
1. Mapping
2. Reflection, Projection and Hydration
3. SQL Query Builder
4. Fetching
5. Caching and persistence
6. Settings

14. ORM COMPONENTS : MAPPING
1. Physical (Storage Model) SSDL
2. Logical (Conceptual Model) CSDL
3. Mapping Model MSL

16. ORM COMPONENTS : SQL QUERY BUILDER

17. FETCHING
• Basically when you think about it, a class is just another data type.
• However unlike say an int, we really don't want to load it when the rest of the class is loaded.
• we might end up loading our entire database or even end up in an endless loop of loading.
• So what most ORM do to combat this is use something called lazy loading.
• Lazy loading is simply a design pattern where you load/initialize an object only when it is needed.
• Lazy loading Levels
• for the data through relations
• for some columns. When we want to display just a list of names, we don't need all the columns of a table to be
loaded. We may need the blob fields only at certain point, under certain conditions, and so it's better to load
them only at that time.

18. ORM COMPONENTS : CACHING AND OPTIMIZATIONS
• Lazy loading (the loading of some data is deferred until it's needed)
• for the data through relations
• for some columns. When we want to display just a list of names, we don't need all the columns of a table to be loaded. We may need the blob fields
only at certain point, under certain conditions, and so it's better to load them only at that time.
• Cache dynamically generated queries, so that they don't get rebuilt at each call.
• Cache some data to avoid too many calls to the data source.
• Optimized queries (update only the modified columns; detect situations where the number of executed queries can be reduced; ...)
• Handle circular references without duplication of objects ("account == account.Client.Account")
• Handle cascade updates. Deleting a master record should delete the linked details if wished so.
• Bulk updates or deletions. When we want to update or delete thousands of records at a time, it's not possible to load all the objects
in memory, while this can be easily and quickly done with a SQL query (DELETE FROM Customer WHERE Balance < 0). Support from
the tool is welcome to handle such massive operations without having to deal with SQL. Hibernate is not very good on this point for
example.

19. ORM COMPONENTS : SETTINGS
• XML
• MetaData
• Database
• File Storage

20. DISADVANTAGES OF ORM
• ORM adds a least one small layer of application code, potentially increasing processing overhead.
• ORM can load related business objects on demand.
• An ORM system's design might dictate certain database design decisions.

21. COMPARISON
• http://en.wikipedia.org/wiki/Comparison_of_object-relational_mapping_software

22. CHOOSING AN ORM TOOL• Be able to use inheritance
• Handle any type of relations (1-1, 1-n, n-n)
• Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
• Support for grouping (SQL's GROUP BY)
• Support for transactions
• Supported databases.
• Query language (OQL - Object Query Language, OPath).
• Support for DataBinding
• Customization of queries.
• Support any type of SQL joins (inner join, outer join)
• Concurrency management (support for optimistic and pessimistic approaches)
• Support for the data types specific to the database management system (identity columns, sequences,
GUIDs, autoincrements)
• Be able to map a single object to data coming from multiple tables (joins, views).
• Be able to dispatch the data from a single table to multiple objects.

23. DEMO

24. WHAT NEXT ?!
• Entity Framework Architecture
• How to use Entity Framework

25. Q & A

26. REFERENCES
• http://www.codeproject.com/Articles/17269/Reflection-in-C-Tutorial
• http://csharp.net-tutorials.com/reflection/introduction/
• http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
• http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
• http://en.wikipedia.org/wiki/Object_database
• http://www.artima.com/intv/abstract3.html
• http://en.wikipedia.org/wiki/Object-relational_mapping
• http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
• http://hateraide.codeplex.com/