Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T04:23:34Z

Xgao2: /* Some related concepts */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==

SoR is closely related with other OO design principles, and hence we explore some related concepts below.

;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling , more often than not, correlates with high cohesion, and tight coupling means low cohesion.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===Project/Architecture Level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:34:26Z

Xgao2: /* project/architecture level SoR */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==

SoR is closely related with other OO design principles, and hence we explore some related concepts below.

;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===Project/Architecture Level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:32:51Z

Xgao2: /* Some related concepts */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==

SoR is closely related with other OO design principles, and hence we explore some related concepts below.

;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:30:17Z

Xgao2: /* References */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:29:07Z

Xgao2: /* External Links */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:28:58Z

Xgao2: /* References */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

http://en.wikipedia.org/wiki/Information_hiding

http://en.wikipedia.org/wiki/Abstraction)

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:27:43Z

Xgao2: /* Class Level SoR */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:24:06Z

Xgao2: /* In Summary */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer" and "saveCustomer". And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC style.

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:16:52Z

Xgao2: /* SoR categories by scope */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer" and "saveCustomer". And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:16:15Z

Xgao2: /* SoR categories by scope */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class and method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");

//Check if a customer was already registered with that name
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
customer.setShoppingCart(new ShoppingCart());

customerService.save(customer);

}
</pre>

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer" and "saveCustomer". And thus separate different concerns to different methods.

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T02:01:48Z

Xgao2: /* References */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

http://designparadigm.wordpress.com/

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T01:16:57Z

Xgao2: /* SoR categories by scope */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

===Class Level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T01:16:10Z

Xgao2: /* class level SoR */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separate different system responsibility to different tiers.

===Class Level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T01:08:39Z

Xgao2: /* References */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

===class level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==In Summary==
==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T01:08:13Z

Xgao2: /* Aspect-oriented programming */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

===class level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-19T00:58:02Z

Xgao2: /* Some related concepts */

==Topic - Separation of Responsibility (SoR)==
Take the principle of Separation of Responsibility (abbreviated as SoR) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==What is SoR==
<b>Separation of responsibility</b> is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

==Some related concepts==
;Object Oriented Programming : OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

;Encapsulation : This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

;Information Hidding : "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

;Abstraction : "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

;Cohesion : "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

;Coupling : Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

==SoR categories by scope==

===class level SoR===

===project/architecture level SoR===
One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.
[[Image:MVC.gif|center]]
<font align='center' size='0.3' color='blue'><i>picture source: http://www.codeproject.com/useritems/PraticalMvc.asp</i></font>

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.
;Model : This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
;View : View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
;Controller : Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

<b>Ruby on Rails</b> (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our <i>Model</i> directory.

<pre>
class CreateProducts <ActiveRecord::Migration
def self.up
creat_table :products do |t|
t.column :title :string
t.column :descriprtion :text
end
end
# ...rest of the code #
end

class Product < ActiveRecord::Base
validates_presence_of :title, :description

def self.find_products_for_sale
find( :all, :order => "title" )
end
end
</pre>

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':
<pre>
<h1>Products Listing</h1>
<% for product in @products %>
<h3><%= h(product.title) %>
<%= product.description %>
<% end %>
</pre>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

<pre>
class StoreController < ApplicationController
@products = Product.find_products_for_sale
end
</pre>

==Aspect-oriented programming ==

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

http://www.rubyonrails.org/docs

==External Links==

To be finished

2007-11-19T00:51:01Z

Xgao2:

"The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T02:20:20Z

Xgao2:

==Problem Description==
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==Concept to explore==
Concept of Separation of responsibility
Separation of concern
Separation of responsibility

==Similar principles==

==class level separation of responsibility==

==project/architecture level separation of responsibility==
MVC

==Aspect-oriented programming ==

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T02:19:58Z

Xgao2: /* References */

==Problem Description==
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==Concept to explore==
Concept of Separation of responsibility
Separation of concern
Separation of responsibility

==Similar principles==

==class level separation of responsibility==

==project/architecture level separation of responsibility==
MVC

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

http://en.wikipedia.org/wiki/Separation_of_concerns

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T02:17:49Z

Xgao2: /* References */

==Problem Description==
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==Concept to explore==
Concept of Separation of responsibility
Separation of concern
Separation of responsibility

==Similar principles==

==class level separation of responsibility==

==project/architecture level separation of responsibility==
MVC

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm
http://en.wikipedia.org/wiki/Separation_of_concerns

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T02:14:24Z

Xgao2: /* Concept to explore */

==Problem Description==
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==Concept to explore==
Concept of Separation of responsibility
Separation of concern
Separation of responsibility

==Similar principles==

==class level separation of responsibility==

==project/architecture level separation of responsibility==
MVC

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T01:59:45Z

Xgao2:

==Problem Description==
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

==Concept to explore==

==Similar principles==

==class level separation of responsibility==

==project/architecture level separation of responsibility==
MVC

==References==
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm

==External Links==

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T01:11:49Z

Xgao2:

===Problem Description===
' Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'

CSC/ECE 517 Fall 2007/wiki3 3 33

2007-11-15T01:11:33Z

Xgao2:

===Problem Description===
" Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class."

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-30T01:25:04Z

Xgao2: /* Comparison */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC. Hibernate is originally developed for Java, but now it also support .NET from 2005.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to SDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia SDO]

