Improve how you architect webapps

Patterns.dev is a free online resource on design, rendering, and performance patterns for building powerful web apps with vanilla JavaScript or modern frameworks.

Introduction to Design Patterns

Introduction

Introduction to Design Patterns

Share a single global instance throughout our application

Singleton Pattern

Share a single global instance throughout our application

Intercept and control interactions to target objects

Proxy Pattern

Intercept and control interactions to target objects

Share properties among many objects of the same type

Prototype Pattern

Share properties among many objects of the same type

Use observables to notify subscribers when an event occurs

Observer Pattern

Use observables to notify subscribers when an event occurs

Split up your code into smaller, reusable pieces

Module Pattern

Split up your code into smaller, reusable pieces

Add functionality to objects or classes without inheritance

Mixin Pattern

Add functionality to objects or classes without inheritance

Use a central mediator object to handle communication between components

Mediator/Middleware Pattern

Use a central mediator object to handle communication between components

Reuse existing instances when working with identical objects

Flyweight Pattern

Reuse existing instances when working with identical objects

Use a factory function in order to create objects

Factory Pattern

Use a factory function in order to create objects

An introduction to animating page transitions using the View Transitions API and libraries

Animating View Transitions

An introduction to animating page transitions using the View Transitions API and libraries

Learn how to optimize your loading sequence to improve how quickly your app is usable

Optimize your loading sequence

Learn how to optimize your loading sequence to improve how quickly your app is usable

Import code that has been exported by another module

Static Import

Import code that has been exported by another module

Import parts of your code on demand

Dynamic Import

Import parts of your code on demand

Load non-critical components when they are visible in the viewport

Import On Visibility

Load non-critical components when they are visible in the viewport

Load non-critical resources when a user interacts with UI requiring it

Import On Interaction

Load non-critical resources when a user interacts with UI requiring it

Dynamically load components based on the current route

Route Based Splitting

Dynamically load components based on the current route

Split your code into small, reusable pieces

Bundle Splitting

Split your code into small, reusable pieces

Optimize initial load through precaching, lazy loading, and minimizing roundtrips

PRPL Pattern

Optimize initial load through precaching, lazy loading, and minimizing roundtrips

Reduce the bundle size by eliminating dead code

Tree Shaking

Reduce the bundle size by eliminating dead code

Inform the browser of critical resources before they are discovered

Inform the browser of critical resources before they are discovered

Fetch and cache resources that may be requested some time soon

Fetch and cache resources that may be requested some time soon

Reduce the performance impact third-party scripts have on your site.

Optimize loading third-parties

Reduce the performance impact third-party scripts have on your site.

Optimize list performance with list virtualization

List Virtualization

Optimize list performance with list virtualization

Reduce the time needed to transfer scripts over the network.

Compressing JavaScript

Reduce the time needed to transfer scripts over the network.

A UI library for building reusable user interface components

Overview of React.js

A UI library for building reusable user interface components

Vercel's framework for hybrid React applications

Overview of Next.js

Vercel's framework for hybrid React applications

Enforce separation of concerns by separating the view from the application logic

Container/Presentational Pattern

Enforce separation of concerns by separating the view from the application logic

Pass reusable logic down as props to components throughout your application

HOC Pattern

Pass reusable logic down as props to components throughout your application

Pass JSX elements to components through props

Render Props Pattern

Pass JSX elements to components through props

Use functions to reuse stateful logic among multiple components throughout the app

Hooks Pattern

Use functions to reuse stateful logic among multiple components throughout the app

Create multiple components that work together to perform a single task

Compound Pattern

Create multiple components that work together to perform a single task

Render your application's UI on the client

Client-side Rendering

Render your application's UI on the client

Generate HTML to be rendered on the server in response to a user request

Server-side Rendering

Generate HTML to be rendered on the server in response to a user request

Deliver pre-rendered HTML content that was generated when the site was built

Static Rendering

Deliver pre-rendered HTML content that was generated when the site was built

Update static content after you have built your site

Incremental Static Generation

Update static content after you have built your site

Delay loading JavaScript for less important parts of the page

Progressive Hydration

Delay loading JavaScript for less important parts of the page

Generate HTML to be rendered on the server in response to a user request

Streaming Server-Side Rendering

Server Components compliment SSR, rendering to an intermediate abstraction without needing to add to the JavaScript bundle

React Server Components

Server Components compliment SSR, rendering to an intermediate abstraction without needing to add to the JavaScript bundle

With Next.js, there are several components that can help improve Core Web Vitals metrics

Optimize Next.js apps for the Core Web Vitals

With Next.js, there are several components that can help improve Core Web Vitals metrics

Introduction to Vue Patterns

Introduction to Vue Patterns

Self-contained modules that couple markup (HTML), logic (JS), and styles (CSS) within them

Self-contained modules that couple markup (HTML), logic (JS), and styles (CSS) within them

Optimize web app performance by asynchronously loading components.

Async Components

Optimize web app performance by asynchronously loading components.

Functions to encapsulate and reuse stateful logic among multiple components

Composables

Functions to encapsulate and reuse stateful logic among multiple components

Enforce separation of concerns by separating the view from the application logic

Data Provider Pattern

Utilize renderless components for managing and providing data

Dynamic Components

Dynamically switch between components with the special <component> element

Have nested components access data without using props

Provide/Inject

Have nested components access data without using props

Create component templates with programmatic JavaScript

Render functions

Create component templates with programmatic JavaScript

Components that don't render their own markup

Renderless components

Components that don't render their own markup

Compile-time syntactic sugar for using the Composition API

<script setup>

Compile-time syntactic sugar for using the Composition API

Manage application level state between components

State Management

Manage application level state between components

How Patterns.dev works

We publish patterns, tips and tricks for improving how you architect apps for free. Keep in mind, design patterns are descriptive, not prescriptive . They can guide you when facing a problem other developers have encountered many times before, but are not a blunt tool for jamming into every scenario. Patterns.dev aims to be a catalog of patterns (for increasing awareness) rather than a checklist (what you must do).

Practical examples on CodeSandbox

Codesandbox

Learn Visually with our animations

Flow chart

Powerful suite of patterns

Design patterns are a fundamental part of software development, as they provide typical solutions to commonly recurring problems in software design.

We offer a modern perspective on patterns

A common critique of design patterns is that they needlessly add complexity.

Our perspective is that patterns are valuable for solving specific problems, often helping to communicate comminalities in code problems for humans. If a project doesn't have those problems, there isn't a need to apply them. Patterns can also be very language or framework-specific (e.g. React), which can often mean thinking beyond the scope of just the original GoF design patterns.

We help you scale your webapps for performance

Learn about web performance patterns for loading your code more efficiently. Unsure how to think about modern approaches to loading or rendering user-experiences? We've got you covered.

Application Architecture Guide - Chapter 10 - Presentation Layer Guidelines

Note - The patterns & practices Microsoft Application Architecture Guide, 2nd Edition is now live at http://msdn.microsoft.com/en-us/library/dd673617.aspx .

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

  • 1 Objectives
  • 3 Presentation Layer Components
  • 5 Design Considerations
  • 6 Presentation Layer Frame
  • 8 Composition
  • 9 Exception Management
  • 12 Navigation
  • 13 Presentation Entities
  • 14 Request Processing
  • 15 User Experience
  • 16 UI Components
  • 17 UI Process Components
  • 18 Validation
  • 19 Pattern Map
  • 20 Pattern Descriptions
  • 21.1 Mobile Applications
  • 21.2 Rich Client Applications
  • 21.3 Rich Internet Applications (RIA)
  • 21.4 Web Applications
  • 22 patterns & practices Solution Assets
  • 23 Additional Resources
  • Understand how the presentation layer fits into typical application architecture.
  • Understand the components of the presentation layer.
  • Learn the steps for designing the presentation layer.
  • Learn the common issues faced while designing the presentation layer.
  • Learn the key guidelines for designing the presentation layer.
  • Learn the key patterns and technology considerations for designing the presentation layer.

The presentation layer contains the components that implement and display the user interface and manage user interaction. This layer includes controls for user input and display, in addition to components that organize user interaction. Figure 1 shows how the presentation layer fits into a common application architecture.

web presentation patterns

Figure 1 A typical application showing the presentation layer and the components it may contain

Presentation Layer Components

  • User interface (UI) components . User interface components provide a way for users to interact with the application. They render and format data for users. They also acquire and validate data input by the user.
  • User process components . User process components synchronize and orchestrate user interactions. Separate user process components may be useful if you have a complicated UI. Implementing common user interaction patterns as separate user process components allows you to reuse them in multiple UIs.

The following steps describe the process you should adopt when designing the presentation layer for your application. This approach will ensure that you consider all of the relevant factors as you develop your architecture:

  • Identify your client type . Choose a client type that satisfies your requirements and adheres to the infrastructure and deployment constraints of your organization. For instance, if your users are on mobile devices and will be intermittently connected to the network, a mobile rich client is probably your best choice.
  • Determine how you will present data . Choose the data format for your presentation layer and decide how you will present the data in your UI.
  • Determine your data-validation strategy . Use data-validation techniques to protect your system from untrusted input.
  • Determine your business logic strategy . Factor out your business logic to decouple it from your presentation layer code.
  • Determine your strategy for communication with other layers . If your application has multiple layers, such as a data access layer and a business layer, determine a strategy for communication between your presentation layer and other layers.

Design Considerations

There are several key factors that you should consider when designing your presentation layer. Use the following principles to ensure that your design meets the requirements for your application, and follows best practices:

  • Choose the appropriate UI technology. Determine if you will implement a rich (smart) client, a Web client, or a rich Internet application (RIA). Base your decision on application requirements, and on organizational and infrastructure constraints.
  • Use the relevant patterns. Review the presentation layer patterns for proven solutions to common presentation problems.
  • Design for separation of concerns. Use dedicated UI components that focus on rendering and display. Use dedicated presentation entities to manage the data required to present your views. Use dedicated UI process components to manage the processing of user interaction.
  • Consider human interface guidelines. Review your organization’s guidelines for UI design. Review established UI guidelines based on the client type and technologies that you have chosen.
  • Adhere to user-driven design principles. Before designing your presentation layer, understand your customer. Use surveys, usability studies, and interviews to determine the best presentation design to meet your customer’s requirements.

Presentation Layer Frame

There are several common issues that you must consider as your develop your design. These issues can be categorized into specific areas of the design. The following table lists the common issues for each category where mistakes are most often made.

Table 1 Presentation Layer Frame

Caching is one of the best mechanisms you can use to improve application performance and UI responsiveness. Use data caching to optimize data lookups and avoid network round trips. Cache the results of expensive or repetitive processes to avoid unnecessary duplicate processing.

