1. Patter orienteds/w architecture for web based
application
Pawan Kumar Tiwari
Roll No: 16
MCA 3sem

2. Why do we need these patterns
 If we can certainly build software applications without
using any of these patterns, but by using these
patterns we can achieve separation of concerns design
principle.
 These help in improving maintainability of the
application.
 Another important reason why these patterns became
popular is implementing these patterns improve the
testability of the application using automated unit
tests

3. Design Pattern Classification
• Creational Patterns
• Structural Patterns
• Behavioral Pattern
-MVC
-MVP
-MVVM
-MVC# and ASP .NET MVC

4. Model View Controller (MVC) architecture
Design patterns:
A design pattern describes a proven solution to a recurring design
problem, placing particular emphasis on the context and forces
surrounding the problem, and the consequences and impact of the
solution. There are many good reasons to use design patterns:
1. They are proven: You tap the experience, knowledge and
insights of developers who have used these patterns
successfully in their own work.
2. They are reusable: When a problem recurs, you don’t have to
invent a new solution; you
follow the pattern and adapt it as necessary.
3. They are expressive: Design patterns provide a common
vocabulary of solutions, which you can use to express
larger solutions succinctly.
It is important to remember, however, that design patterns do not
guarantee success

5. Cont..
• It is common to think of an application as having three
main layers: presentation (UI), application logic, and
resource management. In MVC, the presentation layer
is split into controller and view.
• MVC (Model, View, Controller) is a pattern for
organising code in an application to improve
maintainability.
Imagine a photographer with his camera in a
studio. A customer asks him to take a photo of a
box.
The box is the model, the photographer is
the controller and the camera is the view.

6. • Model View Controller or MVC as it is popularly called, is
a software design pattern for developing web
applications. A Model View Controller pattern is made up
of the following three parts.
 Model
 View
 Controller

7. Model - Model represents an object or JAVA POJO
carrying data. It can also have logic to update controller if
its data changes.
The model is responsible for managing the data of the
application. It responds to the request from the view and
it also responds to instructions from the controller to
update itself.
View - View represents the visualization of the data that
model contains.
MVC is often seen in web applications, where the view is
the HTML page and the
code which gathers dynamic data for the page
Controller - Controller acts on both model and view. It
controls the data flow into model object and updates the
view whenever data changes. It keeps view and model
separate.
The controller receives the input, it validates the input
and then performs the business operation that modifies
the state of the data model.

8. MVC Implementation
We are going to create a Student object acting as a
model.StudentView will be a view class which can
print student details on console and
StudentController is the controller class responsible
to store data in Student object and update view
StudentView accordingly.

9. MVCPatternDemo, our demo class, will use
StudentController to demonstrate use of MVC pattern

10. What is PAC?
• The Presentation-Abstraction-
Control pattern (PAC) defines a
structure for interactive software
systems in the form of a
hierarchy of cooperating agents.

11. Moreover…
• Every agent is responsible for a specific
aspect of the application's functionality and
consists of three components: presentation,
abstraction, and control. This subdivision
separates the human-computer interaction
aspects of the agent from its functional core
and its communication with other agents.
Class Diagram For PAC:

12. As the comparison
• The PAC abstraction component corresponds
roughly to the model component of MVC.
• The presentation component in PAC is a
combination of the view and control
components in MVC.
• The control component of PAC mediates
between agents and has no equivalent in
MVC.

13. Example

14. Context
• Interactive systems can often be viewed as a set of
cooperating agents.
– Agents specialized in human-computer interaction accept user
input and display data.
– Other agents maintain the data model of the system and offer
functionality that operates on this data.
– Additional agents are responsible for diverse tasks such as
error handling or communication with other software
systems.
• Besides this horizontal decomposition of system functionality,
we often encounter a vertical decomposition.
• In such an architecture of cooperating agents, each agent is
specialized for a specific task, and all agents together provide
the system functionality. This architecture captures both a
horizontal and vertical decomposition.

16. How it works?
• The agent's presentation component provides
the visible behavior of the PAC agent.
• Its abstraction component maintains the data
model that underlies the agent, and provides
functionality that operates on this data.
• Its control component connects the
presentation and abstraction components,
and provides functionality that allows the
agent to communicate with other PAC agents.

18. Top-Level
• The top-level PAC agent provides the
functional core of the system.
– The top-level PAC agent includes those parts of
the user interface that cannot be assigned to
particular subtasks, such as menu bars or a
dialog box displaying information about the
application.
– Most other PAC agents depend or operate on
this core.

19. Bottom-level
• Bottom-level PAC agents represent self-
contained concepts on which users of the
system can act, such as spreadsheets and
charts.
– The bottom-level agents present these
concepts to the user and support all
operations that users can perform on these
agents, such as zooming or moving a chart.

20. Intermediate-level
• Intermediate-level PAC agents represent
either combinations of, or relationships
between, lower-level agents, e.g. a floor plan
and an external view of a house in a CAD
system for architecture.

21. PAC Benefits
• Support for change and extension.
– Changes within the presentation or abstraction
components of a PAC agent do not affect other
agents in the system.
– New agents are easily integrated into an existing
PAC architecture without major changes to
existing PAC agents.
• Support for multitasking.
– PAC agents can be distributed easily to different
threads, processes, or machines. Extending a PAC
agent with appropriate inter-process
communication functionality only affects its
control component.

22. Liability of PAC
• Increased system complexity.
• Complex control component.
• Efficiency.
• Applicability.