==Java Data Objects==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or special wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of the Active Record universe. Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

'''Crossing Chasms''' is a pattern language for Object-RDBMS integration, which contains several patterns to transform object to relational database according to different situation and different object values. Like other ORM, Crossing Chasms pattern focuses on how to how to transform between data and objects, however, it also includes other issues related to the mapping procedure, such as ''Table Design Time Pattern'', which discuss when to design the database table schema.

'''Service Data Object''' aims to provide a uniform way to access heterogeneous data, unlike the method or patterns mentioned above, it can not only map to relational database data, but also other types of data.

Application programmers using '''Java Data Objects''' can focus on their domain object model and leave the details of persistence to JDO implementations, while '''Crossing Chasms''' specifies details how to mapping between database and objects.

In one word, different OR mappings has different advantages and limitations, developers will have to choose the appropriate OR mapping tools according to the project requirement and their skill set as well.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-30T01:24:29Z

Xgao2: /* Comparison */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC. Hibernate is originally developed for Java, but now it also support .NET from 2005.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to SDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia SDO]

==Java Data Objects==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or special wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of the Active Record universe. Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

'''Crossing Chasms''' is a pattern language for Object-RDBMS integration, which contains several patterns to transform object to relational database according to different situation and different object values. Like other ORM, Crossing Chasms pattern focuses on how to how to transform between data and objects, however, it also includes other issues related to the mapping procedure, such as ''Table Design Time Pattern'', which discuss when to design the database table schema.

'''Service Data Object''' aims to provide a uniform way to access heterogeneous data, unlike the method or patterns mentioned above, it can not only map to relational database data, but also other types of data.

Application programmers using '''Java Data Objects''' can focus on their domain object model and leave the details of persistence to JDO implementations, while '''Crossing Chasms''' specifies details how to mapping between database and objects.

In one word, different OR mapping has different advantages and limitations, developers will have to choose the appropriate OR mapping tools according to the project requirement and their skill set as well.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:57:47Z

Xgao2: /* Comparison */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to SDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia SDO]

==Java Data Objects==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of the Active Record universe. Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

'''Service Data Object''' aims to provide a uniform way to access heterogeneous data, so it can not only map to relational database data, but also other types of data.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:56:53Z

Xgao2: /* Comparison */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to SDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia SDO]

==Java Data Objects==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of your Active Record universe.
Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

'''Service Data Object''' aims to provide a uniform way to access heterogeneous data, so it can not only map to relational database data, but also other types of data.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:44:18Z

Xgao2: /* Java Data Object */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to JDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia JDO]

==Java Data Objects==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of your Active Record universe.
Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:44:12Z

Xgao2: /* JDO */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to JDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia JDO]

==Java Data Object==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Jeffrey M. Barnes in ''Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications'' indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of your Active Record universe.
Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:35:20Z

Xgao2: /* ActiveRecord in Ruby */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

=Introduction=

Object-oriented (o-o) programming uses '''Object''' to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However '''relational database''' is focus on information. It is a collection of relation variables between the ''attributes'' of ''tables'', it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "''ordering_books''", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

==Object-relational Mapping==