Consider the following guidelines when designing your caching strategy:

  • Do not cache volatile data.
  • Consider using ready-to-use cache data when working with an in-memory cache. For example, use a specific object instead of caching raw database data.
  • Do not cache sensitive data unless you encrypt it.
  • If your application is deployed in Web farm, avoid using local caches that need to be synchronized; instead, consider using a transactional resource manager such as Microsoft SQL Server® or a product that supports distributed caching.
  • Do not depend on data still being in your cache. It may have been removed.

Composition

Consider whether your application will be easier to develop and maintain if the presentation layer uses independent modules and views that are easily composed at run time. Composition patterns support the creation of views and the presentation layout at run time. These patterns also help to minimize code and library dependencies that would otherwise force recompilation and redeployment of a module when the dependencies change. Composition patterns help you to implement sharing, reuse, and replacement of presentation logic and views.

Consider the following guidelines when designing your composition strategy:

  • Avoid using dynamic layouts. They can be difficult to load and maintain.
  • Be careful with dependencies between components. For example, use abstraction patterns when possible to avoid issues with maintainability.
  • Consider creating templates with placeholders. For example, use the Template View pattern to compose dynamic Web pages in order to ensure reuse and consistency.
  • Consider composing views from reusable modular parts. For example, use the Composite View pattern to build a view from modular, atomic component parts.
  • If you need to allow communication between presentation components, consider implementing the Publish/Subscribe pattern. This will lower the coupling between the components and improve testability.

Exception Management

Design a centralized exception-management mechanism for your application that catches and throws exceptions consistently. Pay particular attention to exceptions that propagate across layer or tier boundaries, as well as exceptions that cross trust boundaries. Design for unhandled exceptions so they do not impact application reliability or expose sensitive information.

Consider the following guidelines when designing your exception management strategy:

  • Use user-friendly error messages to notify users of errors in the application.
  • Avoid exposing sensitive data in error pages, error messages, log files, and audit files.
  • Design a global exception handler that displays a global error page or an error message for all unhandled exceptions.
  • Differentiate between system exceptions and business errors. In the case of business errors, display a user-friendly error message and allow the user to retry the operation. In the case of system exceptions, check to see if the exception was caused by issues such as system or database failure, display a user-friendly error message, and log the error message, which will help in troubleshooting.
  • Avoid using exceptions to control application logic.

Design a user input strategy based on your application input requirements. For maximum usability, follow the established guidelines defined in your organization, and the many established industry usability guidelines based on years of user research into input design and mechanisms.

Consider the following guidelines when designing your input collection strategy:

  • Use forms-based input controls for normal data-collection tasks.
  • Use a document-based input mechanism for collecting input in Microsoft Office–style documents.
  • Implement a wizard-based approach for more complex data collection tasks, or for input that requires a workflow.
  • Design to support localization by avoiding hard-coded strings and using external resources for text and layout.
  • Consider accessibility in your design. You should consider users with disabilities when designing your input strategy; for example, implement text-to-speech software for blind users, or enlarge text and images for users with poor sight. Support keyboard-only scenarios where possible for users who cannot manipulate a pointing device.

Design your UI layout so that the layout mechanism itself is separate from the individual UI components and UI process components. When choosing a layout strategy, consider whether you will have a separate team of designers building the layout, or whether the development team will create the UI. If designers will be creating the UI, choose a layout approach that does not require code or the use of development-focused tools.

Consider the following guidelines when designing your layout strategy:

  • Use templates to provide a common look and feel to all of the UI screens.
  • Use a common look and feel for all elements of your UI to maximize accessibility and ease of use.
  • Consider device-dependent input, such as touch screens, ink, or speech, in your layout. For example, with touch-screen input you will typically use larger buttons with more spacing between them than you would with mouse or keyboard inputs.
  • When building a Web application, consider using Cascading Style Sheets (CSS) for layout. This will improve rendering performance and maintainability.
  • Use design patterns, such as Model-View-Presenter (MVP), to separate the layout design from interface processing.

Design your navigation strategy so that users can navigate easily through your screens or pages, and so that you can separate navigation from presentation and UI processing. Ensure that you display navigation links and controls in a consistent way throughout your application to reduce user confusion and hide application complexity.

Consider the following guidelines when designing your navigation strategy:

  • Use well-known design patterns to decouple the UI from the navigation logic where this logic is complex.
  • Design toolbars and menus to help users find functionality provided by the UI.
  • Consider using wizards to implement navigation between forms in a predictable way.
  • Determine how you will preserve navigation state if the application must preserve this state between sessions.
  • Consider using the Command Pattern to handle common actions from multiple sources.

Presentation Entities

Use presentation entities to store the data you will use in your presentation layer to manage your views. Presentation entities are not always necessary; use them only if your datasets are sufficiently large and complex to require separate storage from the UI controls.

Consider the following guidelines when designing presentation entities:

  • Determine if you require presentation entities. Typically, you may require presentation entities only if the data or the format to be displayed is specific to the presentation layer.
  • If you are working with data-bound controls, consider using custom objects, collections, or datasets as your presentation entity format.
  • If you want to map data directly to business entities, use a custom class for your presentation entities.
  • Do not add business logic to presentation entities.
  • If you need to perform data type validation, consider adding it in your presentation entities.

Request Processing

Design your request processing with user responsiveness in mind, as well as code maintainability and testability.

Consider the following guidelines when designing request processing:

  • Use asynchronous operations or worker threads to avoid blocking the UI for long-running actions.
  • Avoid mixing your UI processing and rendering logic.
  • Consider using the Passive View pattern (a variant of MVP) for interfaces that do not manage a lot of data.
  • Consider using the Supervising Controller pattern (a variant of MVP) for interfaces that manage large amounts of data.

User Experience

Good user experience can make the difference between a usable and unusable application. Carry out usability studies, surveys, and interviews to understand what users require and expect from your application, and design with these results in mind.

Consider the following guidelines when designing for user experience:

  • When developing a rich Internet application (RIA), avoid synchronous processing where possible.
  • When developing a Web application, consider using Asynchronous JavaScript and XML (AJAX) to improve responsiveness and to reduce post backs and page reloads.
  • Do not design overloaded or overly complex interfaces. Provide a clear path through the application for each key user scenario.
  • Design to support user personalization, localization, and accessibility.
  • Design for user empowerment. Allow the user to control how he or she interacts with the application, and how it displays data to them.

UI Components

UI components are the controls and components used to display information to the user and accept user input. Be careful not to create custom controls unless it is necessary for specialized display or data collection.

Consider the following guidelines when designing UI components:

  • Take advantage of the data-binding features of the controls you use in the UI.
  • Create custom controls or use third-party controls only for specialized display and data-collection tasks.
  • When creating custom controls, extend existing controls if possible instead of creating a new control.
  • Consider implementing designer support for custom controls to make it easier to develop with them.
  • Consider maintaining the state of controls as the user interacts with the application instead of reloading controls with each action.

UI Process Components

UI process components synchronize and orchestrate user interactions. UI processing components are not always necessary; create them only if you need to perform significant processing in the presentation layer that must be separated from the UI controls. Be careful not to mix business and display logic within the process components; they should be focused on organizing user interactions with your UI.

Consider the following guidelines when designing UI processing components:

  • Do not create UI process components unless you need them.
  • If your UI requires complex processing or needs to talk to other layers, use UI process components to decouple this processing from the UI.
  • Consider dividing UI processing into three distinct roles: Model, View, and Controller/Presenter, by using the MVC or MVP pattern.
  • Avoid business rules, with the exception of input and data validation, in UI processing components.
  • Consider using abstraction patterns, such as dependency inversion, when UI processing behavior needs to change based on the run-time environment.
  • Where the UI requires complex workflow support, create separate workflow components that use a workflow system such as Windows Workflow or a custom mechanism.

Designing an effective input and data-validation strategy is critical to the security of your application. Determine the validation rules for user input as well as for business rules that exist in the presentation layer.

Consider the following guidelines when designing your input and data validation strategy:

  • Validate all input data on the client side where possible to improve interactivity and reduce errors caused by invalid data.
  • Do not rely on client-side validation only. Always use server-side validation to constrain input for security purposes and to make security-related decisions.
  • Design your validation strategy to constrain, reject, and sanitize malicious input.
  • Use the built-in validation controls where possible, when working with .NET Framework.
  • In Web applications, consider using AJAX to provide real-time validation.

Pattern Map

Key patterns are organized by key categories, as detailed in the Presentation Layer Frame in the following table. Consider using these patterns when making design decisions for each category.

Table 2 Pattern Map

  • For more information on the Page Cache pattern, see “Enterprise Solution Patterns Using Microsoft .NET” at http://msdn.microsoft.com/en-us/library/ms998469.aspx
  • For more information on the Model-View-Controller (MVC), Page Controller, Front Controller, Template View, Transform View, and Two-Step View patterns, see “Patterns of Enterprise Application Architecture (P of EAA)” at http://martinfowler.com/eaaCatalog/
  • For more information on the Composite View, Supervising Controller, and Presentation Model patterns, see “Patterns in the Composite Application Library” at http://msdn.microsoft.com/en-us/library/cc707841.aspx
  • For more information on the Chain of responsibility and Command pattern, see “data & object factory” at http://www.dofactory.com/Patterns/Patterns.aspx
  • For more information on the Asynchronous Callback pattern, see “Creating a Simplified Asynchronous Call Pattern for Windows Forms Applications” at http://msdn.microsoft.com/en-us/library/ms996483.aspx
  • For more information on the Exception Shielding and Entity Translator patterns, see “Useful Patterns for Services” at http://msdn.microsoft.com/en-us/library/cc304800.aspx

Pattern Descriptions

  • Asynchronous Callback. Execute long-running tasks on a separate thread that executes in the background, and provide a function for the thread to call back into when the task is complete.
  • Cache Dependency. Use external information to determine the state of data stored in a cache.
  • Chain of Responsibility. Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
  • Composite View . Combine individual views into a composite representation.
  • Command Pattern. Encapsulate request processing in a separate command object with a common execution interface.
  • Entity Translator. An object that transforms message data types into business types for requests, and reverses the transformation for responses.
  • Exception Shielding. Prevent a service from exposing information about its internal implementation when an exception occurs.
  • Front Controller . Consolidate request handling by channeling all requests through a single handler object, which can be modified at run time with decorators.
  • Model-View-Controller . Separate the UI code into three separate units: Model (data), View (interface), and Presenter (processing logic), with a focus on the View. Two variations on this pattern include Passive View and Supervising Controller, which define how the View interacts with the Model.
  • Page Cache. Improve the response time for dynamic Web pages that are accessed frequently but change less often and consume a large amount of system resources to construct.
  • Page Controller . Accept input from the request and handle it for a specific page or action on a Web site.
  • Passive View . Reduce the view to the absolute minimum by allowing the controller to process user input and maintain the responsibility for updating the view.
  • Presentation Model . Move all view logic and state out of the view, and render the view through data-binding and templates.
  • Supervising Controller . A variation of the MVC pattern in which the controller handles complex logic, in particular coordinating between views, but the view is responsible for simple view-specific logic.
  • Template View . Implement a common template view, and derive or construct views using this template view.
  • Transform View . Transform the data passed to the presentation tier into HTML for display in the UI.
  • Two-Step View . Transform the model data into a logical presentation without any specific formatting, and then convert that logical presentation to add the actual formatting required.

