Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-08-01T21:51:39Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

[http://www.rubyonrails.org/ ROR (Ruby-on-Rails)] has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

# '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
# '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
# '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

# Simple to implement
# Good for existing database with new applications
# Less time spend on OO modeling
# Good choice for simple problems

*''' Cons '''

# Centered around Data Modeling
# Not use full capabilities of OO modeling
# Too simple for complex models

=== Data Access Object (DAO) Pattern ===
# '''Introduction'''

This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

* '''Example'''

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

* '''Framework/Library support '''

# '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
# '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
# '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

*''' Pros '''

# Supports full OO modeling approach in layered application.
# Allows object persistence to be easily coupled with business logic
# Hides the complexities associated with database manipulation (no SQL)
# Through some framework support, it could be transparent.
# It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

*''' Cons '''

# Hard to implement but with support of latest frameworks it is getting quite easy
# It requires layer approach for application design.
# Not suitable for simple solution.
# It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T22:02:52Z

Arashid: /* Data Access Object (DAO) Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

# '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
# '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
# '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

# Simple to implement
# Good for existing database with new applications
# Less time spend on OO modeling
# Good choice for simple problems

*''' Cons '''

# Centered around Data Modeling
# Not use full capabilities of OO modeling
# Too simple for complex models

=== Data Access Object (DAO) Pattern ===
# '''Introduction'''

This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

* '''Example'''

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

* '''Framework/Library support '''

# '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
# '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
# '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

*''' Pros '''

# Supports full OO modeling approach in layered application.
# Allows object persistence to be easily coupled with business logic
# Hides the complexities associated with database manipulation (no SQL)
# Through some framework support, it could be transparent.
# It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

*''' Cons '''

# Hard to implement but with support of latest frameworks it is getting quite easy
# It requires layer approach for application design.
# Not suitable for simple solution.
# It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T22:00:39Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

# '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
# '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
# '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

# Simple to implement
# Good for existing database with new applications
# Less time spend on OO modeling
# Good choice for simple problems

*''' Cons '''

# Centered around Data Modeling
# Not use full capabilities of OO modeling
# Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T22:00:14Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

# '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
# '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
# '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

* Simple to implement
# Good for existing database with new applications
# Less time spend on OO modeling
# Good choice for simple problems

*''' Cons '''

# Centered around Data Modeling
# Not use full capabilities of OO modeling
# Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:59:42Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

* Simple to implement
# Good for existing database with new applications
# Less time spend on OO modeling
# Good choice for simple problems

*''' Cons '''

# Centered around Data Modeling
# Not use full capabilities of OO modeling
# Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:59:12Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''

* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems

*''' Cons '''

* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:58:45Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

*''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

*''' Pros '''
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
*''' Cons '''
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:58:04Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
*'''Introduction'''
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

*'''Example'''
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

''' Pros '''
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
''' Cons '''
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:57:21Z

Arashid: /* Active Record Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
'''Introduction'''
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

'''Example'''
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

''' Frameworks/Library support '''

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

''' Pros '''
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
''' Cons '''
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:55:04Z

Arashid: /* Techniques for merging Relational and OO models */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

*'''Minimize the differences'''
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
*'''Compensation'''
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-28T21:54:15Z

Arashid:

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
#'''Encapsulation'''
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
#'''Data type differences'''
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
#'''Structural and integrity differences'''
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
#'''Manipulative differences'''
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
#'''Transactional differences'''
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:37:13Z

Arashid: /* Frameworks/Library support */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - [http://www.rubyonrails.org/ Ruby-on-Rail](ActiveRecord)
* '''Java''' - [https://jactiverecord.dev.java.net/ JactiveRecord], [https://jactiverecord.dev.java.net/ ARJ], [http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping ActiveMapper]
* '''.NET''' - [http://www.castleproject.org/ Castle Project]

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:34:42Z

Arashid: /* Framework/Library support */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – [http://www.hibernate.org/ Hibernate], [http://java.sun.com/javaee/technologies/persistence.jsp JPA Java JEE Persistence], [http://db.apache.org/ojb/ OJB], [http://ibatis.apache.org/ iBATIS]
* '''.NET''' – [http://www.nhibernate.org/ nHibernate], [http://msdn.microsoft.com/en-us/vbasic/aa904594.aspx LINQ],[http://ibatis.apache.org/ iBATIS]
* '''Ruby''' - [http://ibatis.apache.org/ iBATIS]

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:27:43Z

Arashid: /* Example */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

[http://www.hibernate.org/ Hibernate] is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The [http://www.hibernate.org/ Hibernate website] has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – Hibernate, JEE Persistence, OJB, iBATIS
* '''.NET''' – nHibernate, JingDAO, iBATIS

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:27:17Z

Arashid: /* Links */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

Hibernate is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The Hibernate website has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – Hibernate, JEE Persistence, OJB, iBATIS
* '''.NET''' – nHibernate, JingDAO, iBATIS

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29
* http://www.hibernate.org/

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:26:31Z

Arashid: /* Conclusion */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

Hibernate is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The Hibernate website has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – Hibernate, JEE Persistence, OJB, iBATIS
* '''.NET''' – nHibernate, JingDAO, iBATIS

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:25:38Z

Arashid: /* Data Access Object (DAO) Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

==== Example ====

Hibernate is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The Hibernate website has a [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html nice tutorial] to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence,

private void createAndStoreEvent(String title, Date theDate) {

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(theDate);
session.save(theEvent);
session.getTransaction().commit();
}

This code stores new event to backend database.

==== Framework/Library support ====

* '''Java''' – Hibernate, JEE Persistence, OJB, iBATIS
* '''.NET''' – nHibernate, JingDAO, iBATIS

==== Pros ====

* Supports full OO modeling approach in layered application.
* Allows object persistence to be easily coupled with business logic
* Hides the complexities associated with database manipulation (no SQL)
* Through some framework support, it could be transparent.
* It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

==== Cons ====

* Hard to implement but with support of latest frameworks it is getting quite easy
* It requires layer approach for application design.
* Not suitable for simple solution.
* It doesn’t easily support working on existing database with complex model (with long tree of objects).

== Conclusion ==
== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:22:15Z

Arashid: /* Data Access Object (DAO) Pattern */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

[[Image:Dataaccessobject.gif]]

== Conclusion ==
== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29

File:Dataaccessobject.gif

2008-07-26T22:21:50Z

Arashid: Data Access Object (DAO)

Data Access Object (DAO)

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:21:01Z

Arashid: /* Object/Relational Mapping (ORM) Patterns */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

=== Data Access Object (DAO) Pattern ===
==== Introduction ====
This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

== Conclusion ==
== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:17:52Z

Arashid: /* Object/Relational Mapping (ORM) Patterns */

= WIKI Topic - RDB/OO patterns=
:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =
This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

= Relational Vs Object-Oriented Models =
== Relational Models ==
This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

# Domain/data type
# Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say ''"A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."''

== Object-Oriented Models ==

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

== Differences between Relational Vs Object-Oriented Models ==
The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,
=== Relational Model example (Customer and Customer Address) ===
[[Image:Relational.gif]]
=== Object Oriented Model example (Customer and Customer Address) ===
[[Image:oomodel.gif]]

=== Mismatches ===
==== 1. Encapsulation ====
OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.
==== 2. Data type differences ====
Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.
==== 3. Structural and integrity differences ====
OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.
==== 4. Manipulative differences ====
Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.
==== 5. Transactional differences ====
This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

== Techniques for merging Relational and OO models ==
So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

=== Minimize the differences ===
Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.
=== Compensation ===
In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

== Object/Relational Mapping (ORM) Patterns ==
As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.
=== Active Record Pattern ===
==== Introduction ====
This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

==== Example ====
ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class.

class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table.

Create table employees(
id:int,
first_name varchar(100),
last_name varchar(100),
email varchar(100),
PRIMARY KEY (id)
);

Now let’s create a new employee,

employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database,

insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy,

employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend,

select * from employees where first_name = ‘Ben’

==== Frameworks/Library support ====

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

* '''Ruby''' - Ruby-on-Rail(ActiveRecord)
* '''Java''' - JactiveRecord, ARJ, ActiveMapper
* '''.NET''' - Castle Project

==== Pros ====
* Simple to implement
* Good for existing database with new applications
* Less time spend on OO modeling
* Good choice for simple problems
==== Cons ====
* Centered around Data Modeling
* Not use full capabilities of OO modeling
* Too simple for complex models

== Conclusion ==
== Links ==
* http://en.wikipedia.org/wiki/Object-relational_mapping
* http://www.theserverside.com/news/thread.tss?thread_id=40581
* http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm
* http://martinfowler.com/eaaCatalog/
* http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
* http://www.lhotka.net/Article.aspx?id=ff226256-903f-4aee-a921-8b09ef40901b
* http://en.wikipedia.org/wiki/Object-relational_database
* http://gilbane.com/ctoblog/2007/09/relational-and-objectoriented.html
* http://www.geocities.com/tablizer/core1.htm
* http://c2.com/cgi/wiki?RelationalModel
* http://www.agiledata.org/essays/impedanceMismatch.html
* http://en.wikipedia.org/wiki/ActiveRecord_%28Castle%29

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:14:49Z

Arashid: /* Object/Relational Mapping (ORM) Patterns */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-26T22:13:51Z

Arashid: /* Object/Relational Mapping (ORM) Patterns */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:53:35Z

Arashid: /* Object/Relational Mapping (ORM) Patterns */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:52:26Z

Arashid: /* Techniques for merging Relational and OO models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:44:42Z

Arashid: /* Mismatches */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:42:52Z

Arashid: /* Mismatches */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:41:30Z

Arashid: /* * Encapsulation */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:41:16Z

Arashid: /* Mismatches */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:41:01Z

Arashid: /* Mismatches */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:40:11Z

Arashid: /* Differences between Relational Vs Object-Oriented Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:39:01Z

Arashid: /* Differences between Relational Vs Object-Oriented Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:38:17Z

Arashid: /* Differences between Relational Vs Object-Oriented Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:37:40Z

Arashid: /* Differences between Relational Vs Object-Oriented Models */

File:Oomodel.gif

2008-07-25T16:36:14Z

Arashid: OO Models

OO Models

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:34:16Z

Arashid: /* Object-Oriented Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:33:00Z

Arashid: /* Relational Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:32:31Z

Arashid: /* Relational Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:31:58Z

Arashid: /* Relational Models */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:30:36Z

Arashid: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:29:32Z

Arashid: /* Links */

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T16:04:45Z

Arashid:

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-25T15:56:23Z

Arashid:

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-24T19:33:50Z

Arashid: /* Introduction */

File:Relational.gif

2008-07-24T19:32:54Z

Arashid: Relational model example

Relational model example

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-24T16:30:39Z

Arashid:

CSC/ECE 517 Summer 2008/wiki3 1 ar

2008-07-24T03:20:33Z

Arashid:

WIKI entry

CSC/ECE 517 Summer 2008/wiki2 2 ar

2008-06-25T18:38:07Z

Arashid: /* Links */

=Introduction=
This wiki entry will discusses about the importance of naming conventions and how they effect the readability of source code? It also shows examples of Java and Ruby langauge naming conventions.

==Background==
===Source code===
The source code is a set of computer instructions written mostly in ASCII text following some specific high level computer language syntaxes. They are human readable and need some special programs (Compilers and Interpreters) to convert it into machine languages. They actually represent the logic of the program.

===Problems face by source code===
# '''Organization of code''' - Organization of code is a difficult job. As amount and complexity increases it become harder to do that.
# '''Source code comprehension''' - Source code readability is actually associated with source [http://en.wikipedia.org/wiki/Program_comprehension code comprehension]. It is foundation through which a developer make sense of source code. There are some other [http://grok2.tripod.com/code_comprehension.html techniques/tools] available that support program comprehension but nothing could match with batter readable source code.
# '''Complex computer language syntaxes''' - Some time computer languages design with complex notations, that make those languages very powerful but it also forces programmer to stop first to understand the language constructs then follow the actual program logic.

=Naming conventions=
[http://en.wikipedia.org/wiki/Naming_convention Naming conventions] is standard way of making names of things to embed additional information. This technique is very effectively used in normal life to remove irregularities. Numbering houses even and odd numbers across street to represent there direction on the road is an example of simple naming conventions.

In computer languages naming convention mostly represent rules for defining different identifiers in the program. Class names, variable names, and source file names are good examples of such rules. Good naming rules increase the source code comprehension. In some modern languages (Ruby and Ruby-on-Rails) these convention even also used as configuration information.

==Benefits of standardize naming conventions==
* Improve source code comprehension.
* Reduces the maintenance cost.
* Could be used as configuration information.
* Improves code readability.
* Could allow to embed metadata information with identifier names.
* Avoids the "naming collisions".
* Reduces the requirement of program documentation

==Factors effecting naming conventions==
===Language specific===
Readability of source code is very specific to target language. When developers move from one language to other, they start complaining about existing coding standards but later they would figure out the reason for those standards. Joel Spolky has a nice article ([http://www.joelonsoftware.com/articles/Wrong.html Making Wrong Code Look Wrong]) addressing this issue.
===Nature of work/domain===
Nature of software is also very important factor effecting naming conventions. A developer who never worked on web application development might complain about lack of comments explaining session and cookies variables but for web application developer it is common thing.
===Developers preferences===
Developers are people and as every person has different taste for clothing and food, similarly developers have opinion about different style of naming. Some developers who are coming from embedded or real-time software development might like smaller names then developers of business applications.

==Elements of naming conventions==
There are number of elements that define the basics of naming conventions. They actually differentiate one naming standard from another one. These elements are influence by the factors we discussed in last section.
===Length of identifiers===
This element is part of big debate both in professional and academic circles, what is good, brevity or expressiveness? Some standards recommend fixed size names, some don’t allow abbreviations, some ask to add specific characters to define the type of identifier (like use of I to represent interface classes etc.).
===Letter case and numerals===
Some conventions have rules about case of letters according to there types (Like first Uppercase letter for class names and first lowercase letter for method names) and some use no restriction on letters case but add numbers or special characters to identifies the type of identifiers (Like in ruby @ use for public variables etc.)
===Word boundaries===
For multiple words most of languages do not allow whitespaces in identifier names. Some recommend using underscore (“_”) character as separator or use of [http://en.wikipedia.org/wiki/CamelCase CamelCase]. CamelCase technique uses uppercase letter to define the word boundaries. For example,
EmployeeType

addOrder
CamelCase works most of time but with acronym it procedures bad names like DaoEmploye.

=General naming conventions=
There are few naming conventions that are not specific to any language but include the basic principles of program languages. In these conventions naming of identifies not only reflects the domain but also platform specific types too.
==Hungarian notations==
This is a well-known naming convention that incorporates purpose or type of identity with its name. Examples,

IEmployeeType // Interface name

btnSubmit // Submit Button

arrEmployees // employees array

strUsername // user name in string

==Positional notations==
This convention mostly used in mainframe and COBOL environment where system usually has limitation on numbers of character use for identifier names. A typical scheme is something like, two characters for application name, three characters for module or process name in that application and rest is numbers to make them unique.

OPCAT001 // OP - Order processing, CAT - Catalog, 001 - first variable

=Language specific naming conventions=
==Java==
Sun has a very comprehensive guideline for [http://java.sun.com/docs/codeconv/ Java source coding]. It includes everything from source code organization to naming classes. It is difficult to include everything here. I am going to just specify the naming convention for basic things,

===Packages===
Prefix of package names is always in all lowercase. It is also recommended to start the package names from top-level domain names i.e., com, edu, org, mil, net. Examples,

com.sun.lang, edu.ncsu.csc517.pg

===Classes===
Class names should be nouns and starting character should be capital. If name requires any division, then use mixed case where every starting character is capital. Examples,

class Employee

class GraduateStudent.

===Interfaces===

Names for interfaces should also follow the class name conventions. Examples,

interface DataAccessObject

interface StudyType.

===Method Names===
Method names should start with some verb and first letter is in lowercase. Examples,

runApp()

addCustomerOrderInformation

===Variables===
Variable names also follow method naming rules. Examples,

studentId

employeeName

===Constants===
Class constants and ANSI standard constant should be all upper case separated by underscores (“_”). Examples,

EMPLOYEE_MAX_AGE

WINDOW_WIDTH

==Ruby==
Most of the time, Ruby and Ruby-on-Rails follow the same naming convention like Java. But there are a few differences. One more thing we should be careful about Ruby and Ruby-on-Rails is, since they follow convention over configuration schema, some naming rules are more important for successful execution of application.

=== Local variables===
All lowercase letters are separated by underscores. Examples:

employee_age

If it is starts with a capital letter then it is a constant. Example

Constant=10

===Instance variables===
Starts with single “at” sign (@) follow by name. It is suggested to have all lowercase for variable name after @ sign. Examples,

@name

@address

===Instance Method===
Starts with lowercase letter follow by digits, underscores and letters. Examples,

paint_door

manager?.

===Class variables===
Starts with double “at” signs (@@) and followed by letters, digits, and underscores. Examples,

@@employee

===Constants===
Starts with an upper case letter followed by other characters. Sometimes, developers use all upper case names for constant. Examples,

PI

MAX_AGE.

===Class and Modules===
Class and module names start with uppercase. Examples,

Class Employee

module DatabaseFunctions.

===Global variables===
Starts with dollar ($) sign and followed by characters. Examples,

$company

=Tools=

Developing naming conventions is a smaller job then actually making sure those rules are being followed by the team. Luckily there are few tools available that make this task easier. I have used [http://checkstyle.sourceforge.net CheckStyle] on my job and it worked beautifully. Checkstyle is a fully configurable development tool that makes sure that code is following proper naming conventions. It has integration available with all well known development environments. I have included few links to tutorials using checkstyle in Eclipse and Netbeans in links section.

=Conclusion=
Cost of software development keeps increasing and especially maintenance cost is hurting lot of in-production applications. Major contributor to high cost is associated with difficulty to understand the existing code. A lot of time documentation is not synchronized with code updates. In those cases the importance of code readability increases even more. Having proper naming conventions not only improves the development time but it also reduces the cost of maintenance.

Establishing naming convention is very tricky area. It should not be develop in isolation. Team’s developers’ suggestion should also consider besides looking at industry standards. All successful open source projects start with proper naming conventions. I have included few links, in case someone need some examples.

=Links=
* [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation]
* [http://en.wikipedia.org/wiki/CamelCase CamelCase]
* [http://www.wikihow.com/Improve-the-Readability-of-Your-Software-Code How to Improve the Readability of your software code]
* [http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/1995/08/r8toc.xml&DOI=10.1109/2.402076 Program Comprehension During Software Maintenance and Evolution]
* [http://www.perlmonks.org/?node_id=592616 What is code readability?]
* [http://en.wikipedia.org/wiki/Source_code Source Code]
* [http://www.javalobby.org/java/forums/t96280.html Does "code readability" mean different things to different people?]
* [http://en.wikipedia.org/wiki/Naming_convention Naming convention]
* [http://msdn.microsoft.com/en-us/library/ms229045.aspx .NET General Naming Conventions]
==Coding conventions for languages==
*ActionScript(Flex): [http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions Flex SDK coding conventions and best practices]
*C++: [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Code_Style C++ Programming/Code Style]
*C++: [http://geosoft.no/development/cppstyle.html GeoSoft's C++ Programming Style Guidelines]
*C#: [http://www.tiobe.com/standards/gemrcsharpcs.pdf Coding Standard: C# (Philips Medical Systems)]
*D: [http://www.digitalmars.com/d/1.0/dstyle.html The D Style]
*Erlang: [http://www.erlang.se/doc/programming_rules.shtml Erlang Programming Rules and Conventions]
*Java: [http://java.sun.com/docs/codeconv/ Sun official Java coding style]
*Lisp: [http://mumble.net/~campbell/scheme/style.txt Riastradh's Lisp Style Rules]
*Mono: [http://www.mono-project.com/Coding_Guidelines Programming style for Mono]
*Perl: [http://perldoc.perl.org/perlstyle.html Perl Style Guide]
*PHP::PEAR: [http://pear.php.net/manual/en/standards.php PHP::PEAR Coding Standards]
*Python: [http://www.python.org/peps/pep-0008.html Style Guide for Python Code]
*Ruby: [http://itsignals.cascadia.com.au/?p=7 Ruby and Rails Naming Conventions]
==Coding conventions for projects==
*[http://httpd.apache.org/dev/styleguide.html Apache Developers' C Language Style Guide]
*[http://lxr.linux.no/source/Documentation/CodingStyle Linux Kernel Coding Style]
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]
*[ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/style The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)]
==CheckStyle==
*[http://checkstyle.sourceforge.net/ CheckStyle project website]
*[http://blogs.sun.com/geertjan/entry/checkstyle CheckStyle with Netbeans]
*[http://www.testearly.com/2007/06/06/agile-developers-toolbox-checkstyle-for-eclipse/ CheckStyle with Eclipse]
*[http://eclipse-cs.sourceforge.net/ Checkstyle plugin for Eclipse]
*[http://javaboutique.internet.com/reviews/checkstyle/ Good tutorial with some background]

CSC/ECE 517 Summer 2008/wiki2 2 ar

2008-06-25T18:34:21Z

Arashid: /* Links */

=Introduction=
This wiki entry will discusses about the importance of naming conventions and how they effect the readability of source code? It also shows examples of Java and Ruby langauge naming conventions.

==Background==
===Source code===
The source code is a set of computer instructions written mostly in ASCII text following some specific high level computer language syntaxes. They are human readable and need some special programs (Compilers and Interpreters) to convert it into machine languages. They actually represent the logic of the program.

===Problems face by source code===
# '''Organization of code''' - Organization of code is a difficult job. As amount and complexity increases it become harder to do that.
# '''Source code comprehension''' - Source code readability is actually associated with source [http://en.wikipedia.org/wiki/Program_comprehension code comprehension]. It is foundation through which a developer make sense of source code. There are some other [http://grok2.tripod.com/code_comprehension.html techniques/tools] available that support program comprehension but nothing could match with batter readable source code.
# '''Complex computer language syntaxes''' - Some time computer languages design with complex notations, that make those languages very powerful but it also forces programmer to stop first to understand the language constructs then follow the actual program logic.

=Naming conventions=
[http://en.wikipedia.org/wiki/Naming_convention Naming conventions] is standard way of making names of things to embed additional information. This technique is very effectively used in normal life to remove irregularities. Numbering houses even and odd numbers across street to represent there direction on the road is an example of simple naming conventions.

In computer languages naming convention mostly represent rules for defining different identifiers in the program. Class names, variable names, and source file names are good examples of such rules. Good naming rules increase the source code comprehension. In some modern languages (Ruby and Ruby-on-Rails) these convention even also used as configuration information.

==Benefits of standardize naming conventions==
* Improve source code comprehension.
* Reduces the maintenance cost.
* Could be used as configuration information.
* Improves code readability.
* Could allow to embed metadata information with identifier names.
* Avoids the "naming collisions".
* Reduces the requirement of program documentation

==Factors effecting naming conventions==
===Language specific===
Readability of source code is very specific to target language. When developers move from one language to other, they start complaining about existing coding standards but later they would figure out the reason for those standards. Joel Spolky has a nice article ([http://www.joelonsoftware.com/articles/Wrong.html Making Wrong Code Look Wrong]) addressing this issue.
===Nature of work/domain===
Nature of software is also very important factor effecting naming conventions. A developer who never worked on web application development might complain about lack of comments explaining session and cookies variables but for web application developer it is common thing.
===Developers preferences===
Developers are people and as every person has different taste for clothing and food, similarly developers have opinion about different style of naming. Some developers who are coming from embedded or real-time software development might like smaller names then developers of business applications.

==Elements of naming conventions==
There are number of elements that define the basics of naming conventions. They actually differentiate one naming standard from another one. These elements are influence by the factors we discussed in last section.
===Length of identifiers===
This element is part of big debate both in professional and academic circles, what is good, brevity or expressiveness? Some standards recommend fixed size names, some don’t allow abbreviations, some ask to add specific characters to define the type of identifier (like use of I to represent interface classes etc.).
===Letter case and numerals===
Some conventions have rules about case of letters according to there types (Like first Uppercase letter for class names and first lowercase letter for method names) and some use no restriction on letters case but add numbers or special characters to identifies the type of identifiers (Like in ruby @ use for public variables etc.)
===Word boundaries===
For multiple words most of languages do not allow whitespaces in identifier names. Some recommend using underscore (“_”) character as separator or use of [http://en.wikipedia.org/wiki/CamelCase CamelCase]. CamelCase technique uses uppercase letter to define the word boundaries. For example,
EmployeeType

addOrder
CamelCase works most of time but with acronym it procedures bad names like DaoEmploye.

=General naming conventions=
There are few naming conventions that are not specific to any language but include the basic principles of program languages. In these conventions naming of identifies not only reflects the domain but also platform specific types too.
==Hungarian notations==
This is a well-known naming convention that incorporates purpose or type of identity with its name. Examples,

IEmployeeType // Interface name

btnSubmit // Submit Button

arrEmployees // employees array

strUsername // user name in string

==Positional notations==
This convention mostly used in mainframe and COBOL environment where system usually has limitation on numbers of character use for identifier names. A typical scheme is something like, two characters for application name, three characters for module or process name in that application and rest is numbers to make them unique.

OPCAT001 // OP - Order processing, CAT - Catalog, 001 - first variable

=Language specific naming conventions=
==Java==
Sun has a very comprehensive guideline for [http://java.sun.com/docs/codeconv/ Java source coding]. It includes everything from source code organization to naming classes. It is difficult to include everything here. I am going to just specify the naming convention for basic things,

===Packages===
Prefix of package names is always in all lowercase. It is also recommended to start the package names from top-level domain names i.e., com, edu, org, mil, net. Examples,

com.sun.lang, edu.ncsu.csc517.pg

===Classes===
Class names should be nouns and starting character should be capital. If name requires any division, then use mixed case where every starting character is capital. Examples,

class Employee

class GraduateStudent.

===Interfaces===

Names for interfaces should also follow the class name conventions. Examples,

interface DataAccessObject

interface StudyType.

===Method Names===
Method names should start with some verb and first letter is in lowercase. Examples,

runApp()

addCustomerOrderInformation

===Variables===
Variable names also follow method naming rules. Examples,

studentId

employeeName

===Constants===
Class constants and ANSI standard constant should be all upper case separated by underscores (“_”). Examples,

EMPLOYEE_MAX_AGE

WINDOW_WIDTH

==Ruby==
Most of the time, Ruby and Ruby-on-Rails follow the same naming convention like Java. But there are a few differences. One more thing we should be careful about Ruby and Ruby-on-Rails is, since they follow convention over configuration schema, some naming rules are more important for successful execution of application.

=== Local variables===
All lowercase letters are separated by underscores. Examples:

employee_age

If it is starts with a capital letter then it is a constant. Example

Constant=10

===Instance variables===
Starts with single “at” sign (@) follow by name. It is suggested to have all lowercase for variable name after @ sign. Examples,

@name

@address

===Instance Method===
Starts with lowercase letter follow by digits, underscores and letters. Examples,

paint_door

manager?.

===Class variables===
Starts with double “at” signs (@@) and followed by letters, digits, and underscores. Examples,

@@employee

===Constants===
Starts with an upper case letter followed by other characters. Sometimes, developers use all upper case names for constant. Examples,

PI

MAX_AGE.

===Class and Modules===
Class and module names start with uppercase. Examples,

Class Employee

module DatabaseFunctions.

===Global variables===
Starts with dollar ($) sign and followed by characters. Examples,

$company

=Tools=

Developing naming conventions is a smaller job then actually making sure those rules are being followed by the team. Luckily there are few tools available that make this task easier. I have used [http://checkstyle.sourceforge.net CheckStyle] on my job and it worked beautifully. Checkstyle is a fully configurable development tool that makes sure that code is following proper naming conventions. It has integration available with all well known development environments. I have included few links to tutorials using checkstyle in Eclipse and Netbeans in links section.

=Conclusion=
Cost of software development keeps increasing and especially maintenance cost is hurting lot of in-production applications. Major contributor to high cost is associated with difficulty to understand the existing code. A lot of time documentation is not synchronized with code updates. In those cases the importance of code readability increases even more. Having proper naming conventions not only improves the development time but it also reduces the cost of maintenance.

Establishing naming convention is very tricky area. It should not be develop in isolation. Team’s developers’ suggestion should also consider besides looking at industry standards. All successful open source projects start with proper naming conventions. I have included few links, in case someone need some examples.

=Links=
* [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation]
* [http://en.wikipedia.org/wiki/CamelCase CamelCase]
* [http://www.wikihow.com/Improve-the-Readability-of-Your-Software-Code How to Improve the Readability of your software code]
* [http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/1995/08/r8toc.xml&DOI=10.1109/2.402076 Program Comprehension During Software Maintenance and Evolution]
==Coding conventions for languages==
*ActionScript(Flex): [http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions Flex SDK coding conventions and best practices]
*C++: [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Code_Style C++ Programming/Code Style]
*C++: [http://geosoft.no/development/cppstyle.html GeoSoft's C++ Programming Style Guidelines]
*C#: [http://www.tiobe.com/standards/gemrcsharpcs.pdf Coding Standard: C# (Philips Medical Systems)]
*D: [http://www.digitalmars.com/d/1.0/dstyle.html The D Style]
*Erlang: [http://www.erlang.se/doc/programming_rules.shtml Erlang Programming Rules and Conventions]
*Java: [http://java.sun.com/docs/codeconv/ Sun official Java coding style]
*Lisp: [http://mumble.net/~campbell/scheme/style.txt Riastradh's Lisp Style Rules]
*Mono: [http://www.mono-project.com/Coding_Guidelines Programming style for Mono]
*Perl: [http://perldoc.perl.org/perlstyle.html Perl Style Guide]
*PHP::PEAR: [http://pear.php.net/manual/en/standards.php PHP::PEAR Coding Standards]
*Python: [http://www.python.org/peps/pep-0008.html Style Guide for Python Code]
*Ruby: [http://itsignals.cascadia.com.au/?p=7 Ruby and Rails Naming Conventions]
==Coding conventions for projects==
*[http://httpd.apache.org/dev/styleguide.html Apache Developers' C Language Style Guide]
*[http://lxr.linux.no/source/Documentation/CodingStyle Linux Kernel Coding Style]
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]
*[ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/style The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)]
==CheckStyle==
*[http://checkstyle.sourceforge.net/ CheckStyle project website]
*[http://blogs.sun.com/geertjan/entry/checkstyle CheckStyle with Netbeans]
*[http://www.testearly.com/2007/06/06/agile-developers-toolbox-checkstyle-for-eclipse/ CheckStyle with Eclipse]
*[http://eclipse-cs.sourceforge.net/ Checkstyle plugin for Eclipse]
*[http://javaboutique.internet.com/reviews/checkstyle/ Good tutorial with some background]

CSC/ECE 517 Summer 2008/wiki2 2 ar

2008-06-25T18:32:14Z

Arashid: /* Links */

=Introduction=
This wiki entry will discusses about the importance of naming conventions and how they effect the readability of source code? It also shows examples of Java and Ruby langauge naming conventions.

==Background==
===Source code===
The source code is a set of computer instructions written mostly in ASCII text following some specific high level computer language syntaxes. They are human readable and need some special programs (Compilers and Interpreters) to convert it into machine languages. They actually represent the logic of the program.

===Problems face by source code===
# '''Organization of code''' - Organization of code is a difficult job. As amount and complexity increases it become harder to do that.
# '''Source code comprehension''' - Source code readability is actually associated with source [http://en.wikipedia.org/wiki/Program_comprehension code comprehension]. It is foundation through which a developer make sense of source code. There are some other [http://grok2.tripod.com/code_comprehension.html techniques/tools] available that support program comprehension but nothing could match with batter readable source code.
# '''Complex computer language syntaxes''' - Some time computer languages design with complex notations, that make those languages very powerful but it also forces programmer to stop first to understand the language constructs then follow the actual program logic.

=Naming conventions=
[http://en.wikipedia.org/wiki/Naming_convention Naming conventions] is standard way of making names of things to embed additional information. This technique is very effectively used in normal life to remove irregularities. Numbering houses even and odd numbers across street to represent there direction on the road is an example of simple naming conventions.

In computer languages naming convention mostly represent rules for defining different identifiers in the program. Class names, variable names, and source file names are good examples of such rules. Good naming rules increase the source code comprehension. In some modern languages (Ruby and Ruby-on-Rails) these convention even also used as configuration information.

==Benefits of standardize naming conventions==
* Improve source code comprehension.
* Reduces the maintenance cost.
* Could be used as configuration information.
* Improves code readability.
* Could allow to embed metadata information with identifier names.
* Avoids the "naming collisions".
* Reduces the requirement of program documentation

==Factors effecting naming conventions==
===Language specific===
Readability of source code is very specific to target language. When developers move from one language to other, they start complaining about existing coding standards but later they would figure out the reason for those standards. Joel Spolky has a nice article ([http://www.joelonsoftware.com/articles/Wrong.html Making Wrong Code Look Wrong]) addressing this issue.
===Nature of work/domain===
Nature of software is also very important factor effecting naming conventions. A developer who never worked on web application development might complain about lack of comments explaining session and cookies variables but for web application developer it is common thing.
===Developers preferences===
Developers are people and as every person has different taste for clothing and food, similarly developers have opinion about different style of naming. Some developers who are coming from embedded or real-time software development might like smaller names then developers of business applications.

==Elements of naming conventions==
There are number of elements that define the basics of naming conventions. They actually differentiate one naming standard from another one. These elements are influence by the factors we discussed in last section.
===Length of identifiers===
This element is part of big debate both in professional and academic circles, what is good, brevity or expressiveness? Some standards recommend fixed size names, some don’t allow abbreviations, some ask to add specific characters to define the type of identifier (like use of I to represent interface classes etc.).
===Letter case and numerals===
Some conventions have rules about case of letters according to there types (Like first Uppercase letter for class names and first lowercase letter for method names) and some use no restriction on letters case but add numbers or special characters to identifies the type of identifiers (Like in ruby @ use for public variables etc.)
===Word boundaries===
For multiple words most of languages do not allow whitespaces in identifier names. Some recommend using underscore (“_”) character as separator or use of [http://en.wikipedia.org/wiki/CamelCase CamelCase]. CamelCase technique uses uppercase letter to define the word boundaries. For example,
EmployeeType

addOrder
CamelCase works most of time but with acronym it procedures bad names like DaoEmploye.

=General naming conventions=
There are few naming conventions that are not specific to any language but include the basic principles of program languages. In these conventions naming of identifies not only reflects the domain but also platform specific types too.
==Hungarian notations==
This is a well-known naming convention that incorporates purpose or type of identity with its name. Examples,

IEmployeeType // Interface name

btnSubmit // Submit Button

arrEmployees // employees array

strUsername // user name in string

==Positional notations==
This convention mostly used in mainframe and COBOL environment where system usually has limitation on numbers of character use for identifier names. A typical scheme is something like, two characters for application name, three characters for module or process name in that application and rest is numbers to make them unique.

OPCAT001 // OP - Order processing, CAT - Catalog, 001 - first variable

=Language specific naming conventions=
==Java==
Sun has a very comprehensive guideline for [http://java.sun.com/docs/codeconv/ Java source coding]. It includes everything from source code organization to naming classes. It is difficult to include everything here. I am going to just specify the naming convention for basic things,

===Packages===
Prefix of package names is always in all lowercase. It is also recommended to start the package names from top-level domain names i.e., com, edu, org, mil, net. Examples,

com.sun.lang, edu.ncsu.csc517.pg

===Classes===
Class names should be nouns and starting character should be capital. If name requires any division, then use mixed case where every starting character is capital. Examples,

class Employee

class GraduateStudent.

===Interfaces===

Names for interfaces should also follow the class name conventions. Examples,

interface DataAccessObject

interface StudyType.

===Method Names===
Method names should start with some verb and first letter is in lowercase. Examples,

runApp()

addCustomerOrderInformation

===Variables===
Variable names also follow method naming rules. Examples,

studentId

employeeName

===Constants===
Class constants and ANSI standard constant should be all upper case separated by underscores (“_”). Examples,

EMPLOYEE_MAX_AGE

WINDOW_WIDTH

==Ruby==
Most of the time, Ruby and Ruby-on-Rails follow the same naming convention like Java. But there are a few differences. One more thing we should be careful about Ruby and Ruby-on-Rails is, since they follow convention over configuration schema, some naming rules are more important for successful execution of application.

=== Local variables===
All lowercase letters are separated by underscores. Examples:

employee_age

If it is starts with a capital letter then it is a constant. Example

Constant=10

===Instance variables===
Starts with single “at” sign (@) follow by name. It is suggested to have all lowercase for variable name after @ sign. Examples,

@name

@address

===Instance Method===
Starts with lowercase letter follow by digits, underscores and letters. Examples,

paint_door

manager?.

===Class variables===
Starts with double “at” signs (@@) and followed by letters, digits, and underscores. Examples,

@@employee

===Constants===
Starts with an upper case letter followed by other characters. Sometimes, developers use all upper case names for constant. Examples,

PI

MAX_AGE.

===Class and Modules===
Class and module names start with uppercase. Examples,

Class Employee

module DatabaseFunctions.

===Global variables===
Starts with dollar ($) sign and followed by characters. Examples,

$company

=Tools=

Developing naming conventions is a smaller job then actually making sure those rules are being followed by the team. Luckily there are few tools available that make this task easier. I have used [http://checkstyle.sourceforge.net CheckStyle] on my job and it worked beautifully. Checkstyle is a fully configurable development tool that makes sure that code is following proper naming conventions. It has integration available with all well known development environments. I have included few links to tutorials using checkstyle in Eclipse and Netbeans in links section.

=Conclusion=
Cost of software development keeps increasing and especially maintenance cost is hurting lot of in-production applications. Major contributor to high cost is associated with difficulty to understand the existing code. A lot of time documentation is not synchronized with code updates. In those cases the importance of code readability increases even more. Having proper naming conventions not only improves the development time but it also reduces the cost of maintenance.

Establishing naming convention is very tricky area. It should not be develop in isolation. Team’s developers’ suggestion should also consider besides looking at industry standards. All successful open source projects start with proper naming conventions. I have included few links, in case someone need some examples.

=Links=
* [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation]
* [http://en.wikipedia.org/wiki/CamelCase CamelCase]
* [http://www.wikihow.com/Improve-the-Readability-of-Your-Software-Code How to Improve the Readability of your software code]
==Coding conventions for languages==
*ActionScript(Flex): [http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions Flex SDK coding conventions and best practices]
*C++: [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Code_Style C++ Programming/Code Style]
*C++: [http://geosoft.no/development/cppstyle.html GeoSoft's C++ Programming Style Guidelines]
*C#: [http://www.tiobe.com/standards/gemrcsharpcs.pdf Coding Standard: C# (Philips Medical Systems)]
*D: [http://www.digitalmars.com/d/1.0/dstyle.html The D Style]
*Erlang: [http://www.erlang.se/doc/programming_rules.shtml Erlang Programming Rules and Conventions]
*Java: [http://java.sun.com/docs/codeconv/ Sun official Java coding style]
*Lisp: [http://mumble.net/~campbell/scheme/style.txt Riastradh's Lisp Style Rules]
*Mono: [http://www.mono-project.com/Coding_Guidelines Programming style for Mono]
*Perl: [http://perldoc.perl.org/perlstyle.html Perl Style Guide]
*PHP::PEAR: [http://pear.php.net/manual/en/standards.php PHP::PEAR Coding Standards]
*Python: [http://www.python.org/peps/pep-0008.html Style Guide for Python Code]
*Ruby: [http://itsignals.cascadia.com.au/?p=7 Ruby and Rails Naming Conventions]
==Coding conventions for projects==
*[http://httpd.apache.org/dev/styleguide.html Apache Developers' C Language Style Guide]
*[http://lxr.linux.no/source/Documentation/CodingStyle Linux Kernel Coding Style]
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]
*[ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/style The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)]
==CheckStyle==
*[http://checkstyle.sourceforge.net/ CheckStyle project website]
*[http://blogs.sun.com/geertjan/entry/checkstyle CheckStyle with Netbeans]
*[http://www.testearly.com/2007/06/06/agile-developers-toolbox-checkstyle-for-eclipse/ CheckStyle with Eclipse]
*[http://eclipse-cs.sourceforge.net/ Checkstyle plugin for Eclipse]
*[http://javaboutique.internet.com/reviews/checkstyle/ Good tutorial with some background]