Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:08:36Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design.

Responsibilities of an Object include two types : ''Knowing'' and ''Doing''

''Doing'' responsibilities of an object include:

*Doing something itself, such as creating an object or doing a calculation
*Initiating action in other objects
*Controlling and coordinating activities in other objects

''Knowing'' responsibilities of an object include:

*Knowing about private encapsulated data
*Knowing about related objects
*Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:08:15Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : ''Knowing'' and ''Doing''

''Doing'' responsibilities of an object include:

*Doing something itself, such as creating an object or doing a calculation
*Initiating action in other objects
*Controlling and coordinating activities in other objects

''Knowing'' responsibilities of an object include:

*Knowing about private encapsulated data
*Knowing about related objects
*Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:07:59Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : ''Knowing'' and ''Doing''

''Doing'' responsibilities of an object include:

*Doing something itself, such as creating an object or doing a calculation
*Initiating action in other objects
*Controlling and coordinating activities in other objects

''Knowing'' responsibilities of an object include:

*Knowing about private encapsulated data (know thyself, presume not God to scan)
*Knowing about related objects
*Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:07:24Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : ''Knowing'' and ''Doing''

''Doing'' responsibilities of an object include:
1.Doing something itself, such as creating an object or doing a calculation
2.Initiating action in other objects
3.Controlling and coordinating activities in other objects

''Knowing'' responsibilities of an object include:
1.Knowing about private encapsulated data (know thyself, presume not God to scan)
2.Knowing about related objects
3.Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:05:38Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : ''Knowing'' and ''Doing''

Doing responsibilities of an object include:
1.Doing something itself, such as creating an object or doing a calculation
2.Initiating action in other objects
3.Controlling and coordinating activities in other objects

Knowing responsibilities of an object include:
1.Knowing about private encapsulated data (know thyself, presume not God to scan)
2.Knowing about related objects
3.Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T01:05:18Z

Ppadman: /* GRASP Patterns */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : Knowing and Doing

Doing responsibilities of an object include:
1.Doing something itself, such as creating an object or doing a calculation
2.Initiating action in other objects
3.Controlling and coordinating activities in other objects

Knowing responsibilities of an object include:
1.Knowing about private encapsulated data (know thyself, presume not God to scan)
2.Knowing about related objects
3.Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

1. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691 Applying UML and Patterns: Craig Larman]

2. [http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf Grasp Design Patterns]

3. [http://www.galileo.cs.uwindsor.ca:8000/60-322/LectureSlides/GRASPPatterns.ppt GRASP Patterns]
=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T00:02:59Z

Ppadman: /* References */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : Knowing and Doing
Doing responsibilities of an object include:
1.Doing something itself, such as creating an object or doing a calculation
2.Initiating action in other objects
3.Controlling and coordinating activities in other objects

Knowing responsibilities of an object include:
1.Knowing about private encapsulated data (know thyself, presume not God to scan)
2.Knowing about related objects
3.Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

9. [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly Example]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-20T00:00:55Z

Ppadman: /* Example 2 */

''Take the Controller pattern (which we did not cover in class) 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.''

__TOC__

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design
Responsibilities of an Object include two types : Knowing and Doing
Doing responsibilities of an object include:
1.Doing something itself, such as creating an object or doing a calculation
2.Initiating action in other objects
3.Controlling and coordinating activities in other objects

Knowing responsibilities of an object include:
1.Knowing about private encapsulated data (know thyself, presume not God to scan)
2.Knowing about related objects
3.Knowing about things it can derive or calculate

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The ''Facade controller'' is suitable when there are few system events.

2. The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large
and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Example 1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

[[Image:controller6.jpg]]

The figure below shows allocation of different operations
[[Image:controller4.jpg]]

[[Image:controller5.jpg]]

== Example 2 ==
The game of [http://www.academic.marist.edu/~jzbv/SoftwareDevelopment/GRASP.ppt Monopoly] is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows:
What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows:
Assign the responsibility to an object representing either of following:
- Represents the overall “system” – a root object
- Represents a use case scenario within which the system operation occurs.

[[Image:monopoly.jpg]]

==Example 3==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

== Example 4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:controller2.jpg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:controller.jpg]]

==Example 5==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

File:Image-Controller example.jpeg

2007-11-17T14:08:11Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-15T17:10:49Z