Technology Considerations

The following guidelines will help you to choose an appropriate implementation technology. The guidelines also contain suggestions for common patterns that are useful for specific types of application and technology.

Mobile Applications

Consider the following guidelines when designing a mobile application:

  • If you want to build full-featured connected, occasionally connected, and disconnected executable applications that run on a wide range of Microsoft Windows®–based devices, consider using the Microsoft Windows Compact Framework.
  • If you want to build connected applications that require Wireless Application Protocol (WAP), compact HTML (cHTML), or similar rendering formats, consider using ASP.NET Mobile Forms and Mobile Controls.
  • If you want to build applications that support rich media and interactivity, consider using Microsoft Silverlight® for Mobile.

Rich Client Applications

Consider the following guidelines when designing a rich client application:

  • If you want to build applications with good performance and interactivity, and have design support in Microsoft Visual Studio®, consider using Windows Forms.
  • If you want to build applications that fully support rich media and graphics, consider using Windows Presentation Foundation (WPF).
  • If you want to build applications that are downloaded from a Web server and then execute on the client, consider using XAML Browser Applications (XBAP).
  • If you want to build applications that are predominantly document-based, or are used for reporting, consider designing a Microsoft Office Business Application.
  • If you decide to use Windows Forms and you are designing composite interfaces, consider using the Smart Client Software Factory.
  • If you decide to use WPF and you are designing composite interfaces, consider using the Composite Application Guidance for WPF.
  • If you decide to use WPF, consider using the Presentation Model (Model-View-ViewModel) pattern.
  • If you decide to use WPF, consider using WPF Commands to communicate between your View and your Presenter or ViewModel.
  • If you decide to use WPF, consider implementing the Presentation Model pattern by using DataTemplates over User Controls to give designers more control.

Rich Internet Applications (RIA)

Consider the following guidelines when designing an RIA:

  • If you want to build browser-based, connected applications that have broad cross-platform reach, are highly graphical, and support rich media and presentation features, consider using Silverlight.
  • If you decide to use Silverlight, consider using the Presentation Model (Model-View-ViewModel) pattern.

Web Applications

Consider the following guidelines when designing a Web application:

  • If you want to build applications that are accessed through a Web browser or specialist user agent, consider using ASP.NET.
  • If you want to build applications that provide increased interactivity and background processing, with fewer page reloads, consider using ASP.NET with AJAX.
  • If you want to build applications that include islands of rich media content and interactivity, consider using ASP.NET with Silverlight controls.
  • If you are using ASP.NET and want to implement a control-centric model with separate controllers and improved testability, consider using the ASP.NET MVC Framework.
  • If you are using ASP.NET, consider using master pages to simplify development and implement a consistent UI across all pages.

patterns & practices Solution Assets

  • Web Client Software Factory at http://msdn.microsoft.com/en-us/library/bb264518.aspx
  • Smart Client Software Factory at http://msdn.microsoft.com/en-us/library/aa480482.aspx
  • Composite Application Guidance for WPF at http://msdn.microsoft.com/en-us/library/cc707819.aspx
  • Smart Client - Composite UI Application Block at http://msdn.microsoft.com/en-us/library/aa480450.aspx

Additional Resources

  • For more information, see Microsoft Inductive User Interface Guidelines at http://msdn.microsoft.com/en-us/library/ms997506.aspx .
  • For more information, see User Interface Control Guidelines at http://msdn.microsoft.com/en-us/library/bb158625.aspx .
  • For more information, see User Interface Text Guidelines at http://msdn.microsoft.com/en-us/library/bb158574.aspx .
  • For more information, see Design and Implementation Guidelines for Web Clients at http://msdn.microsoft.com/en-us/library/ms978631.aspx .
  • For more information, see Web Presentation Patterns at http://msdn.microsoft.com/en-us/library/ms998516.aspx .

Navigation menu

Page actions.

  • View source

Personal tools

  • Community portal
  • Current events
  • Recent changes
  • Random page
  • What links here
  • Related changes
  • Special pages
  • Printable version
  • Permanent link
  • Page information

Powered by MediaWiki

  • This page was last edited on 22 January 2010, at 02:50.
  • Privacy policy
  • About Guidance Share
  • Disclaimers

Book cover

Modern Web Performance Optimization pp 273–300 Cite as

Modern Web Performance Patterns

  • Shailesh Kumar Shivakumar 2  
  • First Online: 25 November 2020

961 Accesses

Modern web platforms need high performance to fulfill the expectations of Internet users, and elastic scalability to absorb increased user loads, data loads, and high availability. The presentation layer has seen maximum disruption in terms of challenges and technologies. The crucial success factors for the presentation layer are performance, interactivity, responsiveness, and availability. Web users expect seamless rendering of modern web platforms on various devices and channels with optimal performance. Modern web platforms should scale to a large volume of web users.

This is a preview of subscription content, log in via an institution .

Buying options

  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
  • Available as EPUB and PDF
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Author information

Authors and affiliations.

Bengaluru, India

Shailesh Kumar Shivakumar

You can also search for this author in PubMed   Google Scholar

Rights and permissions

Reprints and permissions

Copyright information

© 2020 Shailesh Kumar Shivakumar

About this chapter

Cite this chapter.

Shivakumar, S.K. (2020). Modern Web Performance Patterns. In: Modern Web Performance Optimization. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-6528-4_10

Download citation

DOI : https://doi.org/10.1007/978-1-4842-6528-4_10

Published : 25 November 2020

Publisher Name : Apress, Berkeley, CA

Print ISBN : 978-1-4842-6527-7

Online ISBN : 978-1-4842-6528-4

eBook Packages : Business and Management Business and Management (R0) Apress Access Books

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

  • Publish with us

Policies and ethics

  • Find a journal
  • Track your research

LIFE & TIMES of a WEB DEVELOPER

Web presentation patterns.

Another article of mine has made its appearance on Digital Web. In Web Presentation Patterns , I quickly touch on design patterns in general and then touch on MVC, page controller, and front controller has various implementations of design patterns. Best of all are probably the resources at the bottom. Plenty of stuff to get you into and excited about design patterns.

Conversation

Hi Jonathan, Saw your article on web patterns...looks good. You've cited Martin Fowler's and others work in this area and there's some overlap with our work, as well, so I thought I'd encourage you to have a look and let me know what you think... (www.corej2eepatterns.com). We've worked to sync our pattern catalogue with Martin, who also helped review some of our content. While our book is called Core J2EE Patterns, the patterns themselves are really Enterprise patterns that are bound to a platform (in this case J2EE) through the numerous implementation strategies that are provided. The encouraging thing is that these patterns are relevant regardless of your platform and we can all share a similar vocabulary and approach to good design, through the judicious use of patterns.

Look forward to hearing your comments.

Thanks, Dan Malks

In looking through the catalog, the demonstration of how various patterns link together is excellent. The J2EE terminology may scare off those who use other languages but it looks like you've done a good job catalouging and providing strategies for each pattern. I might have to pick up the book sometime.

Hi. My name is Jonathan Snook and this is my site. I write about what interests me, which is usually web design, development, and technology. Check out my projects . Want to learn more ?

© Jonathan Snook

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Cutting Edge

ASP.NET Presentation Patterns

Dino Esposito

This column is based on a prerelease version of the ASP.NET MVC Framework. All information is subject to change.

Inside an ASP.NET Event Handler The Original MVC Pattern Model2: A Web Variation of MVC ASP.NET MVC Framework vs. Manual MVC The MVP Pattern The Page Controller Pattern

In a layered Web app, the presentation layer is just as important as navigation logic, business logic, and data access. While you should try to keep the presentation layer (mostly the presentation logic) independent from the UI technology and platform, it's not always easy to do. Design patterns can help.

In this month's column, I'll examine some design patterns for building an ASP.NET presentation layer. I'll start with the Model-View-Controller (MVC) pattern—the root of all patterns specifically targeted to the UI—and discuss its applicability to ASP.NET beyond the ASP.NET MVC Framework.

Inside an ASP.NET Event Handler

An ASP.NET presentation layer is composed mostly of .aspx pages that are orchestrated by the HTTP runtime environment. A typical .aspx page, at some point, may place an HTTP request following a certain user's action (such as a button click or a list selection). In ASP.NET Web Forms programming, these events are usually handled by methods—event handlers—written in the codebehind class of the page. At first glance, it would appear that there's a direct connection between the user action and the system's reaction. While this may be true in desktop applications, it is not the case in ASP.NET.

In ASP.NET, a lot of things happen in the time between a user click and the display of an updated page—regardless of whether or not you're using AJAX. The flow of information is shorter, however, in ASP.NET applications that you build with the ASP.NET MVC Framework.

Let's consider a button click event. As a developer, you handle it by writing some code in the Button control's Click event handler. The code goes in the page's codebehind, like so:

You could place all the code for the required action here. Or, you could group all of this code in a static or instance method exposed by an object:

You could also organize the code that responds to the user's activity in controllers and actions:

I'm assuming that each page has its own controller component and that each controller has a list of public methods logically bound to a possible user action.

How would you let the controller know the state of the page and how the new view is generated? Button1_Click is invoked on the server after the user has clicked the button and the ASP.NET runtime has received and processed the corresponding HTTP request. The Button1_Click method is exposed by a class derived from System.Web.UI.Page. This class has access to UI controls.

Here's a simple change to the controller's signature that would enable the controller to access any public element in the page:

The controller's signature now receives a reference to the current ASP.NET page—the view. The controller method performs its work and then simply updates server controls. The standard page lifecycle of ASP.NET will do the rest and produce the HTML for the browser.

The Page Lifecycle

Figure 1 shows the main steps in the page lifecycle. Whenever an ASP.NET request hits the Web server and an HTTP handler is found to service it, the steps outlined in the figure are performed. As you can see, the code for a simple click of a button is only a small fraction of the whole ASP.NET infrastructure. You'll see in a moment that the page lifecycle represents a fraction of the work that the ASP.NET runtime executes to service each request.

Figure 1 The ASP.NET Page Lifecycle

Before the code in Button1_Click can execute, the ASP.NET runtime creates an instance of the Page class that holds the expected behavior for the requested URL. The Page class processes the request according to the steps in Figure 1 and uses your event handlers where appropriate.

In the Button1Clicked method in a controller class, you should be able to access any of the controls in the page with the same syntax you would use in a plain codebehind event handler. But members that reference UI controls (say, TextBox1) are not public members on the Page class. How can you make them accessible to a controller? You can implement a custom interface on the codebehind class that includes public properties for the UI controls you intend to manipulate from within the controller. Here's an example:

