Wednesday, January 19, 2011

There is no doubt that any non-trivial application has a database behind it which often presents a problem when dealing with object oriented Code. Confusion between dealing with data base based on relational algebra concepts and modern programming languages based on object oriented Concepts is most annoying problem for any programmer as You may ask , hi guys I have inheritance scenario how can I connect it for data base tables in proper way?

This question and all other puzzled questions have a magic answer when you start to use ORM tools.

What is ORM?

ORM stands for Object relational Mapping. ORM is an attempt to map the notion of object and relational world so that they can talk to each other in an easy way. Using an (ORM) allows one to cleanly apply object-oriented design, analysis, and programming techniques while hiding the specifics of dealing with the relational system.  This creates, in effect, a "virtual object database" that can be used from within the programming language. You can say that ORM means "write less code".

It is the best mechanism that makes it possible to address access and manipulate objects without having to consider how those objects relate to their data sources. ORM lets programmers maintain a Flair Systems - ORM consistent view of objects over time, even as the sources that deliver them, the sinks that receive them and the applications that access them change.

Based on abstraction, ORM manages the mapping details between a set of objects and underlying relational databases, XML repositories or other data sources and sinks, while simultaneously hiding the often changing details of related interfaces from developers and the code they create.

ORM hides and encapsulates change in the data source itself, so that when data sources or their APIs change, only ORM needs to change to keep up—not the applications that use ORM to insulate themselves from this kind of effort. This capacity lets developers take advantage of new classes as they become available and also makes it easy to extend ORM-based applications. In many cases, ORM changes can incorporate new technology and capability without requiring changes to the code for related applications.

Why I should use ORM?

  • To have a rich, object oriented business model and still be able to store it and write effective queries quickly against a relational database.

  • To minimize duplication of simple SQL queries.

  • To can move to different any data base type easily because you are developing to an abstraction.

  • To get huge reduction in code. ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD logic.

  • Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

  • To completely configure data loads by allowing you to load the data appropriate for each scenario (Lazy Loading or Eager Loading).

  • To manage keys. Identifiers and surrogate keys are automatically propagated and managed.

  • To manage and isolate Transactions. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transaction changes are isolated form on another.

  • To facilitate implementing the Domain Model pattern which means that you model entities based on real business concepts rather than based on your database structure.

  • To offer concurrency and caching methodology to your code.

You can think that ORM is Full Optimal solution for your problems but really there is always no optimal solution for all cases.

Disadvantages of O/R mapping tools are in areas where proprietary or database-specific techniques have been highly optimized. Most O/R mapping tools do not perform well during bulk deletions of data or joins (even simple ones). Stored procedures may have better performance, but are not portable.

At all you will think in an ORM as a perfect solution for more daily business cases Smile and Say: "Good bye SQL strings!"

Some Used References:

Eng. Ahmed Emad

Senior Software Engineer
Flair Software House


Anonymous said...

طب أنا عندي سؤال
هي ايه هي ال

Ahmed Emad said...

تحديدا تقدر تقول انها وسيط بين الداتا بيز والمودل الي شغال عليه البرنامج بتاعك الوسيط دا مسئول إنه يدير كل العمليات الخاصة بالداتا بيز ويعزلها عن الكود بحيث إنك تقدر تتعامل مع الداتا بيز من خلال objects من الموديل بتاعك بدون الدخول في اي تفاصيل او كتابة أكواد للconnection بنفسك.

كل دا بيتم عن طريق ال Mapping
الي بيمكن كل طرف منهم انه يفهم التاني.

أوضح مثال ليها هو الEntityFramework
تابعنا وإن شاء الله هنتكلم أكتر في الموضوع.

Annie Calvert said...

This article has something unique in it. Its written very well. Its always good to come to know about new technology.thanks for the article.