Ppadman:

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=Issues that are important in learning about this topic=

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T19:17:11Z

Ppadman: /* Description */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Examples=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T19:16:06Z

Ppadman: /* Introduction */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The '''Controller pattern''' addresses the question: ''Who handles a system event?'' It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

==Benefits==

*''Reuse'' of domain layer software by plugging in various interfaces
*It is possible to ''control'' out-of-sequence system events

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T19:08:44Z

Ppadman: /* References */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

o Benefits:
+ ''Reuse'' of domain layer software by plugging in various interfaces
+ It is possible to ''control'' out-of-sequence system events

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8. [http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T19:08:32Z

Ppadman: /* References */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

o Benefits:
+ ''Reuse'' of domain layer software by plugging in various interfaces
+ It is possible to ''control'' out-of-sequence system events

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.[http://www.dcs.bbk.ac.uk/~niki/lecture5.ppt Presentation on Design Patterns]

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T19:07:38Z

Ppadman:

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

o To choose between facade and use-case controllers:
+ The ''Facade controller'' is suitable when there are few system events.
+ The ''Use-case controller'' is applicable when there are many system events and the facade controller would have become too large and incohesive.

o Benefits:
+ ''Reuse'' of domain layer software by plugging in various interfaces
+ It is possible to ''control'' out-of-sequence system events

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T18:22:46Z

Ppadman: /* Description4 */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_example.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

File:Controller example.jpeg

2007-11-14T18:22:17Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T18:19:22Z

Ppadman:

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:http://pg.ece.ncsu.edu/mediawiki/index.php/Image:Controller_Choice.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:2.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

File:Controller Choice.jpeg

2007-11-14T18:18:04Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T18:17:08Z

Ppadman:

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:1.jpeg]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:2.jpeg]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T18:16:06Z

Ppadman: /* Description4 */

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

[[Image:]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

File:Controller Example.jpg

2007-11-14T18:11:25Z

Ppadman:

File:New Bitmap Image.jpg

2007-11-14T18:08:05Z

Ppadman: Choice of Controller

Choice of Controller

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T18:05:52Z

Ppadman:

''Take the Controller pattern (which we did not cover in class) 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.''

=Design Patterns=
A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern] refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are ''proven solutions to common problems''.

==GRASP Patterns==
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] refers to '''G'''eneral '''R'''esponsibility '''A'''ssignment '''S'''oftware '''P'''atterns. It includes a systematic approach to [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design], while assigning responsibilities to classes.

The GRASP Patterns include:
* Information Expert
* Creator
* Controller
* Low Coupling
* High Cohesion
* Polymorphism
* Pure Fabrication
* Indirection
* Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

=The Controller Pattern=

==Introduction==
The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:
* A class that represents the ''overall system'', device, or subsystem (facade controller).
* A class that represents a ''use case scenario'' within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

Wikipedia succinctly states: ''"The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Controller] pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"''

=Description=

==Description1==