Figure 2 provides an example of the sample controller. In Button1Clicked, you do your regular ASP.NET Web Forms programming and determine the next view by simply updating the state of server controls. The logic of the page is now encapsulated in a separate class that can be developed separately from the page.

Figure 2 A Sample Class Acting as the Controller for a Page

This solution, though, is still tightly coupled to the controls in the page. Let's consider a refinement that refers to the Model-View-Presenter (MVP) pattern. I'll briefly recall the basics of the MVC and MVP patterns.

The Original MVC Pattern

The MVC pattern was devised back in 1979 as an approach to move away from catch-all, autonomous front ends. An autonomous view is a class that displays content, maintains state information for the view, and incorporates the full logic to handle any user actions from start to finish.

This code snippet lays the groundwork for an autonomous view:

With such a monolithic view, you can hardly build a testable presentation layer that's separate from the underlying layers. Applying the concept of Separation of Concerns (SoC) helps you to get the right combination of low coupling and high cohesion for any component, because it causes you to keep the various functionalities in their own layers rather than intermingled. Second, SoC makes it easier to implement a navigational workflow to decide which page comes next.

The original paper describing the MVC approach, " How to Use Model-View-Controller ," is available online. If you've never read it, I suggest you have a look at it regardless of your familiarity with the MVC philosophy. Today, MVC is considered a pattern for building a presentation layer, but it was originally meant for building complete applications. It's helpful to look at it in this light.

MVC is a loosely defined pattern that gives the architect much discretion over implementation details. This is probably why so many variations of MVC exist.

MVC splits the app into three parts—the model, the view, and the controller. The model refers to the application data, manages the application's functionalities, and notifies the view of state changes. The view is concerned with the content to display to users. Finally, the controller maps user gestures to actions on the model and updates the current view or selects the next view. These three actors are often referred to as the MVC triad. Figure 3 provides a graphical comparison between autonomous views and MVC applications.

Figure 3 From Autonomous View to MVC

In MVC, the user interacts with the view, and actions (such as a button click) are captured by the view and forwarded to the controller. The controller decides what to do and does it through an interaction with the model. The model is essentially the business layer plus some extra capabilities. In particular, the model notifies the view about changes that may require an update of the UI.

The model doesn't know any details of the view, but between model and view there's an "observer" relationship. In other words, the view holds a reference to the model and registers itself with the model to receive a notification of changes. When the notification is received, the view gets fresh data from the model and updates the UI. Figure 4 illustrates a sequence diagram of an MVC interaction. Note that in some MVC implementations , it's the controller that notifies the view of the changes.

Figure 4 A Standard MVC Interaction (Click the image for a larger view)

Model2: A Web Variation of MVC

MVC was devised to target desktop applications, but because of its relatively loose formulation, it was easily adapted for the Web. A popular Web variation of the MVC pattern is Model2. Model2 is the historical name of the pattern that fuels the ASP.NET MVC Framework today.

The Model2 pattern exposes the view to users through the browser. User actions are captured by the browser and transformed into a new HTTP request. In this way, requests flow from the browser to a special component (referred to as the front controller) sitting within the Web server. The front controller coordinates all of the requests that are made to the Web application.

In ASP.NET, the front controller takes the form of the URL-routing HTTP module. The HTTP module captures the request and routes it to the appropriate controller for the requested action to take place. As the action method returns, the controller orders the view to refresh and passes fresh data for the new UI. The output of the view is captured by the front controller HTTP module and sent back to the browser.

Figure 5 shows the sequence diagram for a typical Model2 interaction. You should note that the diagram includes only the general steps. For example, in the ASP.NET MVC implementation of the pattern, the URL routing component does some work in addition to using the controller.

Figure 5 The Model2 Interaction as in the ASP.NET MVC Framework (Click the image for a larger view)

A few differences exist between the original MVC and Model2. As you can see, there's no contact between the view and the model as in the MVC original formulation based on the aforementioned "observer" relationship. The user action is not captured and handled by the view. The controller renders the view and explicitly passes display data to it.

In ASP.NET, when you say MVC you should specify whether you mean Model2 or a manual implementation of MVC, as briefly explained in the beginning of this column. (If you'd like to read more on the MSDN Magazine article ASP.NET MVC Framework .

ASP.NET MVC Framework vs. Manual MVC

Is there any difference at all between using the ASP.NET MVC Framework and rolling your own implementation of the MVC pattern in order to have a controller class for each page (or for a group of pages)? In terms of SoC, I don't see any significant differences. In both cases, you have a controller class that is neatly separated from the view and the model that represents the gateway to the business or service layer.

In terms of testability, the Model2 pattern is preferable over the original formulation of the MVC pattern because of the neat separation it forces between view and model and because of an extremely thin view. This aspect alone makes code written for the ASP.NET MVC Framework extremely effective to test. Furthermore, in Model2 there's a sort of loose contract that can be established between the view and the controller. In the ASP.NET MVC Framework, this contract is represented by the ViewData container object or, better yet, by the ViewPage<T> base class for view classes.

Compared with ASP.NET Web Forms, a Model2 implementation is also faster to execute the requested action. In a Model2 implementation, all you need is a component that processes the HTTP request and invokes a controller. There's no need to create page classes dynamically; the lookup for the controller is based on a much simpler algorithm than the lookup of an HTTP handler in a Web Forms scenario. Likewise, you don't need the page lifecycle, the viewstate, or server controls. In a Model2 implementation, such as the ASP.NET MVC Framework, you have a much more agile runtime environment. Let's explore it further.

In an MVC scenario implemented over the Web Forms programming model, any user action originates an HTTP post. The Web server captures these requests and maps them to a page class. The Page class goes through its own lifecycle, as shown in Figure 1 . Next, the Page class figures out the right controller and invokes a method. The execution of the method modifies the model. The remainder of the page lifecycle involves refreshing the view.

In a Model2 scenario implemented with the ASP.NET MVC Framework, the generation of the next view is a much simpler process. The URL routing module parses the URL, determines from it the controller to use, and invokes an action on it. Then the controller collects new data for the new view and passes this information on. The view assembles some HTML that is then returned to the browser as the response to the captured request. The view is a passive subject that needs virtually no testing. Instead, you focus your testing effort on the controller.

Model2 is an excellent alternative for improving the testability of an application. However, what if you still need the Web Forms runtime environment with its support for Session, Cache, server controls, and even viewstate that you get with the MVC pattern? Does this mean that you have to abandon SoC and testability? Certainly not. You can opt for the other variation of MVC that I mentioned at the outset—the MVP pattern. It applies to Web applications without requiring an ad hoc runtime.

The MVP Pattern

The original formulation of MVC has one key weakness: the mechanism that updates the view. The flow of information you observe in Figure 4 shows that the view communicates the user gesture to the controller but receives a notification of changes from the model. Next, the view needs to leverage its intimate knowledge of the model to grab updated data and refresh itself. MVP is a variation of MVC that separates the elements of the triad more cleanly. Figure 6 displays the typical interaction between the actors in an MVP model.

Figure 6 The MVP Pattern in Action (Click the image for a larger view)

In MVP, the view forwards user input to the presenter, and from the presenter it receives fresh data for updates. In turn, the presenter services the request by interacting with the model.

In the original MVC, there's no explicit contract that states which data the view needs. In MVC, the view holds a reference to the model and runs its own logic to select the data it needs and massage it into UI elements. Equipped with this logic, the view is not as passive as it should be for testing purposes. In addition, the view depends, to some extent, on the underlying UI platform.

In MVP, the presenter is essentially the mediator between end users and applications. The presenter has the power to render the view and interact with the model. As a result, most of the presentation logic lives within the presenter. Because the presenter is a plain class with no UI, it is an inherently more testable class. You can see a practical implementation of the MVP pattern in ASP.NET in the August 2006 MSDN Magazine Design Patterns column . MVP is natively supported by the Microsoft Web Client Software Factory, which is a collection of ASP.NET-related application blocks. An MVP QuickStart is available on MSDN.

MVP is a general UI pattern that, unlike Model2, is not specifically designed for the Web. Model2 (the ASP.NET MVC Framework) and MVP are nearly the same thing. Interestingly, neither was originally designed to be a general-purpose pattern.

Technically speaking, there's just one difference between Model2 and MVP: the contract between the controller (called the presenter in MVP) and the view. The contract is loosely defined in Model2 and formally defined in MVP.

In MVP, the view implements an interface, and the presenter talks to the view using only the members on the interface. So, for example, the presenter reads input data in the view using methods and getters in the interface and sets new values for the view using methods and/or setters in the interface. In Model2, you use a strongly typed container.

With MVP, the presentation logic gains independence from the UI platform, so it's easier to reuse the same presenter across different platforms. In addition, the same presenter can work with different views of the same application thus enabling Software as a Service (SaaS) scenarios. Finally, with MVP you have a component—the presenter—that may store some logic for navigation between pages. Whether you implement the logic internally or use a Windows Workflow Foundation (WF) component is up to you.

The Page Controller Pattern

MVC, Model2, and MVP are patterns external to the design of the ASP.NET runtime. The Web Forms programming model of ASP.NET is based on yet another design pattern—the Page Controller pattern. The Page Controller pattern entails the creation of a central object (the dynamically created class that inherits from your codebehind class) that handles all HTTP requests directed at a specific Web page (see Figure 7 ).

Figure 7 The Page Controller Structure

If you customize this pattern, you may get some benefits in terms of logic reuse across pages, including the navigation logic. You can customize it by simply creating a hierarchy of Page classes and incorporating navigation and presentation logic in the classes higher up in the hierarchy to make that logic available to derived classes. A customized page controller may be a good way to improve the reuse of presentation and navigation logic without switching to a full new pattern.

Applying MVP means essentially designing the codebehind class of pages in a different way by implementing an interface on the Page class and using a separate component—the presenter—to handle user gestures. No changes occur to the runtime environment, as the request is routed to the codebehind class in the usual way.

Creating an ASP.NET MVC Framework project means entering changes to the runtime environment to enable a front controller—the URL routing module—to resolve the request in terms of an action on a controller. Both options have an impact on the development of the application.

The first issue to assess is whether you need viewstate and server controls. There might be situations where you prefer not to deal with them. As an example, if you have no server controls, styling the UI using CSS is much easier. Using AJAX with server controls is currently easier than with an ASP.NET MVC Framework solution. Applications with a lot of data entry or complex table-based views are not so easy to build without rich server controls. So it is ultimately a trade-off. The key question is whether you need server controls and viewstate. There's no obvious answer.

If you decide you'd better stick to Web Forms and still want some SoC, then MVP is for you. MVP is an important UI pattern that may be a bit expensive to implement in relatively simple applications. On the other hand, MVP shines in enterprise-class applications where you really need to reuse as much presentation logic as possible, across multiple platforms and in SaaS scenarios.

Send your questions and comments for Dino to [email protected] .

Dino Esposito is an architect at IDesign and the coauthor of Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press, 2008). Based in Italy, Dino is a frequent speaker at industry events worldwide. You can join his blog at weblogs.asp.net/despos .

