orm methodology

26
ORM METHODOLOGY AHMED GOMAA LEAD SOFTWARE ENGINEER [email protected]

Upload: ahmed-gomaa

Post on 16-Jul-2015

253 views

Category:

Technology


1 download

TRANSCRIPT

ORM METHODOLOGY

AHMED GOMAA

LEAD SOFTWARE ENGINEER

[email protected]

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

WHAT IS ORM ?!

in computer science is a programming technique for converting data between incompatible typesystems in object-oriented programming languages. This creates, in effect, a "virtual object database" thatcan be used from within the programming language.

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.

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 aredeployed on diverse platforms.

• Enables collaboration between systems on different operatingsystems, programming languages, and computing hardware.

• CORBA has many of the same design goals as object-orientedprogramming: encapsulation and reuse.

• CORBA uses an object-oriented model although the systems thatutilize CORBA do not have to be object-oriented.

OBJECT-RELATIONAL IMPEDANCE MISMATCH

The object-relational impedance mismatch is a set of conceptual and technical difficulties that are oftenencountered when a relational database management system (RDBMS) is being used by a program writtenin an object-oriented programming language or style; particularly when objects or class definitions aremapped in a straightforward way to database tables or relational schema.

OBJECT-RELATIONAL IMPEDANCE MISMATCH

'Object-Relational Impedance Mismatch' is just a fancy way of saying that object models and relationalmodels 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 andstoring graphs of objects using a tabular relational database exposes us to 5 mismatch problems

• Granularity

• Subtypes (inheritance)

• Identity

• Associations

• Data Types

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{

}

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

IDENTITY

• A RDBMS defines exactly one notion of 'sameness‘

• Java, however, defines both object identity a==b and object equality a. equals(b) .

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 {

}

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

ORM COMPONENTS

1. Mapping

2. Reflection, Projection and Hydration

3. SQL Query Builder

4. Fetching

5. Caching and persistence

6. Settings

ORM COMPONENTS : MAPPING

1. Physical (Storage Model) SSDL

2. Logical (Conceptual Model) CSDL

3. Mapping Model MSL

ORM COMPONENTS : SQL QUERY BUILDER

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.

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.

ORM COMPONENTS : SETTINGS

• XML

• MetaData

• Database

• File Storage

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.

COMPARISON

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

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.

DEMO

WHAT NEXT ?!

• Entity Framework Architecture

• How to use Entity Framework

Q & A

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/