This project is read-only.

Introducing OORM Concepts

The days of embedded structured query language is gone. The days of stored procedure are numbered; also the days of partial object relational mapping (ORM) are numbered as well. Coming into the limelight is the talk of the industry, “The Object Oriented Relational Mapping” (OORM).
  • Note the use of the abbreviation OORM over ORM, this is because some relational mapping frameworks under the name ORM neglects the true Object Oriented Programming Nature of OOP when you map with them. But to remind the ORM community, we are not mapping data and object, one for one, but we are mapping properties of an object to a persistent storage. Thereby we will not be loosing the true nature of OOP fundamentals, inheritance, polymorphism, abstraction, encapsulation, resilience to changes, re-usability, decupling, persistent ignorance etc.
  • Segregation  between  applications  layers  in  a  distributed  computing  system  have  really  changed  the  way  software are written  because this  contributed  to  the  adoption  of  clean  and  clear  coding  practices  that  form  the  blueprints  for  a  reusable  software  API/frameworks  across    tiers  and  platforms.  You  could  imagine  a  framework  that  caters  for  standalone  applications  plus  a  thin  client  application  and  mobile  application  at  the  same  time.    Such  framework  is  a  success  to  organizations  because  of  its  productivity  gains  in  the  area  of  reusability and maintainability.  This framework is known as Object Oriented Relational Mapping (OORM).
  • When you engineer data access application that requires an extensive use of relational database using an OOP programming language of your choice, the data usage and the  overhead  involved  in  the  development  of  such efficient  relational  data  access  layer  have  shifted  the  paradigm  from  coupling  persistence  logic  within  application  to  industry  standard  object  oriented  data  access  designs.  In the bad old days the Data  Access  Objects  (DAO)  was  the  preferred standards  of  building  data  access  layer  components  that  can connect  applications  to  databases;  This  approach  can introduce  hard  coding  of Structured  Query  Language  (SQL)  and stored procedure statements  into  the  components  that  connects  to  the  database.  It  can also introduce the difficulty of maintaining good quality source code,  can encourage poor  coding  styles  and  design  standards,  changes  to  database  designs  requires  complex  changes. 
  • Software  engineers\developers\programmers\architects  have  lived  with  this  poor  approaches,  but  with  the  introduction  of  Object  Oriented to  Relational  Mapping  (OORM)  and  mapping  tools;  data  access  development in an object oriented manner couldn’t have been better.

Application layers and architectureIn  a  distributed  system,  such  that  spans  several  computing  servers,  hardware’s,  processes  and  platforms.  Several  application  layers  must  conform,  communicate  and  exchange  information  geographically  in  an  heterogeneous  environment.  This  type  of  architecture  needs  to  transmit  data  as  serialized  objects;  different  types  of  servers  and  computing  platforms  that  consume  the  transported  object  must  understand  and  certify  the  way  the  data  will  be  serialized  in  other  to  de-serialize  and  consume  the  data.  Objects  that  were  mapped  to  relational  databases  can  be  serialized  and  wired  over  the  network  to  another  listening  application\layer  that  will  consume  and  use  the  information  collected  from  the  transported  object  model.  The  types  of  application  layers  that  serves  as  listeners  are  as  follows:  web  services,  message  oriented  service  (JMS,  MSMQ),  client  server  system.  At  the  center  of  this  application  layers  you  will  find  the  domain  object  which  are  the  objects  that  represent  the  mapping  between  object  orientation  and  relational  paradigm.


Full details of the above diagram:
  • User  Interface:  The  user  interface  is  an  entry  point  for  human  interaction  with  the  application  as  designed  in  Figure  1.  User  interfaces  may  target  different  computing  devices  ranging  from  laptops,  mobile  devices;  palm  tops  etc  it  mainly  focused  on  data  presentation/rendering.  This  layer  makes  use  of  the  domain  object,  by  rendering  the  data’s  contained  in  the  domain  object  to  the  users.
  • Domain  Object:  The  domain  objects  are  the  models  that  map  to  relational  table,  they  are  data  centric  and  in  figure  1,  the  domain  objects  is  accessible  by  all  the  application  layers  in  the  diagram;  it  can  also  be  consumed  by  servers  running  on  heterogeneous  computing  environment  and  also  mainframe  computers.  The  domain  objects  represent  data  alone  and  do  not  contain  data  manipulation  functionalities.
  • Business  Logic:  This  layer  models  the  business  requirements  of  an  application,  this  is  where  the  business  needs  of  the  application  are  implemented  and  it  makes  excessive  use  of  the  domain  object.
  • Persistent  Framework:  The  domain  objects  cannot  populates  itself  with  data  from  the  relational  database,  it  cannot  save  the  modifications  made  to  it  into  the  database,  so  it  requires  a  framework  that  understands  both  the  object  oriented  paradigm  and  the  relational  paradigm,  this  framework  is  like  a  factory  that  manufactures  and  populates  all  the  domain  objects  required  by  the  application  at  runtime.  The  architecture  diagram  above  leverages  data  persistent  framework  for  object  persistent  and  fetching.  The  Create  Update  Delete  (CRUD)  operations  against  the  relational  databases  are  performed  by  the  persistent  framework  as  to  ensure  a  single  entry  point  and  reusability  at  the  code  level,  which  is  one  of  the  greatest  successes  of  this  layer  (Code  reduction.  which  makes  extensibility  painless).  The  persistent  framework  also  serves  as  a  bridge  between  data  persistence/logic  and  the  underlying  database,  in  other  words,  the  persistent  framework  is  database  independent  as  you  can  see  from  the  diagram  pointing  to  the  two  databases  (Microsoft  SQL  server  and  Oracle),  and  it  supports  various  SQL dialects.  The  Framework  communicates  with  other  layers/APIs  by  passing  objects  (domain  object)  mapped  to  database  tables.