Additional resources

blog banner

Web Application Architecture: How the Web Works

  • Engineering
  • 25 Jul, 2019
  • No comments Share

What is Web Application Architecture?

  • addresses a particular problem, even if it’s simply finding some information
  • is as interactive as a desktop application
  • has a Content Management System

How does the web request work?

web request-response cycle

Web request-response cycle

Web application architecture components and Three-Tier Architecture

web application architecture

Web application architecture following the three-tier pattern

Presentation layer

Business layer, persistence layer, example #1. dynamic web pages, spas, and mpas, single page applications.

SPA architecture

Single Page Application architecture

Multi-Page Applications

multi-page applications

MPA architecture

Example #2. Enterprise applications

enterprise application architecture

Enterprise application architecture

To conclude

Subscribe to our newsletter.

Stay tuned to the latest industry updates.

Latest Engineering Articles

secret key

OAuth Authorization Framework: How to Use It and Build Trust Online

Non-functional

Nonfunctional Requirements in Software Engineering: Examples, Types, Best Practices

orm

The Good and the Bad of Terraform Infrastructure-as-Code Tool

Join us on the techtalks.

Discover new opportunities for your travel business, ask about the integration of certain technology, and of course - help others by sharing your experience.

Write an article for our blog

Almost 50 guest articles published from such contributors as Amadeus, DataQuest, MobileMonkey, and CloudFactory.

4 Design Patterns You Should Know for Web Development: Observer, Singleton, Strategy, and Decorator

Have you ever been on a team where you need to start a project from scratch? That's usually the case in many start-ups and other small companies.

There are so many different programming languages, architectures, and other concerns that it can be difficult to figure out where to start. That's where design patterns come in.

A design pattern is like a template for your project. It uses certain conventions and you can expect a specific kind of behavior from it. These patterns were made up of many developers' experiences so they are really like different sets of best practices.

And you and your team get to decide which set of best practices is the most useful for your project. Based on the design pattern you choose, you all will start to have expectations for what the code should be doing and what vocabulary you all will be using.

Programming design patterns can be used across all programming languages and can be used to fit any project because they only give you a general outline of a solution.

There are 23 official patterns from the book Design Patterns - Elements of Reusable Object-Oriented Software , which is considered one of the most influential books on object-oriented theory and software development.

In this article, I'm going to cover four of those design patterns just to give you some insight to what a few of the patterns are and when you would use them.

The Singleton Design Pattern

The singleton pattern only allows a class or object to have a single instance and it uses a global variable to store that instance. You can use lazy loading to make sure that there is only one instance of the class because it will only create the class when you need it.

That prevents multiple instances from being active at the same time which could cause weird bugs. Most of the time this gets implemented in the constructor. The goal of the singleton pattern is typically to regulate the global state of an application.

An example of a singleton that you probably use all the time is your logger.

If you work with some of the front-end frameworks like React or Angular, you know all about how tricky it can be to handle logs coming from multiple components. This is a great example of singletons in action because you never want more than one instance of a logger object, especially if you're using some kind of error tracking tool.

Now you don't have to worry about losing logs from multiple instances because you only have one in your project. So when you want to log the food that has been ordered, you can use the same FoodLogger instance across multiple files or components.

With this singleton pattern in place, you don't have to worry about just getting the logs from the main application file. You can get them from anywhere in your code base and they will all go to the exact same instance of the logger, which means none of your logs should get lost due to new instances.

The Strategy Design Pattern

The strategy is pattern is like an advanced version of an if else statement.  It's basically where you make an interface for a method you have in your base class. This interface is then used to find the right implementation of that method that should be used in a derived class. The implementation, in this case, will be decided at runtime based on the client.

This pattern is incredibly useful in situations where you have required and optional methods for a class. Some instances of that class won't need the optional methods, and that causes a problem for inheritance solutions. You could use interfaces for the optional methods, but then you would have to write the implementation every time you used that class since there would be no default implementation.

That's where the strategy pattern saves us. Instead of the client looking for an implementation, it delegates to a strategy interface and the strategy finds the right implementation. One common use for this is with payment processing systems.

You could have a shopping cart that only lets customers check out with their credit cards, but you will lose customers that want to use other payment methods.

The strategy design pattern lets us decouple the payment methods from the checkout process which means we can add or update strategies without changing any code in the shopping cart or checkout process.

Here's an example of a strategy pattern implementation using the payment method example.

To implement our payment method strategy, we made a single class with multiple static methods. Each method takes the same parameter, customerInfo , and that parameter has a defined type of customerInfoType . (Hey all you TypeScript devs! ??) Take note that each method has its own implementation and uses different values from the customerInfo .

With the strategy pattern, you can also dynamically change the strategy being used at run time. That means you'll be able to change the strategy, or method implementation, being used based on user input or the environment the app is running in.

You can also set a default implementation in a simple config.json file like this:

Whenever a customer starts going through the checkout process on your website, the default payment method they encounter will be the PayPal implementation which comes from the config.json . This could easily be updated if the customer selects a different payment method.

Now we'll create a file for our checkout process.

This Checkout class is where the strategy pattern gets to show off. We import a couple of files so we have the payment method strategies available and the default strategy from the config .

Then we create the class with the constructor and a fallback value for the default strategy in case there hasn't been one set in the config . Next we assign the strategy value to a local state variable.

An important method we need to implement in our Checkout class is the ability to change the payment strategy. A customer might change the payment method they want to use and you'll need to be able to handle that. That's what the changeStrategy method is for.

After you've done some fancy coding and gotten all of the inputs from a customer, then you can update the payment strategy immediately based on their input and it dynamically sets the strategy before the payment is sent for processing.

At some point you might need to add more payment methods to your shopping cart and all you'll have to do is add it to the PaymentMethodStrategy class. It'll instantly be available anywhere that class is used.

The strategy design pattern is a powerful one when you are dealing with methods that have multiple implementations. It might feel like you're using an interface, but you don't have to write an implementation for the method every time you call it in a different class. It gives you more flexibility than interfaces.

The Observer Design Pattern

If you've ever used the MVC pattern, you've already used the observer design pattern. The Model part is like a subject and the View part is like an observer of that subject. Your subject holds all of the data and the state of that data. Then you have observers, like different components, that will get that data from the subject when the data has been updated.

The goal of the observer design pattern is to create this one-to-many relationship between the subject and all of the observers waiting for data so they can be updated. So anytime the state of the subject changes, all of the observers will be notified and updated instantly.

Some examples of when you would use this pattern include: sending user notifications, updating, filters, and handling subscribers.

Say you have a single page application that has three feature dropdown lists that are dependent on the selection of a category from a higher level dropdown. This is common on many shopping sites, like Home Depot. You have a bunch of filters on the page that are dependent on the value of a top-level filter.

The code for the top-level dropdown might look something like this:

This CategoryDropdown file is a simple class with a constructor that initializes the category options we have available for in the dropdown. This is the file you would handle retrieving a list from the back-end or any kind of sorting you want to do before the user sees the options.

The subscribe method is how each filter created with this class will receive updates about the state of the observer.

The onChange method is how we send out notification to all of the subscribers that a state change has happened in the observer they're watching. We just loop through all of the subscribers and call their update method with the selectedCategory .

The code for the other filters might look something like this:

This FilterDropdown file is another simple class that represents all of the potential dropdowns we might use on a page. When a new instance of this class is created, it needs to be passed a filterType. This could be used to make specific API calls to get the list of items.

The update method is an implementation of what you can do with the new category once it has been sent from the observer.

Now we'll take a look at what it means to use these files with the observer pattern:

What this file shows us is that we have 3 drop-downs that are subscribers to the category drop-down observable. Then we subscribe each of those drop-downs to the observer. Whenever the category of the observer is updated, it will send out the value to every subscriber which will update the individual drop-down lists instantly.

The Decorator Design Pattern

Using the decorator design pattern is fairly simple. You can have a base class with methods and properties that are present when you make a new object with the class. Now say you have some instances of the class that need methods or properties that didn't come from the base class.

You can add those extra methods and properties to the base class, but that could mess up your other instances. You could even make sub-classes to hold specific methods and properties you need that you can't put in your base class.

Either of those approaches will solve your problem, but they are clunky and inefficient. That's where the decorator pattern steps in. Instead of making your code base ugly just to add a few things to an object instance, you can tack on those specific things directly to the instance.

So if you need to add a new property that holds the price for an object, you can use the decorator pattern to add it directly to that particular object instance and it won't affect any other instances of that class object.

Have you ever ordered food online? Then you've probably encountered the decorator pattern. If you're getting a sandwich and you want to add special toppings, the website isn't adding those toppings to every instance of sandwich current users are trying to order.

Here's an example of a customer class:

And here's an example of a sandwich class:

This sandwich class is where the decorator pattern is used. We have a Sandwich base class that sets the rules for what happens when a regular sandwich is ordered. Customers might want to upgrade sandwiches and that just means an ingredient and price change.

You just wanted to add the functionality to increase the price and update the type of sandwich for the DeluxeSandwich without changing how it's ordered . Although you might need a different order method for an ExquisiteSandwich because there is a drastic change in the quality of ingredients.

The decorator pattern lets you dynamically change the base class without affecting it or any other classes. You don't have to worry about implementing functions you don't know, like with interfaces, and you don't have to include properties you won't use in every class.

Now if we'll go over an example where this class is instantiated as if a customer was placing a sandwich order.

Final Thoughts

I used to think that design patterns were these crazy, far-out software development guidelines. Then I found out I use them all the time!

A few of the patterns I covered are used in so many applications that it would blow your mind. They are just theory at the end of the day. It's up to us as developers to use that theory in ways that make our applications easy to implement and maintain.

Have you used any of the other design patterns for your projects? Most places usually pick a design pattern for their projects and stick with it so I'd like to hear from you all about what you use.

Thanks for reading. You should follow me on Twitter because I usually post useful/entertaining stuff: @FlippedCoding

International tech conference speaker | <New courses & books coming soon!> | Super Software Engineering Nerd | Still a mechanical engineer at heart | Lover of difficult tech problems

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

  • United States
  • United Kingdom

Joydip Kanjilal

By Joydip Kanjilal , Contributor, InfoWorld |

Exploring the MVC, MVP, and MVVM design patterns

Understand the intricacies of the presentation patterns available to build applications that are loosely coupled, easier to test and maintain.

mvc mvp mvvm

The user interface often contains a lot of cluttered code primarily because of the complicated logic it needs to handle. The presentation patterns are design primarily with one objective in mind, reducing the complex code in the presentation layer and making the code in the user interface clean and manageable. In this post, I will present a discussion on the MVC, MVP, and MVVM design patterns and highlight when one should be the design of choice over the other.