'''Object-relational mapping''' (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

[[image:figure-1.gif]]

=Implementations=
==ActiveRecord in Ruby==

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table
<pre>
create table customers{
customerNumber int
name varchar(20)
address varchar(50)
}
</pre>

and declaring a module
<pre>
class Customer < ActiveRecord::Base
end
</pre>

The table then can be manipulated directly through object.
<pre>
customer=Customer.new
customer.customerNumber=3
customer.name="John"
customer.address="#202 Heaven Rd, Raleigh, NC"
customer.save
</pre>
This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

*Automated mapping between classes and tables, attributes and columns.
*Associations between objects controlled by simple meta-programming macros.
*Aggregations of value objects controlled by simple meta-programming macros.
*Validation rules that can differ for new or existing objects.
*Acts that can make records work as lists or trees:
*Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
*Observers for the entire lifecycle
*Inheritance hierarchies
*Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
*Reflections on columns, associations, and aggregations
*Direct manipulation (instead of service invocation)
*Database abstraction through simple adapters (~100 lines) with a shared connector
*Logging support for Log4r and Logger

A detailed explanation including examples can be found [http://ar.rubyonrails.com/ here]

==Crossing Chasms Pattern==

'''Crossing Chasms Pattern''' is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in ''Crossing Chasms: A Pattern Language for Object-RDBMS Integration'' [7], such as:

*Pattern: Table Design Time
*Pattern: Representing Objects as Tables
*Pattern: Representing Object Relationships
*Pattern: Representing Inheritance in a Relational Database
*Pattern: Representing Collections in a Relational Database
*Pattern: Object Identifier
*Pattern: Foreign Key References
*Pattern: Foreign Key versus Direct Reference

More details can be found in [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]

There are other useful links:

*[http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
*[http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
*[http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

==Hibernate==

'''Hibernate''' is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class ''Customer''[http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ [3]] as follows:

<pre>
public class Customer {
private int customerNumber;
private String name;
private String Address;
private String telephoneNumber;

/* Accessors and other methods go here, such as "ordering_books". These are generally
not part of the class-to-table mapping process. Remember, the database is for storing the
data of the class, not its behavior. */
}
</pre>

Then, the mapping document in Hibernate is:

<pre>
<hibernate-mapping>
<class name="Customer" table="Customer" discriminator-value="P">
<id name="id" column="CustomerId" type="long">
<generator class="native"/>
</id>
<property name="name" column="Name" />
<property name="streetAddress" column="Address" />
<property name="telephoneNumber" column="TelephoneNumber" />
</class>
</hibernate-mapping>
</pre>

Every mapping document in Hibernate has a root ''bihernate-mapping'', classes are specified by element ''class'', in the ''class'' elements, children element ''property'' specifies persistent data of the class and the corresponding database columns.

An object '''c''' of class ''Customer'' can be saved to the database using code like the following [3]:

<pre>
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.save(c);
tx.commit();
session.close();
</pre>

More details can be found in [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]

Some other useful links:
*[http://www.laliluna.de/what-is-hibernate.html What Is Hibernate]
*[http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate (Java)]
*[http://www.hibernate.org/ Relational Persistence for Java and .NET]

==Service Data Object==

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

* Uniform access APIs to heterogeneous data sources
* Support Multi-language (Java, C++, etc)
* Maintains a disconnected data graph.
* A dynamic APIs
* Generate static APIs from the data source’s schema or UML.
* Xpath based navigation through data graph
* Change summary
* Validations and constraints
* Metadata access which is useful for tool builders.

Useful links includes

[http://www.ibm.com/developerworks/java/library/j-sdo/ introduction to JDO from IBM]

[http://en.wikipedia.org/wiki/Service_Data_Objects wikipedia JDO]

==JDO==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from [http://java.sun.com/jdo/ Sun website]

'''Ease of use''': Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

'''Portability''': Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

'''Database independence''': Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

'''High performance''': Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

'''Integration with EJB''': Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

=Comparison=
In '''Hibernate''', developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object.

'''Active Record''' is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of your Active Record universe.
Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

=Reference=
# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia Definition]
# [http://www.chimu.com/publications/objectRelational/ Foundations of Object-Relational Mapping]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ ORM Thesis]
# [http://www-128.ibm.com/developerworks/java/library/j-cb03076/index.html Crossing borders: Exploring Active Record ]
# [http://osoa.org/display/Main/Service+Data+Objects+Specifications SDO2.0 specifications ]
# [http://people.engr.ncsu.edu/efg/517/f02/common/syllabus/annotations/lec24/ppframe.htm Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations]
# [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
# [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
# [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]
# [http://java.sun.com/jdo/ Java Data Objects (JDO)]

=External Links=
'''
# [http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Appendices/products.htm O/R Mapping Products]

CSC/ECE 517 Fall 2007/wiki2 2 aa

2007-10-23T14:34:31Z