[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern.

The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method
for the system operation".

*A system event is said to be an event generated by an "external actor"

*A system operation refers to the response of the system to a system event.

The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

******Should we format it as Desc/Example or separate them ?

==Description2==
This article contains an [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example] of the Controller Pattern. The author classifies controllers as '''Use case Controllers''' and '''Facade Controllers'''.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

Get Categories
Get Product in Category X
Get Items in Shopping Cart
Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

ProductCatalogHandler
-Get Categories
-Get Product in Category X
ShoppingCartHandler
-Get Items in Shopping Cart
-Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

==Description3==

This [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog] mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related [http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx article] disambiguates between the Controller Pattern and the [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

==Description4==

[http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Reference 6] contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling
between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

''enterItem()''
''endSale()''
''makePayment()''

The problem can be phrased as: Who is responsible for ''enterItem()''?

Using the Controller Pattern to solve our problem, we can choose among the following:

*The overall system [POST]
*The overall business(sub-system) [STORE]
*Someone in the real world who is active in the task [CASHIER]
*The artificial handler of all system events in the use case [BuyItemsHandler]

[[Image:New Bitmap Image.bmp]]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decouple from the problem domain.

[[Image:Controller Example.wmf]]

=See Also=

Applying UML and Patterns: Craig Larman

=References=

1. [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns]

2. [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP]

3. [http://codebetter.com/blogs/david.hayden/archive/2005/04/08/61648.aspx Blog on GRASP Controller Pattern]

4. [http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx E-Commerce example]

5. [http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/GRASP.pdf Controller responsibility]

6. [http://209.85.165.104/search?q=cache:Mgu-Um9Lx1sJ:www.soc.napier.ac.uk/module.php3%3Fop%3Dgetresource%26cloaking%3Dno%26resourceid%3D5938601+controller+pattern+GRASP&hl=en&ct=clnk&cd=15&gl=us Presentation on GRASP]

7. [http://www.informit.com/content/images/0130925691/samplechapter/0130925691.pdf DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS]

8.

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T17:35:21Z

Ppadman: /* References */

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T17:12:42Z

Ppadman: /* Description4 */

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T05:26:47Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T05:07:55Z

Ppadman: /* Description2 */

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T05:06:41Z

Ppadman: /* Introduction */

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T05:05:24Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T04:42:19Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T04:03:49Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T03:52:18Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T03:46:40Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-14T03:30:42Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki3 6 pm

2007-11-13T21:07:30Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T21:07:10Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T16:25:13Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T16:24:20Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T16:23:46Z

Ppadman:

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T16:18:01Z

Ppadman:

=The Controller Pattern=

=Problem Description=

Take the Controller pattern (which we did not cover in class) 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.

==Introduction==

CSC/ECE 517 Fall 2007/wiki2 6 pm

2007-11-13T16:15:21Z

Ppadman:

=Problem Description=

Take the Controller pattern (which we did not cover in class) 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 1 p23

2007-10-30T03:30:17Z

Ppadman: /* Productivity */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

All actions in Struts must be mapped in an XML file. Return values use indirection (Success/Failure) that must be mapped in the XML
file. In Rails, this is handled by reflection (the framework figures out how the configuration should look).

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

Validation in Struts requires the use of "model mirrors" called ActionForms. These mirrors have a 1-1 mapping to your model files a lot of the time, but result in 'repeating yourself'. In Rails, validation occurs in the model. For example:

class MusicCd < ActiveRecord::Base
validates_presence_of :title, :artist, :genre, :quantity, :price
validates_numericality_of :price
validates_uniqueness_of :title
protected
def validate
errors.add(:price,"of the CD should be a positive value")unless price.nil? || price > 0.0
end
end

The presentation of validation errors are kept in the Action Controller.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for bridging components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-30T03:29:48Z

Ppadman: /* Productivity */

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-30T03:28:27Z

Ppadman: /* Architectural Differences */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

All actions in Struts must be mapped in an XML file. Return values use indirection (Success/Failure) that must be mapped in the XML
file. In Rails, this is handled by reflection (the framework figures out how the configuration should look).

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

Validation in Struts requires the use of "model mirrors" called ActionForms. These mirrors have a 1-1 mapping to your model files a lot of the time, but result in 'repeating yourself'. In Rails, validation occurs in the model. For example:

class MusicCd < ActiveRecord::Base
has_many :sold_music_cd
validates_presence_of :title, :artist, :genre, :quantity, :price
validates_numericality_of :price
validates_uniqueness_of :title
protected
def validate
errors.add(:price,"of the CD should be a positive value")unless price.nil? || price > 0.0
end
end

The presentation of validation errors are kept in the Action Controller.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for bridging components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-30T03:28:11Z

Ppadman: /* Comparison and Evaluation */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

All actions in Struts must be mapped in an XML file. Return values use indirection (SUCCESS/FAILURE) that must be mapped in the XML
file. In Rails, this is handled by reflection (the framework figures out how the configuration should look).

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

Validation in Struts requires the use of "model mirrors" called ActionForms. These mirrors have a 1-1 mapping to your model files a lot of the time, but result in 'repeating yourself'. In Rails, validation occurs in the model. For example:

class MusicCd < ActiveRecord::Base
has_many :sold_music_cd
validates_presence_of :title, :artist, :genre, :quantity, :price
validates_numericality_of :price
validates_uniqueness_of :title
protected
def validate
errors.add(:price,"of the CD should be a positive value")unless price.nil? || price > 0.0
end
end

The presentation of validation errors are kept in the Action Controller.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for bridging components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-30T02:27:53Z

Ppadman: /* Summary */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for bridging components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-25T03:30:42Z

Ppadman: /* References */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for configuration and gluing the components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-25T03:30:21Z

Ppadman:

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Architectural Differences ==

Both rely on the MVC Architecture. But they differ slightly in the implementation of the front controller.
With Struts, a developer needs to externalize mappings of requests to Action classes in an XML configuration file. Rails does not require this mapping, but discovers the mapping based on the URL specified. For example, http://localhost/product/delete/4 indicates that the fourth product must be deleted. Rails is smart enough to know that /product maps to a controller class defined in a file named product_controller.rb. If there is a find method defined in the controller, that method can be invoked by simply replacing delete with find in the URL.

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent. Apache Struts facilitates the creation of an extensible development environment for enterprise-grade applications, based on industry standards and established design patterns. A very simple application may be structured without the need for Struts, but for a complicated application that need to be maintained over time, Struts offers an ideal solution.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= Summary =

Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. The approach to development of Web applications sets the two frameworks apart.

Rails follows DRY and CoC instead of configuration files like Struts, and the dynamic nature of the Ruby language generates much of the code at runtime. The typical J2EE stack tends to be built from components that are usually developed independently of one another, and XML is often used for configuration and gluing the components together.

Rails is based upon industry accepted enterprise patterns, and Ruby language allows for fast development, due to its dynamic nature and is extremely popular.
At the same time, Struts, based on J2EE, is more established than the relatively-new Rails.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]'''

'''[http://www.roseindia.net/struts/ Struts Tutorial]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

CSC/ECE 517 Fall 2007/wiki2 1 p23

2007-10-25T03:14:17Z

Ppadman: /* Database Migration */

= Ruby on Rails and Apache Struts: A comparison based study =

There exist several [http://en.wikipedia.org/wiki/Web_Application_Framework web application development frameworks] in the market. A software developer faces a dilemma regarding which of these to employ to implement his application, based on criteria such as enhanced productivity, complexity, scalability, requirement satisfaction, maintenance, etc. This article aims to compare two such frameworks, '''[http://www.rubyonrails.org/ Ruby on Rails]''' and '''[http://struts.apache.org/ Apache Struts]''', from the perspective of the developer and that of the finished application.

= Introduction =

[http://en.wikipedia.org/wiki/Web_Application_Framework Web application frameworks] are employed to develop dynamic web pages as well as web applications and services. Generally, web application frameworks comprise libraries compiled into a cohesive software stack.
Web applications differ from static web pages in that they allow the generation of dynamic responses through database interaction.

Ruby on Rails as well as Apache Struts are based on what is known as the [http://en.wikipedia.org/wiki/Model_View_Controller Model-View-Controller (MVC)] architectural pattern. The concept underlying MVC is to separate the presentation layer (view) from the logic and the data model. This ensures that any changes to the user interface will not affect the business logic, and reorganization of the data model will not affect the user's view. [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] and the [http://en.wikipedia.org/wiki/Apache_Struts Apache Struts] framework are both based on the MVC Architecture.

== Problem Statement ==

"Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?"

= Ruby on Rails =

Ruby on Rails is a framework that facilitates the development, deployment and maintenance of web applications, written in the '''[http://www.ruby-lang.org/en/ Ruby]''' programming language.

== Design Paradigms ==

Rails was designed with the underlying concept of [http://en.wikipedia.org/wiki/DRY Don't Repeat Yourself (DRY)], which emphasizes that every piece of information in the system should be expressed only once. As a result, changes to applications designed with Rails will impact a lot less code than they would in other frameworks.

Another paradigm that Rails is based on is [http://en.wikipedia.org/wiki/Convention_over_Configuration Convention over Configuration (CoC)], which means that Rails has defaults for every aspect of the application being developed. Hence, following conventions can lead to application deployment with much less code than would have been written in another programming language. Rails is the first framework to have adopted this paradigm. Ruby also provides ''[http://en.wikipedia.org/wiki/Scaffold_%28programming%29 scaffolding]'', an "autogenerated framework for manipulating a model".

== Architecture ==

Rails is designed based on the MVC Architecture. It enforces a structure for the application where models, views and controllers are developed functionally separately, and then knit together during the execution of the application. Incoming requests are sent to a 'router', which computes where the request must be directed to, and how it must be interpreted. This directs the request to a method in the ''controller'' (an action), which performs some data manipulation or computation. The data is then rendered as a ''view'' to the user.

== Structure ==

Rails' framework consists of the following packages: Active Record, Action Pack, Active Support, Action Mailer and Action Web Service.

=== Active Record ===

Rails maps relational database tuples to objects using [http://en.wikipedia.org/wiki/Active_record Active Record]: tables map to classes, rows to objects, and columns to object attributes. Active Record facilitates the implementation of the primitive database operations: Create, Read, Update and Delete. It is also the model part that allows the user to define relationships such as ''belongs_to'' and ''has_many''.

= Apache Struts =

Apache Struts is a web application framework for developing web applications in [http://java.sun.com/javaee/ Java].

== Design Paradigms ==

The key technologies underlying the core control layer of the Struts framework are Java Servlets, JavaBeans and XML.

== Architecture ==

Struts achieves separation between data, views and the underlying logic, according to the MVC architecture. It provides the controller (ActionServlet) and the views, which can be generated for the user interface, usually with JSP. The developer must bridge the view and the controller together the model - with a configuration file struts-config.xml. Messaging between components is achieved through [http://en.wikipedia.org/wiki/JavaBeans JavaBeans].

Like Ruby on Rails, the 'router' receives requests and actions defined in the configuration file determine the processing of the request. The Action class corresponding to this action is called, and it interacts with the model to receive a string (ActionForward) indicating where the results must be directed.

=== ActionServlet ===

ActionServlet provides the controller for the framework and performs the following tasks:

* Identifies the action procedure to direct the incoming request to.

* Uses this to map to the corresponding Java action class name (an implementation of the Action or Command interface).

* Populate the field properties of the associated ActionForm bean.

* Call the execute method

== Other Features ==

Struts supports [http://en.wikipedia.org/wiki/Internationalization_and_localization internationalization], and also includes a template mechanism (Tiles). This is achieved by including a library of markup tags.

= Comparison and Evaluation =

These web application frameworks can be compared against each other based on several criteria, as given below.

== Comparison criteria ==

== Productivity ==

The Ruby developer is more productive by spending less time writing code. The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

With Rails, one line of code, namely, ''scaffold :table_name'' can generate all the CRUD methods required for the application. Achieving the same in the traditional J2EE environment translates roughly to a hundred lines of code.

On the other hand, Apache Struts contains a predefined tag library, to process the content of JavaBeans from the views without the need for any embedded Java code.

== Scalability ==

Ruby on Rails is often criticized for its poor scalability. Apache Struts is meant for applications that need to be scalable, to a large extent.

== Internationalization ==

Internationalization refers to the adaptation of computer software to different environments. Struts supports this, whereas Rails currently does not have any explicit support for internationalization, but offers Globalization plugins.

== Database Migration ==

Apache does not contain a DB migration framework like Rails does.
The database migrations enhance productivity by reducing effort spent in switching between schema versions. In the traditional J2EE environment, version control would be required for the developer to achieve the same.

== Platforms ==

Considering the platforms these two applications are built upon, a big difference is that Java on the server is targeted at the enterprise. Anyone who wants to run a Java EE application will most likely host their own servers.

Ruby on Rails is targeting a different population: the "Web sites in-between", that are not massively scalable but a fair amount of usage. PHP is not an option since it's installed virtually on 99% of Internet Providers. Hence, Rails being hosted natively is the perfect solution.

= See Also =

'''[http://pragprog.com/titles/rails2/index.html Agile Web Development with Rails]''' by Dave Thomas and David Heinemeier Hansson, with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

'''Model Driven Development with Rails''' by Antonios Protopsaltou

'''[http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-978-1-4303-2033-3 Starting with Struts2]''' by Ian Roughley

= References =

'''[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Ruby on Rails Tutorial]'''

'''[http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails]'''

'''[http://wiki.rubyonrails.org/rails Rails Wiki]'''

'''[http://cwiki.apache.org/WW/nutshell.html Struts MVC in a nutshell]'''

'''[http://wiki.apache.org/struts/StrutsCatalog An overview of the Struts framework and Design Patterns and Practices]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''

'''[ ]'''