Model View Controller

The Model View Controller (commonly known as MVC) framework helps you to build applications that are easier to test and maintain. It comprises of three major components, namely:

  • Model -- this is the layer that represents the application's data
  • View -- this represents the presentation or the user interface layer
  • Controller -- this layer typically contains the business logic of your application

The primary objective of the MVC design pattern is separation of concerns to facilitate testability. The Model View Controller design pattern enables you to isolate the concerns and makes your application's code easier to test and maintain. In a typical MVC design, the request first arrives at the controller which binds the model with the corresponding view. In the MVC design pattern, the view and the controller makes use of strategy design and the view and the model are synchronized using the observer design. Hence, we may say that MVC is a compound pattern. The controller and the view are loosely coupled and one controller can be used by multiple views. The view subscribes to the changes in the model.

Model View Presenter

The MVP (Model View Presenter) design pattern also comprises of three components - the model, the view and the presenter. In the MVP design pattern, the Controller (in MVC) is replaced by the Presenter. Unlike the MVC design pattern, the Presenter refers back to the view due to which mocking of the view is easier and unit testing of applications that leverage the MVP design pattern over the MVC design pattern are much easier. In the MVP design pattern, the presenter manipulates the model and also updates the view. There are two variations of this design. These include the following.

  • Passive View -- in this strategy, the view is not aware of the model and the presenter updates the view to reflect the changes in the model.
  • Supervising Controller -- in this strategy, the view interacts with the model directly to bind data to the data controls without the intervention of the presenter. The presenter is responsible for updating the model. It manipulates the view only if needed -- if you need a complex user interface logic to be executed.

While both these variants promote testability of the presentation logic, the passive view variant is preferred over the other variant (supervising controller) as far as testability is concerned primarily because you have all the view updated logic inside the presenter.

The MVP design pattern is preferred over MVC when your application needs to provide support for multiple user interface technologies. It is also preferred if you have complex user interface with a lot of user interaction. If you would like to have automated unit test on the user interface of your application, the MVP design pattern is well suited and preferred over the traditional MVC design.

Model - View - ViewModel (MVVM)

The Model - View - ViewModel (MVVM) is a variation of Martin Fowler's Presentation Model design pattern. The MVVM is a refinement of the popular MVC design and the ViewModel in MVVM is used to facilitation Presentation Separation. In the MVVM the logic is stored in the presenter and the view is completely isolated from the model. While the presenter isn't aware of the view, the view is aware of the presenter -- the presenter in MVVM is used to represent an abstract view of the user interface. A passive view implies that the view doesn't have any knowledge of the model. In the MVVM design pattern, the View is active and contains behaviors, events and data binding information. Note that the view in MVVM is not responsible for managing the state information -- the view is rather synchronized with the viewmodel. The viewmodel in MVVM is responsible for presentation separation and exposes methods and commands to manage the state of a view and manipulate the model.

How does the view and the viewmodel in MVVM communicate? Well, the view and the viewmodel in MVVM communicates using methods, properties and events. The bi-directional databinding or the two way databinding between the view and the viewmodel ensures that the models and properties in the viewmodel is in sync with the view. The MVVM design pattern is well suited in applications that need support for bi-directional databinding.

Next read this:

  • Why companies are leaving the cloud
  • 5 easy ways to run an LLM locally
  • Coding with AI: Tips and best practices from developers
  • Meet Zig: The modern alternative to C
  • What is generative AI? Artificial intelligence that creates
  • The best open source software of 2023
  • Software Development

Joydip Kanjilal is a Microsoft MVP in ASP.NET, as well as a speaker and author of several books and articles. He has more than 20 years of experience in IT including more than 16 years in Microsoft .NET and related technologies.

Copyright © 2015 IDG Communications, Inc.

web presentation patterns

Patterns of Enterprise Application Architecture by Martin Fowler

Get full access to Patterns of Enterprise Application Architecture and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Chapter 4. Web Presentation

One of the biggest changes to enterprise applications in the last few years has been the rise of Web-browser-based user interfaces. They bring with them a lot of advantages: no client software to install, a common UI approach, and easy universal access. Also, many environments make it easy to build a Web app.

Preparing a Web app begins with the server software itself. Usually this has some form of configuration file that indicates which URLs are to be handled by which programs. Often a single Web server can handle many kinds of programs. These programs may be dynamic and can be added to a server by placing them in an appropriate directory. The Web server’s job is to interpret the URL of a request and hand over control ...

Get Patterns of Enterprise Application Architecture now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Cover of Software Architecture Patterns

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

web presentation patterns

  • System Design Tutorial
  • What is System Design
  • System Design Life Cycle
  • High Level Design HLD
  • Low Level Design LLD
  • Design Patterns
  • UML Diagrams
  • System Design Interview Guide
  • Crack System Design Round
  • System Design Bootcamp
  • System Design Interview Questions
  • Microservices
  • Scalability

Related Articles

  • Introduction to Decorator Pattern in C++ | Design Patterns
  • Repository Design Pattern
  • 10 Best Java Design Pattern Books
  • Factory Method in JavaScript | Design Pattern
  • Top 30 Java Design Patterns Interview Question
  • Design Patterns Gamma
  • Caching Design Pattern
  • Introduction to Gang Of Four(GoF) | Design Patterns
  • Architecture for Mobile Development | Design Patterns
  • Mediator Design Pattern in JavaScript | Design Pattern
  • User Interface (UI) Design Patterns
  • Complete Guide to Design Patterns
  • Template Method Design Pattern | C++ Design Patterns
  • Design Patterns for Relational Databases
  • Most asked Singleton Design Pattern Interview Questions
  • Java Dependency Injection (DI) Design Pattern
  • Design Patterns for Mobile Development
  • Top 20 Design Patterns Books of All Time from Beginner to Experts
  • Design Patterns in Angular

10 Best Design Patterns Books for Beginners to Advanced

In this article, we’ll explore ten of the best design pattern books that cater to everyone from beginners to advanced programmers, helping you master the art of writing clean and efficient code.

Important Books for Design Patterns

1. “design patterns”: elements of reusable object-oriented software.

  • 2. “Head First Design Patterns”: Building Extensible and Maintainable Object-Oriented Software by Elisabeth Freeman and Eric Freeman

3. “Peeling Design Patterns: For Beginners and Interviews” by Narasimha Karumanchi

4. “adaptive code: agile coding with design patterns and solid principles (best practices)” by gary mclean hall, 5. “patterns of enterprise application architecture” by martin fowler, a renowned engineering expert., 6. “selenium design patterns and best practices” by dima kovalenko, 7. “hands-on design patterns with c++”, 8. “adaptive code”: agile coding with design patterns and solid principles by gary mclean hall, 9. “machine learning design patterns”: solutions to common challenges in data preparation, model building, and mlops by valliappa lakshmanan, sara robinson & michael munn, 10. hands-on design patterns with delphi: build applications using idiomatic, extensible, and concurrent design patterns in delphi.

The GoF (Gang of Four) authored the book, which unveils 23 design patterns that were not previously documented. These patterns enable users to devise flexible and reusable designs, eliminating the need to constantly reinvent design solutions. Initially, you will gain an understanding of the concept of design patterns and their role in designing object-oriented software.

Author: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

2. “ Head First Design Patterns”: Building Extensible and Maintainable Object-Oriented Software by Elisabeth Freeman and Eric Freeman

The pace is nice and slow at first but can get tedious after some time with every chapter describing a fictional scenario and how someone might approach the problem with a simple solution.

Head First Design Patterns learned from their mistakes and shared their knowledge to help others avoid the same difficulties. you will learn some good ways to design things using methods that have been proven to work well. This will help you learn faster and remember the information better. As a result, you will be able to write code more efficiently.

Author: Elisabeth Freeman and Eric Freeman

This guide is for people who are new to designing software. It teaches you patterns and principles of software design in a simple and easy-to-understand way. The book has nine chapters and uses Java to show examples of how to design code. The explanations are clear and there are pictures to help you understand. The book also has real examples from the real world to help you apply what you learn. It is a good book for computer scientists and people who don’t know much about software design.

Author: Narasimha Karumanchi

The book talks about the best ways to design and write code that can change easily when needed. It explains how to test code and make improvements to it. It also teaches a technique to work with old code. This book is useful for all programmers and helps them create code that can be changed easily in an Agile development environment. Author: Gary McLean Hall

You will learn about solutions to common problems in business design. You will also learn how to make decisions when facing a difficult design.

The second part of this book is dedicated to design patterns such as:

  • Domain logic patterns
  • Data source architectural patterns
  • Object-relational behavioral patterns
  • Web presentation patterns
  • Distribution patterns

Author: Martin Fowler

This book helps you learn how to make a good Selenium test suite. It teaches you how to make your code better and plan for the future. It shows you lots of examples and explains things well. It also helps you with managing outside services. The book is all about making your test suite better and easier to take care of.

Author: Dima Kovalenko

This book is really good for programmers who want to make robust and useful apps. You will learn important patterns in C++ to create better applications. You will also learn how to solve common design challenges. You will understand the things that C++ cannot do and learn how to fix them using design techniques.

Author: Fedor G. Pikus

Adaptive code is for people who write computer programs. It has useful information for all kinds of programmers, no matter how much experience they have. It teaches helpful and practical things about:

  • Design patterns
  • SOLID principles
  • Unit testing
  • Refactoring

You’ll learn how to:

  • Develop code that can handle required changes
  • Plan for and improve adaptability
  • Perform unit testing and refactoring
  • Use techniques to make legacy code adaptive.
  • Avoid anti-related patterns.

Author: Gary McLean Hall

This book written by 3 Google engineers. This book explains 30 different ways to represent and solve problems with data. It tells you how to make your solutions repeatable, explainable, and fair. Each way includes a problem description, different possible solutions, and suggestions for picking the best one for your situation.

You’ll learn how to:

  • Identify and mitigate common challenges when training, evaluating, and deploying ML models.
  • Represent data for different ML model types, including embeddings, feature crosses, and more.
  • Choose the right model type for specific problems.
  • Build a robust training loop that uses checkpoints, distribution strategy, and hyperparameter tuning.
  • Deploy scalable ML systems that you can retrain and update to reflect new data.
  • Interpret model predictions for stakeholders and ensure models are treating users fairly.

Author: Valliappa Lakshmanan, Sara Robinson & Michael Munn

This book for beginner Delphi developers who want to build scalable, robust applications. Using real-world examples, you’ll explore various design patterns. Next, you will learn about software development mistakes, you’ll learn some of the most important patterns for various behavioral and structural types and also learn about concurrency patterns.

Author: Primož Gabrijelčič