The  need  for  mapping  OO  to  RDBMS Object  oriented  programming  (OOP)  is  already popular  and widely used in  today’s  software  development  because in the mordern day development, nearly  all  systems  were  built  using  OOP.  Legacy  systems  written  in  procedural  languages  like  C, COBOL are beign reverse engineered to conform to the OOP pattern.  When  developing with an in an OOP platform like .NET, it  is  required  that  you  follow  all  the  semantics  of  OOP,  because  the  mixture  of  procedural  methodology  with  object  orientation  will  not  only  break  the  rules  of  object  oriented  design  patterns,  but  also,  it  will  promote code smell, and a bug riden system.  The  following  are  the  advantages  for  mapping  OO  to  RDBMS: 

Advantage  of  mapping  OO  to  RDBMS: 
  • Portable  Abstraction  layer:  Object  to  relational  mapping  is  pattern  oriented  approach  for  building  an  effective  data  layer  that  span  multiple  databases  and  cut  across  many  applications  that  are  common  in  the  software  industry.    Mapping  OO  to  RDBMS  introduce  another  abstraction  layer  in  the  architecture  of  an application,  it  makes  for  a  reusable  entity  layer  that  can  span  multiple  applications  without  having  to  make  changes  to  existing  application  at  source  code  level.  An  application  that  maps  between  the  two  paradigms  needs  to  be  designed  with  respect  to  performance,  maintainability  and  cost  to  name  just  a  few  requirements  (Keller,  1998)
  • Loosely  coupled  ness:  One  of  the  most  debated  OO  to  RDBMS  problems  today,  is  the  data  coupling  between  the  two  application  layers.  The  coupling  introduces  an  extra  overhead  when  there  is  a  need  for  migration  from  databases  or  when  new  changes  are  made  to  database  schema.  When  data  access  application  layer  codes  are  coupled  within  the  business  needs  of  an  application,  this  makes  the  application  tied  down  to  the  database;  it  becomes  very  messy  when  having  to  use  such  code  with  another  relational  database  system.  The  basic  purpose  of  ORM  is  to  allow  an  application  written  in  an  object  oriented  language  to  deal  with  the  information  it  manipulates  in  terms  of  objects,  rather  than  in  terms  of  database-specific  concepts  such  as  rows,  columns  and  tables  (Mirleid,  2006)
  • Paradigm  Mismatch:  Object  oriented  programming  languages  are  becoming  the  choice  languages  used  to  build  software  in  today’s  application  development  as  well  as  relational  databases  are  being  excessively  used  in  the  industry.  An  object  oriented  language  such  as  Java  and  C#,  makes  use  of  classes\Interfaces  as  data  and  behaviors  (Methods)  as  set  of  instructions  that  manipulate  the  data.  Object  oriented  languages  needed  to  interact  with  RDBMS  for  data  persistence,  and  because  of  the  differences  in  the  paradigm  used  by  both,  there  was  a  need  for  data  frameworks  that  can  be  used  to  bridge  the  two  paradigms  together  using  the  relational  mapping  approach.
  • High  productivity  gain:  There  are  productivity  gains  in  using  the  relational  mapping  approach  to  combine  the  RDBMS  and  object  orientation  as  a  single  design. Developers improve their productivity and maintainability while using object oriented technologies. There  are  several  tools  that  support  the  Object  to  relational  mapping  approach,  these  tools  allows  for  mapping  the  tables  to  classes,  columns  to  properties  of  a  class  and  auto  generation  of  the  mapped  code.  For  example,  if  we  were  supposed  to  map  a  hundred  database  tables  to  object  oriented  classes;  we  could  start  to  imagine  that  this  will  lead  to  writing  a  hundred  classes  with  columns  mapped  to  class  properties.  If  the  mapping  were  to  be  done  by  human,  this  will  lead  to  so  many  errors  and  it  will  take  longer  time  to  write  the  codes  that  maps  the  two  paradigms.  The  auto  generation  of  mapped  classes  saves  a  lot  of  time  and  money  by  shifting  the  software  engineer’s  concentration  away  from  persistent  implementation  to  business  logic  implementation. 

Last edited Jun 14, 2009 at 11:36 AM by ahmedsalako, version 10


No comments yet.