1. MVC and other n-tier Architectures

2. Traditional Host Systems
A Central Processing System (Mainframe) provides all processing.
Local Terminals are responsible for display and keyboard for user input and viewing capabilities. Local Terminals do not contain any intelligent processing capabilities.

3. Traditional Host Systems

4. Distributed Systems Distributed System Replication
Both data and transaction processing are divided between one or more computers connected by a network, each computer playing a specific role in the system.
Replication
Ensures data at all sites in a distributed system reflects any changes made anywhere in the system.

5. Distributed Systems

6. Client/Server 2-Tier Architecture
Two-tier client/server architectures have 2 essential components
A Client PC and
A Database Server
2-Tier Considerations:
Client program accesses database directly
Requires a code change to port to a different database
Potential bottleneck for data requests
High volume of traffic due to data shipping
Client program executes application logic
Limited by processing capability of client workstation (memory, CPU)
Requires application code to be distributed to each client workstation

8. Advantages Disadvantages
Development Issues:
• Simple structure
• Easy to setup and maintain
• Complex application rules difficult to implement in database server – requires more code for the client
• Complex application rules difficult to implement in client and have poor performance
• Changes to business logic not automatically enforced by a server – changes require new client side software to be distributed and installed
• Not portable to other database server platforms
Performance:
• Adequate performance for low to medium volume environments
• Business logic and database are physically close, which provides higher performance.
• Inadequate performance for medium to high volume environments, since database server is required to perform business logic. This slows down database operations on database server.

9. 3-Tier Client/Server Architecture
3-Tier client-server architectures have 3 essential components:
A Client PC
An Application Server
A Database Server
3-Tier Architecture Considerations:
Client program contains presentation logic only
Less resources needed for client workstation
No client modification if database location changes
Less code to distribute to client workstations
One server handles many client requests
More resources available for server program
Reduces data traffic on the network

10. 3-Tier Client/Server Architecture

11. Advantages Disadvantages
Development Issues:
• Complex application rules easy to implement in application server
• Business logic off-loaded from database server and client, which improves performance
• Changes to business logic automatically enforced by server – changes require only new application server software to be installed
• Application server logic is portable to other database server platforms by virtue of the application software
• More complex structure
• More difficult to setup and maintain.
Performance:
• Superior performance for medium to high volume environments
• The physical separation of application servers containing business logic functions and database servers containing databases may moderately affect performance.

12. 3-Tier Architectures
A 3-tier architecture is one which has a client tier, a middle tier, and a database tier.
The database tier manages the database
The middle tier contains most of the logic and communicates between the other tiers
The client tier is the interface between the user and the system
An n-tier architecture is one which has n tiers, usually including a database tier, a client tier, and n-2 tiers in between.

13. Thin-Client 3-Tier Models
The thin-client 3-tier model has these tiers:
The database management system (DBMS)
The main application software
A web browser
Examples
Lotus Notes Web Client*
(*These may actually be n-tier)

14. Thick-Client 3-Tier Models
The thick-client 3-tier model has these tiers:
The database management system (DBMS)
The main application software
Some sort of interface software which must be installed on each client machine
Examples:
Lotus Notes
Desktop applets that display weather, etc.
RealPlayer and other applications that download CD information from the Web

15. Another 3-Tier Model Another common model has these tiers:
The database management system (DBMS) and a persistence manager which controls all data flow into and out of the database
The main application software
A GUI (thin or thick)
The main difference here is that the main application software is not allowed to interact directly with the database
You could also think of this as a 4-tier architecture:
The database management system (DBMS)
A persistence manager

16. n-Tier Models In general an n-tier model will have
The database management system (DBMS)
(n-2) application layers
A GUI (thin or thick)

17. n-Tier Questions
The following are important questions one must ask when thinking about n-tier architectures
How many tiers should be used?
What tasks should be done by each tier? In other words, how exactly should the layers be divided?
Should I use thin or thick clients?
Should the application be web-accessible?
How should connections to the database be managed?
What database management system (DBMS) should be used?
What languages(s), platform(s), and software should the system use?

18. n-Tier Answers The purpose of these notes is not to
Present clear answers to all of the questions on the previous slide
Be the authoritative source for information about n-tier architectures
Make you an expert in n-tier architectures
Rather, the purpose is to
Introduce you to the concept of n-tier architectures
Get you to start thinking about the issues involved
Give you partial answers to some of the question

19. Database Choices
There are many popular database management systems (DBMSs), including
IBM DB2
Oracle
Microsoft SQL Server
Microsoft Access
MySQL
Which one you should use depends on many factors, including number of expected users, size of the application and/or the database, budget, etc.
Fortunately, the interfaces to these DBMSs have a lot in common, so if you learn to use one, most of what you learn is transferable to the others

20. Middle Tier Choices JSP C# PHP .NET C++ ASP Perl
Almost anything is possible, with some common choices being
Java
JSP
PHP
C++
Perl
Visual Basic C#
.NET
ASP
However, whether or not the client will be thin or thick will influence this choice
For a thin client, the obvious middle tier choices are
Java applets, JSP, PHP, ASP, and Perl
Of course with all of these, HTML is involved as well

21. Client Choices
Thin clients are generally web browsers, so the important choice was made in the middle tier
For thick clients, we might use
Java applications
C++ applications with GUI provided by
MFC (Microsoft Foundation Classes)
Tcl/Tk (Tool command language)
GTK (Gimp ToolKit) Qt

22. MVC Architecture
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. The most important separation is between presentation and application logic.

23. MVC Controller Model View Controller
The domain-specific representation of the information on which the application operates. The model is another name for the application logic layer. Application (or domain) logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data.
View
Renders the model into a form suitable for interaction, typically a user interface element. 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
Processes and responds to events, typically user actions, and may invoke changes on the model and view.

24. MVC

25. MVC Control Flow The control flow generally works as follows:
The user interacts with the user interface in some way (e.g., user presses a button)
A controller handles the input event from the user interface, often via a registered handler or callback.
The controller accesses the model, possibly updating it in a way appropriate to the user’s action (e.g., controller updates user’s shopping cart). Complex controllers are often structured using the command pattern to encapsulate actions and simplify extension.
A view uses the model to generate an appropriate user interface (e.g., view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view. (However, the observer pattern can be used to allow the model to indirectly notify interested parties, potentially including views, of a change.)
The user interface waits for further user interactions, which begins the cycle a new.

26. MVC and Java EE