Please Login to comment...

  • Geeks Premier League 2023
  • Design Pattern
  • Geeks Premier League
  • System Design
  • tarunsarawgi_gfg

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

Web Presentation Patterns

The following table lists the patterns included in the Web Presentation patterns cluster. The patterns are arranged so that later patterns build on earlier patterns. This implies a progression from more general patterns (such as Model-View- Controller ) to more specific patterns (such as Intercepting Filter ).

Enterprise Solution Patterns Using Microsoft. NET 2003

  • Welcome to DarkBASIC
  • Making Programs Think Branching Statements and Subroutines
  • The Art of Using Animated Sprites for 2D Games
  • Playing Some Tunes CD Audio, MIDI and MP3 Music
  • Fundamentals of 3D Graphics Programming
  • Call-Processing Deployment Models
  • SIP and Cisco CallManager
  • Blocking Commonly Exploited Area Codes
  • Bulk Trace Analysis
  • Master Test Planning
  • Detailed Test Planning
  • Analysis and Design
  • Improving the Testing Process
  • Appendix F Process Diagrams
  • A Need for Implementing Competency-Based HR Management
  • Competency-Based HR Planning
  • Competency-Based Performance Management
  • Competency-Based Employee Rewards
  • The Transformation to Competency-Based HR Management
  • Working with Fields
  • Remove an Element from an Array
  • Working with Dates and Times
  • Format a Users Name
  • Modifying Data Using a LotusScript Agent
  • Getting to Know AutoCAD
  • Basic Commands to Get Started
  • Gaining Drawing Strategies: Part 2
  • Using Layers to Organize Your Drawing
  • Grouping Objects into Blocks

DZone

  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
  • Manage My Drafts

Modernizing APIs : Share your thoughts on GraphQL, AI, microservices, automation , and more for our April report (+ enter a raffle for $250!).

DZone Research Report : A look at our developer audience, their tech stacks, and topics and tools they're exploring.

Getting Started With Large Language Models : A guide for both novices and seasoned practitioners to unlock the power of language models.

Managing API integrations : Assess your use case and needs — plus learn patterns for the design, build, and maintenance of your integrations.

  • Laravel for Beginners: An Overview of the PHP Framework
  • Is PHP Still the Best Language in 2024?
  • These 37 Items Are Required for Magento 2 Launch
  • PHP 8.2.12 Release that Every Developer Must Know About
  • Automate Application Load Balancers With AWS Load Balancer Controller and Ingress
  • The Impact of Technical Ignorance
  • Understanding Site Reliability Engineering
  • Automate JBoss Web Server 6 Deployment With the Red Hat Ansible Certified Content Collection for JWS

Practical PHP Patterns: Page Controller

Giorgio Sironi user avatar

Join the DZone community and get the full member experience.

Back in the time of when the web was starting out as a platform to consult remote documents (1990s), a path would have always corresponded to a static HTML document, which would be sent as-is to the client which requested it in the first place.

With the introduction of dynamic pages, a path did not translate to a single response anymore, but to an object capable of producing a response which can change everytime basing on parameters in the request, cookies or session variables. This dynamic generation of web pages is the basis of the Web as we know it today.

Implementation

Technically speaking, a Page Controller is an object (in the broader sense of the term, not ony an instance of a class but every kind of item) kept on the server, which is called upon a certain endpoint is the target of a HTTP request.

For example, plain old PHP scripts, which you call with Urls like /index.php , /list.php or /folder/member.php?id=42 are Page Controllers. But what is happening when you see Urls like /node/25645 ? Obviousy there is no 25645 file stored in the web server filesytem.

In more modern PHP frameworks, like Zend Framework or Symfony, the Page Controllers are not files but classes, a choice which simplifies the management of scope and the parameters passing to them (and also provides the unique possibility of defining multiple action methods). In this environment, Page Controllers are called Action Controllers or simply Actions, but don't be fooled by the name, since we have seen that even a simple PHP script is a Page Controller.

The reason for a different name can be tracked back to the transition from page-oriented websites to web full-featured web applications: a controller does not simply display a page anymore, but it performs some actions, at the end of which it can redirect the client or forward the execution to a colleague. The responses produced by controllers are not only HTML pages anymore, since they can be produced as HTML fragments, XML or JSON results.

Similarly, the plain old Page Controllers based on a PHP file have greater responsibilities than modern Action Controllers. Page Controller have to deal with the basic infrastructure of the programming language, like $_GET and $_POST, while Action Controllers are passed an higher-level abstraction like a Request Zend_Controller_Action_Request object.

The insulation layer between the client and Action Controllers will be the subject of another article. In general, this layer is not needed if the translation between URLs and Page Controllers can be performed natively by the web server.

Collaborators

The two collaborators of the Page Controllers have various implementation, which will be treated in detail in the upcoming articles of this series.

The Model part is the most application-specific part of the code, and contains as usual the business logic related to the domain. Ideally it should be testable in isolation, while the Page Controllers job is translating HTTP requests to method calls on the Model's objects and adding some indirection to check the client's authentication and authorization.

