MVC and other n-tier Architectures

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.

Traditional Host Systems

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.

Distributed Systems

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

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.

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

3-Tier Client/Server Architecture

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.

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.

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 http://cse.unl.edu/~sscott/teach http://contests.unl.edu http://ebay.com* http://amazon.com* Lotus Notes Web Client* (*These may actually be n-tier)

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

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

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)

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?

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

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

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

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

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.

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.

MVC

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.

MVC and Java EE