After having obtained the necessary data from the Model, the Controller uses a View component to generate the response. In PHP scripts, this separation is almost non-existent, as the script executes its logic and then starts printing. In Action Controllers, which are modelled as classes, they actually forward, automatically or not, to a View, which in turn may be modelled as a PHP script (Zend Framework's case) or as an object.

There are two simple examples we can made about Page Controllers. The first one is a plain old PHP scripts, a solution widely employed before the advent of web frameworks. The mapping of the request to the file is performed by the web server, which takes the standard output of the script, along with its produced HTTP headers, and sends it back to the client.

Very simple, and it's why PHP is so diffused and easy to use. But it does not scale.

A more sophisticated example is an Action Controller of Zend Framework. Here the framework, basing on configuration, figures out which controller is responsible for a request, and produces Zend_Controller_Action_Request and Zend_Controller_Action_Response objects as an abstraction over standard input and standard output. Part of this abstraction already existed in PHP ($_GET, $_POST) as an advantage over CGI scripts, part of it (matching Urls with predefined formats or regular expressions) is implemented in userland PHP by the framework itself.

For a full discussion of Zend Framework's implementation of this pattern, refer to the manual .

Opinions expressed by DZone contributors are their own.

Partner Resources

  • About DZone
  • Send feedback
  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone
  • Terms of Service
  • Privacy Policy
  • 3343 Perimeter Hill Drive
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

Got any suggestions?

We want to hear from you! Send us a message and help improve Slidesgo

Top searches

Trending searches

web presentation patterns

66 templates

web presentation patterns

9 templates

web presentation patterns

spring flowers

88 templates

web presentation patterns

st patricks day

12 templates

web presentation patterns

world war 1

45 templates

web presentation patterns

calendar 2024

35 templates

Celebrate Slidesgo’s big 5! Five years of great presentations, faster

Pattern Presentation templates

Give a dynamic presentation with the help of these slide designs with backgrounds full of patterns. browse these free and editable templates for google slides and powerpoint and focus on your message..

Agricultural Land Investment Pitch Deck Infographics presentation template

Agricultural Land Investment Pitch Deck Infographics

Download the Agricultural Land Investment Pitch Deck Infographics template for PowerPoint or Google Slides and discover the power of infographics. An infographic resource gives you the ability to showcase your content in a more visual way, which will make it easier for your audience to understand your topic. Slidesgo infographics...

Research Methods in Chinese Studies - Master of Arts in Chinese presentation template

Research Methods in Chinese Studies - Master of Arts in Chinese

Download the Research Methods in Chinese Studies - Master of Arts in Chinese presentation for PowerPoint or Google Slides. As university curricula increasingly incorporate digital tools and platforms, this template has been designed to integrate with presentation software, online learning management systems, or referencing software, enhancing the overall efficiency and...

Geometric Pattern presentation template

Geometric Pattern

Geometry is a beautiful and exact science. Have you ever thought about using geometric shapes in your presentation? We have designed a modern template that is perfect for several purposes, such as electronic music, concerts or gigs!

Floral Pattern presentation template

Premium template

Unlock this template and gain unlimited access

Floral Pattern

“A rose, is a rose, is a rose.” This simple yet powerful quotation by Gertrude Stein is perfect for these Spring days. Discover the beauty of roses, daffodils, dandelions and poppies with this floral template for your presentation!

Halloween Pattern Social Media presentation template

Halloween Pattern Social Media

A lot of people are looking forward to celebrating Halloween. Let’s seize the opportunity to present a strategy for social media by using this new template. As its name suggests, it features patterns inspired by this famous festivity, and it’s design is quite cool indeed. Did we say it has...

Colorful Polka Dots Portfolio presentation template

Colorful Polka Dots Portfolio

Download the Colorful Polka Dots Portfolio presentation for PowerPoint or Google Slides. When a potential client or employer flips through the pages of your portfolio, they're not just looking at your work; they're trying to get a sense of who you are as a person. That's why it's crucial to...

Tech Pattern presentation template

Tech Pattern

The future is now at Slidesgo! A slide deck with futuristic vibes is what we’re bringing to you today. The backgrounds contain lots of pixel patterns and simple but effective layouts. Even the typography is very suitable for tech-related topics. Go ahead and edit the resources!

Modern Wave presentation template

Modern Wave

Do you want to convey your message in a modern, simple and creative way? Then download and try our latest design, the Modern Wave presentation for Google Slides and PowerPoint!

Calms presentation template

You will love the elegance of this multipurpose template, which you can adapt to different business sectors and presentation goals. It is modern and has abstract shapes in pastel colors. Share the vision and mission of your company and use the graphs to show market trends and percentage growth. Tables...

Vintage Patterns Project Management Business Plan presentation template

Vintage Patterns Project Management Business Plan

Did you carry out a market analysis? Do you know what are the current trends and what is your competition? And do you have an operating plan ready too? That's great management, so now you just need this vintage-looking template in order to create a slideshow that details all of...

Smoking Health Effects presentation template

Smoking Health Effects

Download the Smoking Health Effects presentation for PowerPoint or Google Slides. Healthcare goes beyond curing patients and combating illnesses. Raising awareness about diseases, informing people about prevention methods, discussing some good practices, or even talking about a balanced diet—there are many topics related to medicine that you could be sharing...

Floral Pattern CV presentation template

Floral Pattern CV

Putting some flowers in your life makes you see things from another, more positive perspective. On the other hand, if you work as a florist, then things just got easier! This new template is perfect for CVs and it's already in A4, including the cover letter. The floral pattern that...

Start of Ramadan presentation template

Start of Ramadan

Download the Start of Ramadan presentation for PowerPoint or Google Slides and start impressing your audience with a creative and original design. Slidesgo templates like this one here offer the possibility to convey a concept, idea or topic in a clear, concise and visual way, by using different graphic resources....

Talavera Pottery Workshop presentation template

Talavera Pottery Workshop

Are you familiar with typical Talavera pottery? This is a type of ceramic finish and design typical of the Mexican states of Tlaxcala and Puebla. It is characterized for being a glazed ceramic with ivory white as the base of the decoration. It is very beautiful... so much so that...

Bhutan: Land of Happiness presentation template

Bhutan: Land of Happiness

Download the Bhutan: Land of Happiness presentation for PowerPoint or Google Slides and start impressing your audience with a creative and original design. Slidesgo templates like this one here offer the possibility to convey a concept, idea or topic in a clear, concise and visual way, by using different graphic...

Korean Pedagogy - Master of Arts in Korean presentation template

Korean Pedagogy - Master of Arts in Korean

Download the Korean Pedagogy - Master of Arts in Korean presentation for PowerPoint or Google Slides. As university curricula increasingly incorporate digital tools and platforms, this template has been designed to integrate with presentation software, online learning management systems, or referencing software, enhancing the overall efficiency and effectiveness of student...

Muted Color Palette Social Media presentation template

Muted Color Palette Social Media

If you work creating social media strategies, this template is perfect for you. It has a creative style, in a muted brown color and features geometric elements that give dynamism to the presentation. It is very versatile and you can adapt it to different types of companies. Define the buyer...

Fellowship Program presentation template

Fellowship Program

For those searching for an immersive learning experience, fellowship programs are a fantastic option. Unlike traditional classroom learning, these programs offer hands-on opportunities to engage with professionals in your field of interest. Who knows, you might even find your next mentor or collaborator during these fellowships! It all can begin...

  • Page 1 of 39

New! Make quick presentations with AI

Slidesgo AI presentation maker puts the power of design and creativity in your hands, so you can effortlessly craft stunning slideshows in minutes.

Five years of great presentations, faster

Celebrate Slidesgo’s big 5!

Back to Seekers of Perl Wisdom

www . com | www . net | www . org

  • GrandFather
  • Seekers of Perl Wisdom
  • Cool Uses for Perl
  • Meditations
  • PerlMonks Discussion
  • Categorized Q&A
  • Obfuscated Code
  • Perl Poetry
  • PerlMonks FAQ
  • Guide to the Monastery
  • What's New at PerlMonks
  • Voting/Experience System
  • Other Info Sources
  • Nodes You Wrote
  • Super Search
  • List Nodes By Users
  • Newest Nodes
  • Recently Active Threads
  • Selected Best Nodes
  • Worst Nodes
  • Saints in our Book
  • The St. Larry Wall Shrine
  • Offering Plate
  • Random Node
  • [id://781756|Buy PerlMonks Gear]
  • [Snippets Section|Snippets]
  • [Code Catacombs]
  • [Editor Requests]
  • blogs.perl.org
  • [http://planet.perl.org/|Planet Perl]
  • [http://ironman.enlightenedperl.org/|Perl Ironman Blog]
  • Perl Weekly
  • Perl Mongers
  • Perl Directory
  • Perl documentation
  • Today I Learned

Taking a day trip Baking Proposing Leaping Reading La_Bougie_du_Sapeur Making love, not war Enjoying life Relaxing (as there is no leap year bug in my code) Playing Frog Out Other

Results (22 votes) . Check out past polls .

IMAGES

  1. Pattern Free Presentation Template

    web presentation patterns

  2. Vector Templates for Website Design, Minimal Presentations, Portfolio

    web presentation patterns

  3. Web Presentation Patterns

    web presentation patterns

  4. 5 Really Useful Responsive Web Design Patterns

    web presentation patterns

  5. The Best Examples of Effective Web Design Presentation

    web presentation patterns

  6. Free Pattern Presentation Template on Behance

    web presentation patterns

VIDEO

  1. Master Web Messaging API #WebDevelopment

  2. Assignment front page design/ Project Work Designs/ Front page design #inspiration #shorts

  3. Sustainability

  4. Understanding "Web Pattern": A Guide for English Learners

  5. Presentation Patterns: Refactoring

  6. Using the MVVM Presentation Pattern

COMMENTS

  1. Catalog of Patterns of Enterprise Application Architecture

    Web Presentation Patterns: Model View Controller (330), Page Controller (333), Front Controller (344), Template View (350), Transform View (361), Two-Step View (365), Application Controller (379). Distribution Patterns: Remote Facade (388), Data Transfer Object (401)

  2. PDF Web Presentation Patterns (controller)

    Web Presentation Patterns (controller) SWEN-343 From Fowler, Patterns of Enterprise Application Architecture Objectives Look at common patterns for designing Web-based presentation layer behavior Model-View-Control Handling user input in HTTP request Delegating to domain layer for application processing Constructing HTML response stream

  3. Architecture Presentation Patterns in JS.

    In this article, we will explore some of the most commonly used architecture presentation patterns in JavaScript, including the Model-View-Controller (MVC) pattern, the Model-View-Presenter (MVP) pattern, and the Model-View-ViewModel (MVVM) pattern.

  4. 6 Popular Content Presentation Design Patterns

    6 Popular Content Presentation Design Patterns Published: Mar 1, 2011 Last Updated: Sep 26, 2023 12 min. read William Craig CEO & Co-Founder Content is what is considered the "meat" of a website. Content should be usable and displayed in a manner that makes it efficient to read and act on.

  5. Patterns.dev

    Patterns.dev is a free online resource on design, rendering, and performance patterns for building powerful web apps with vanilla JavaScript or modern frameworks. Download eBook or PDF Read online JavaScript Patterns Patterns focused on plain Javascript and Node.js Introduction Introduction to Design Patterns Singleton Pattern

  6. PDF Web Presentation Patterns (view)

    Web Presentation Patterns (view) SWEN-343 From Fowler, Patterns of Enterprise Application Architecture View Patterns Concerns How to construct a view (a web page) in response to application processing? How to generate the detailed HTML stream to send in response to the HTTP request? Patterns

  7. Chapter 10

    In Web applications, consider using AJAX to provide real-time validation. Pattern Map. Key patterns are organized by key categories, as detailed in the Presentation Layer Frame in the following table. Consider using these patterns when making design decisions for each category. Table 2 Pattern Map

  8. Modern Web Performance Patterns

    Common Presentation Patterns. The following are some of the most widely used presentation patterns. UI composition pattern: A single web page is composed of multiple independently developed UI components or fragments. Different teams can independently develop the UI components in parallel that loads the content asynchronously.

  9. Chapter 14. Web Presentation Patterns

    Chapter 14. Web Presentation Patterns Model View Controller Splits user interface interaction into three distinct roles. Model View Controller (MVC) is one of the most quoted (and most … - Selection from Patterns of Enterprise Application Architecture [Book]

  10. Web Presentation Patterns

    Web Presentation Patterns Another article of mine has made its appearance on Digital Web. In Web Presentation Patterns, I quickly touch on design patterns in general and then touch on MVC, page controller, and front controller has various implementations of design patterns. Best of all are probably the resources at the bottom.

  11. Cutting Edge: ASP.NET Presentation Patterns

    Inside an ASP.NET Event Handler The Original MVC Pattern Model2: A Web Variation of MVC ASP.NET MVC Framework vs. Manual MVC The MVP Pattern The Page Controller Pattern. In a layered Web app, the presentation layer is just as important as navigation logic, business logic, and data access. While you should try to keep the presentation layer ...

  12. Web Application Architecture: How the Web Works

    This architectural pattern is called Multi- or Three-Tier Architecture. Web application architecture following the three-tier pattern. Presentation layer The presentation layer is accessible to users via a browser and consists of user interface components and UI process components that support interaction with the system.

  13. 4 Design Patterns You Should Know for Web Development: Observer

    The Strategy Design Pattern. The strategy is pattern is like an advanced version of an if else statement. It's basically where you make an interface for a method you have in your base class. This interface is then used to find the right implementation of that method that should be used in a derived class.

  14. Exploring the MVC, MVP, and MVVM design patterns

    The presentation patterns are design primarily with one objective in mind, reducing the complex code in the presentation layer and making the code in the user interface clean and manageable. In ...

  15. Chapter 4. Web Presentation

    Web Presentation - Patterns of Enterprise Application Architecture [Book] Patterns of Enterprise Application Architecture by Martin Fowler Chapter 4. Web Presentation One of the biggest changes to enterprise applications in the last few years has been the rise of Web-browser-based user interfaces.

  16. 15 Top Web Application Design Patterns with Real Examples

    One of the key benefits of using design patterns in web application development is that they allow us to separate our business logic from our presentation logic. This means that we can focus on building robust, reusable components that can be used across our application. By doing this, we can reduce code duplication, improve code quality, and ...

  17. 10 Best Design Patterns Books for Beginners to Advanced

    2. "Head First Design Patterns": Building Extensible and Maintainable Object-Oriented Software by Elisabeth Freeman and Eric Freeman. 3. "Peeling Design Patterns: For Beginners and Interviews" by Narasimha Karumanchi. 4. "Adaptive Code: Agile coding with design patterns and SOLID principles (Best Practices)" by Gary McLean Hall. 5.

  18. Web Presentation Patterns

    The following table lists the patterns included in the Web Presentation patterns cluster. The patterns are arranged so that later patterns build on earlier patterns. This implies a progression from more general patterns (such as Model-View- Controller) to more specific patterns (such as Intercepting Filter ). Previous page Table of content

  19. 8 Time Tested Patterns For presentation organization

    1. Chronological pattern This model is best suitable for historical, timeline and process or procedure topics that can be split into different segments according to the time sequence. Structuring your presentation chronologically means your information will be arranged according to the order of time in which each event occurred.

  20. Enterprise Architecture

    About Press Copyright Contact us Creators Advertise Developers Terms Privacy Press Copyright Contact us Creators Advertise Developers Terms Privacy

  21. Practical PHP Patterns: Page Controller

    This is the first article from the Web Presentation Patterns part of this series. We are going to skip the part on web-based Model-View-Controller since we have talked about it enough both for PHP ...

  22. How to use Microsoft Copilot in your day-to-day work

    Create a new presentation from scratch. Create a presentation based on a file. Add a new slide to a presentation. Redesign slides to use a new theme or style. Let's give that first bullet point a try with this prompt: "Create a presentation about Q1 sales for AdventureWorks. Make it modern with a blue theme.

  23. Free Pattern Google Slides Themes and PowerPoint Templates

    Pattern Presentation templates Give a dynamic presentation with the help of these slide designs with backgrounds full of Patterns. Browse these free and editable templates for Google Slides and PowerPoint and focus on your message. Filters Ads Ads Ads Geometric Pattern Geometry is a beautiful and exact science.

  24. Web presentation patterns, MVC, and reinventing the wheel

    Re: Web presentation patterns, MVC, and reinventing the wheel by perrin (Chancellor) on Jan 30, 2003 at 21:11 UTC (I'm the author of the article you're referring to) The big secret about MVC is that it's pathetically easy, and much easier in Perl than in Java because of the great templating solutions available and the ease of passing data around.