presentation layer vs app

Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where application data is stored and managed.

The chief benefit of three-tier architecture is that because each tier runs on its own infrastructure, each tier can be developed simultaneously by a separate development team. And can be updated or scaled as needed without impacting the other tiers.

For decades three-tier architecture was the prevailing architecture for client-server applications. Today, most three-tier applications are targets for modernization that uses cloud-native technologies such as containers and microservices and for migration to the cloud.

Connect and integrate your systems to prepare your infrastructure for AI.

Register for the guide on app modernization

Presentation tier

The presentation tier is the user interface and communication layer of the application, where the end user interacts with the application. Its main purpose is to display information to and collect information from the user. This top-level tier can run on a web browser, as desktop application, or a graphical user interface (GUI), for example. Web presentation tiers are developed by using HTML, CSS, and JavaScript. Desktop applications can be written in various languages depending on the platform.

Application tier

The application tier, also known as the logic tier or middle tier, is the heart of the application. In this tier, information that is collected in the presentation tier is processed - sometimes against other information in the data tier - using business logic, a specific set of business rules. The application tier can also add, delete, or modify data in the data tier. 

The application tier is typically developed by using Python, Java, Perl, PHP or Ruby, and communicates with the data tier by using  API  calls. 

The data tier, sometimes called database tier, data access tier or back-end, is where the information that is processed by the application is stored and managed. This can be a  relational database management system  such as  PostgreSQL , MySQL, MariaDB, Oracle, Db2, Informix or Microsoft SQL Server, or in a  NoSQL  Database server such as Cassandra,  CouchDB , or  MongoDB . 

In a three-tier application, all communication goes through the application tier. The presentation tier and the data tier cannot communicate directly with one another.

Tier versus layer

In discussions of three-tier architecture,  layer  is often used interchangeably – and mistakenly – for  tier , as in 'presentation layer' or 'business logic layer'. 

They aren't the same. A 'layer' refers to a functional division of the software, but a 'tier' refers to a functional division of the software that runs on infrastructure separate from the other divisions. The Contacts app on your phone, for example, is a  three - layer  application, but a  single-tier  application, because all three layers run on your phone.

The difference is important because layers can't offer the same benefits as tiers.

Again, the chief benefit of three-tier architecture is its logical and physical separation of functionality. Each tier can run on a separate operating system and server platform - for example, web server, application server, database server - that best fits its functional requirements. And each tier runs on at least one dedicated server hardware or virtual server, so the services of each tier can be customized and optimized without impacting the other tiers. 

Other benefits (compared to single- or two-tier architecture) include:

• Faster development : Because each tier can be developed simultaneously by different teams, an organization can bring the application to market faster. And programmers can use the latest and best languages and tools for each tier.
• Improved scalability : Any tier can be scaled independently of the others as needed.
• Improved reliability : An outage in one tier is less likely to impact the availability or performance of the other tiers.
• Improved security : Because the presentation tier and data tier can't communicate directly, a well-designed application tier can function as an internal firewall, preventing SQL injections and other malicious exploits.

In web development, the tiers have different names but perform similar functions:

• The web server  is the presentation tier and provides the user interface. This is usually a web page or website, such as an ecommerce site where the user adds products to the shopping cart, adds payment details or creates an account. The content can be static or dynamic, and is developed using HTML, CSS, and JavaScript.
• The application server  corresponds to the middle tier, housing the business logic that is used to process user inputs. To continue the ecommerce example, this is the tier that queries the inventory database to return product availability, or adds details to a customer's profile. This layer often developed using Python, Ruby, or PHP and runs a framework such as Django, Rails, Symphony, or ASP.NET.
• The database server  is the data or backend tier of a web application. It runs on database management software, such as MySQL, Oracle, DB2, or PostgreSQL.

While three-tier architecture is easily the most widely adopted multitier application architecture, there are others that you might encounter in your work or your research.

Two-tier architecture 

Two-tier architecture is the original client-server architecture, consisting of a presentation tier and a data tier; the business logic lives in the presentation tier, the data tier or both. In two-tier architecture the presentation tier - and therefore the end user - has direct access to the data tier, and the business logic is often limited. A simple contact management application, where users can enter and retrieve contact data, is an example of a two-tier application. 

N-tier architecture

N-tier architecture - also called or multitier architecture - refers to  any  application architecture with more than one tier. But applications with more than three layers are rare because extra layers offer few benefits and can make the application slower, harder to manage and more expensive to run. As a result, n-tier architecture and multitier architecture are usually synonyms for three-tier architecture.

Move to cloud faster with IBM Cloud Pak solutions running on Red Hat OpenShift software—integrated, open, containerized solutions certified by IBM®.

Seamlessly modernize your VMware workloads and applications with IBM Cloud.

Modernize, build new apps, reduce costs, and maximize ROI.

IBM Consulting® application modernization services, which are powered by IBM Consulting Cloud Accelerator, offers skills, methods, tools, and initiatives that help determine the right strategy based on your portfolio. To modernize and containerize legacy system applications and accelerate the time-to-value of hybrid cloud environments. 

Discover what application modernization is, the common benefits and challenges, and how to get started.

Learn about how relational databases work and how they compare to other data storage options.

Explore cloud native applications and how they drive innovation and speed within your enterprise.

Modernize your legacy three-tier applications on your journey to cloud. Whether you need assistance with strategy, processes, or capabilities—or want full-service attention—IBM can help. Start using containerized middleware that can run in any cloud—all bundled in IBM Cloud Paks.

A Guide To 3-Tier Architecture

A well-structured and organized solution is crucial for maintainability and scalability in software development. The 3-Tier architecture clarifies concerns, allowing developers to manage the application logic, data access, and presentation layers separately. In this article, we will explore the benefits of this architecture and learn how to implement it in a Visual Studio solution using C#. 

Different Architectures

There are many types of architectures you can use for your applications. You just have to find the one that suits your needs. I like the 3-tier architecture. It’s small, simple, and easy to create. But in some cases, I might change it because of my needs.

There are 9 known architectures we use these days in C#:

• Monolithic architecture
• Microservices architecture
• 3-tier architecture
• Model-View-Controller (MVC) architecture
• Model-View-Presenter (MVP) architecture
• Model-View-ViewModel (MVVM) architecture
• Event-Driven architecture
• Service-Oriented Architecture (SOA)
• Client-Server architecture

I am not going to explain them all. It will become a very large page. But the top 3 popular architectures are:

• Microservices architecture A way to break down a large and complex application into smaller, independent services that are connected. They communicate with each other through APIs. This architecture is becoming popular with bigger projects. You can maintain and deploy the smaller projects more easily.
• 3-tier architecture This type of architecture separates an application into three logical components: the presentation layer, the application layer, and the data layer. This separation of concerns provides better scalability, maintainability, and ease of development.
• Model-View-Controller (MVC) architecture  Well-known if you have created web applications and/or  APIs  with C#. It is a design that separates the application logic from the user interface. The Model component represents the data and the business logic, the View component displays the data, and the Controller component handles user input and updates the Model. This separation of concerns provides a more organized and maintainable codebase.

This tutorial explains the 3-tier architecture a bit further. Mainly because we use this one the most.

The 3-Tier Architecture

This architecture separates the application into three logical components. These three layers help to maintain the code and separation of concern. But for me, it has a different reason I use this architecture: reusability. 

Especially at a time when you might want to create a Windows, macOS, Android, Linux, and iOS app that does the same thing. Do you create the same class over and over again? No, you create a class library with the logic and reference that library in all the projects that need the logic. If something changes in the class library, all other projects get updated.

Three Different Layers

Each layer has its own responsibility but only talks to one other layer. The presentation layer only talks to the application layer and the application layer only talks to the data layer. That means that if you want to show a list of movies, for example, you need to ask the application layer which will ask the data layer. The application layer will send the information of the data layer to the presentation layer. The presentation layer never talks to the data layer directly.

The Data Layer

The first layer I am discussing is the data layer. Maybe the name already tells you what this layer is about: Data. It could be data from a database or a file. Generally speaking, we use this layer to transport data from and to a data source.

This layer does not contain any form of logic. It just sends or retrieves data from the data source. Nothing special. Logic is placed in the application layer.

If you have multiple data sources you need to manage, you can create multiple data layers and bring them together in the application by using dependency injection.

The data layer is a layer that is disappearing a bit. Before we had ORMs, like  Entity Framework , we had to write a lot of code to retrieve and send data from and to a database. With Entity Framework, we don’t need that anymore. That is the reason the logic for the database is moving to the application layer.

The Application Layer

This layer is the beating heart for all your logic. Here you combine logic with the data from the data layer. This layer is responsible for calculations and decisions before sending the data to your presentation layer.

The application layer is often called the business layer. This is a small heritage from the time we had the DLL (data layer library) and the BLL (business layer library). In my projects, I usually call it the business.

For example, the presentation layer requests a list of movies, ordered by title. The application layer will retrieve all the movies from the data layer and sort them by title.

This layer does nothing with the data source directly. The reason is simple: The application layer should never know what kind of data source you use. If you implement dependency injection, the data source can change. Even the whole data layer can change (except for the interface). But the application layer should always be working without changing it.

You can have multiple application layers. I created a logger once. A simple logger that stores messages in a file. But later I needed a logger that stored the messages in a database. I didn’t want two loggers in the single class library representing my application layer. So I created a second application layer for the logger.

It’s usually this layer we  unit test  because it contains the most important code of our application.

The Presentation Layer

And last but not least; the presentation layer. This layer is what a user sees. It could be a console application, WinForms, or an API. It’s the one that gives output that a user or a client application can work with. This layer is also referred to as the top-most layer in this architecture.

It is responsible for presenting the data from the application layer in a user-friendly way. Examples of user-friendly are web pages, WinForms, and mobile apps.

A console application or a WinForms application has a clear GUI. You can click on stuff and it works. An API doesn’t have that. But it does expose JSON (or XML if you want). An API is considered a front-end application.

Conclusion On A Guide to 3-Tier Architecture

The 3-tier architecture is the most used because it’s easy to understand and implement. I encourage you to use this if you just start or create a small project. If you have a really, really small project; make your life easier, and don’t use layers.

The idea behind these layers is to separate data, logic, and application. I think the names are a bit confusing and most people think the application layer is the front end, but that’s the presentation layer. And that is why I call the application layer the business layer.

Kens Learning Curve

Chatgpt: yay or nay, 10 reasons why you should unit test, you may also like, visual studio shortcuts, design patterns and design principles, to savechanges or not to savechanges, learn c# essentials and frameworks for new developers, top 5 reasons to use c#, how to apply clean code with c#, the c# data types part 2 – int, the c# data types part 1 – string, the use of code comments, leave a comment cancel reply.

Save my name, email, and website in this browser for the next time I comment.

Kens Learning Curve is all about learning C# and all that comes along with it. From short, practical tutorials to learning from A to Z.

All subjects are tried and used by myself and I don’t use ChatGPT to write the texts.

Useful links

Free Tutorials

• C# Bootcamp

Use the contact form to contact me or send me an e-mail.

The contact form can be found here .

Email: [email protected]

@2023 – All Right Reserved. Designed and Developed by Kens Learning Curve

• All tutorials
• About Kens Learning Curve
• Career Advise
• Technical Writer

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.

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

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

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 application architecture components and Three-Tier 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.

Single Page Application architecture

Multi-Page Applications

MPA architecture

Example #2. Enterprise applications

Enterprise application architecture

To conclude

A Primer on Layers: Understanding Layer-Based Architectures

Fernando Doglio

Bits and Pieces

When we’re just getting started, we can only think about the code, and that if we write it and it works, then we’re good to go.

However, that is not entirely true, when writing code there are many other aspects to consider other than it running. In particular, things like complexity, ease of maintenance, testability, performance, overall syntax and adherence to the coding standards, and many others.

And all those points affect the way you write and structure your code. With that in mind, it would make a lot more sense to consider them before you start putting your hands on the keyboard, that way you only write your code once.

Out of all those factors, in this article, I want to cover what layer-based architectures are, and how they can affect your project’s structure.

What are layers?

The concept of a layer is used in Software Development to separate different concerns or levels of abstraction. You start by thinking at a really high level about the type of tasks your application is going to be performing, and then you create “groups” or “layers” for them.

For instance, consider your classical To-Do app created using HTML, CSS and JavaScript. What type of actions will your app do?

Remember, this is high-level, so we can say:

• It’ll let the user interact with the To-Do items through a UI.
• It’ll save those items to some type of storage so it can retrieve them in the future.
• It’ll validate that we don’t create repeated items and it’ll let us manage their state.

So we have 3 groups or layers:

• UI layer, where the presentation takes place
• A storage layer where the persistence of the data takes place
• And a business logic layer, where we include all the validations and state management code.

As you can see layers are nothing more than a logical group that allows you to organize your logic. At least at this stage, let’s keep going.

How do layers affect your project?

The effect layers can have highly depend on the type of project you are building.

If you’re working on a monorepo-type project, or even something as simple as a monolithic app, the layers will most likely become different folders within the same project.

You could have something like this:

Granted, this is just an example of a fake Node.js project, however, you can see how we’re using the layers to organize our code. Could you possibly have all these files and concepts inside a single “src” folder? Absolutely, but the question here isn’t if you can, it’s if you should.

This (or any similar) separation allows you to work on each layer’s code without significantly affecting the other layers. This is the main benefit of this approach.

On the other hand, if instead you have a project split into multiple microservices, you might not need to have the exact same folder structure. Instead, if each layer is small enough you could turn each one into a single project. Or if they are complex, try to split each microservice internally like you would a monolith.

The point is that through the logical separation of responsibilities and concerns you add layers of abstraction that provide you with the tools to better maintain and extend the code.

Classic uses of layers in software architecture

This separation of concerns and its subsequent effect on the internal (or external) structure of your applications is also known as “Architecture”.

The architecture determines how easy or hard it is to scale, maintain and even deploy your application. And just like with anything in the real world, there is no single answer to all problems, so there is no real single architecture that will solve all your problems.

Even better, there are patterns you can use and reuse after some tweaks that will help you structure your projects in the best way possible.

Classic web application architecture: the MVC pattern

The MVC (or Model, View, Controller) pattern is a classic layer-based architecture that allows you to separate the individual data-related logic (i.e how you interact with the data) from the actual presentation (the view) and the way you communicate both (in other words, the controller).

With an MVC pattern, you usually end up having something like React, Vue or heck, even plain old JavaScript for your View layer, and then an API in the back-end. Each endpoint of this API uses a controller, which centralizes the way you use the models and each model is the way you interact with the storage layer through a higher abstraction level interface.

Put another way:

Each layer can only communicate with the adjacent one, so the view can only communicate with the controller but never directly with the model, and the model can only talk to the controller. The only one that can “talk” both ways is the controller, due to its particular placement.

This is a great basic pattern to tackle any web application because there is a very natural mapping between your app components and the layers.

There are other patterns that you can extrapolate from this one, I’ll leave that to you, the point here is to understand that each layer will give you a different type of abstraction.

Some layer-based patterns are meant for the entire application (like this one), because they deal with the front-end and the back-end as well. But in the cases where the front-end is complex enough, it might also require its own architecture. So you might find yourself using an MVC overall, but an MVVM for the UI for example.

If you liked what you read so far, consider subscribing to my FREE newsletter “ The rambling of an old developer ” and get regular advice about the IT industry directly in your inbox.

Creating your own pattern

This article is not about memorizing different layer-based patterns, but instead, it’s about trying to understand how they all work and how you can use them to solve your problems.

Once you understand that layers are just abstraction levels that you add between groups that handle different concerns, you can start creating your own patterns and your own architectures.

For example, imagine you’re creating an API from scratch using something like Node.js and you structure your routes handlers (the functions that will be called a request hits the server) like this:

Granted, the above code doesn’t follow any particular framework, and I’m assuming a given external dependency for the Database connection (in the form of the db object. That said, the code there would work, it’s perfectly valid and it will return the list of active users when you hit the /users URL.

However, we can see several improvement areas:

• The direct access to the data through the SQL query and directly using the db object is coupling the hander with our storage medium. If next month, for any reason we need to move this to a MongoDB, all our controllers would have to change, and potentially the way they deal with the data as well.
• There is no data model for our API, the schema of the response is defined directly in the handler function (as evidenced in the map method). Imagine having 8 to 10 more handlers that deal with users, if in 6 months you have to change the name of one of the fields returned here, you’d have to update all 10 methods. That’s not efficient.
• And finally, the response is given by the JSON representation of our array users by our use of the json method. If in the future we need to add extra attributes to our response, such as the time the query took to run, or debug information, we’re going to have to modify this logic.

Every time you write a piece of code that should be considered “production-ready”, you have to think about scalability and resilience to change in the business logic. Of course, changes there will always mean code changes, but it’s a matter of minimizing the number of changes to apply and the places where you have to apply them.

Taking this into account and the improvement points from above, we can say that we could use a storage layer to abstract away the interaction with the data, and a representation layer to centralize the way our data is returned to the client.

Once these concepts are applied, we could end up with a handler like this:

Line 4 abstracts away all the data modeling and data access code, and line 5 abstracts away the representation of our data. That way if changes in the future require us to modify the way we deal with data, we go to the model definition, if we need to change our response, we go to the response handler. And none of our handler functions is affected.

As an added bonus, if you’re part of a big team, maybe you who only work on handlers, don’t even know about the changes required for the models. This is the type of abstractions you should always aim for and the main benefit of layers.

Layers are a powerful tool that should be used at the start of a project, they help dictate the way you structure your code, the way your data flows through your business logic, and how future-proof your app actually is.

Do not let the term scare you or make you think you don’t need it, layers are simple and powerful, there is no real need to not use them.

Are you going to try layers for your next project or do you still have questions about them? Leave your doubts in the comments and let’s connect!

Build composable web applications

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and greatly speed up, scale, and standardize development as a team. Start with composable frontends like a Design System or Micro Frontends, or explore the composable backend. Give it a try →

How We Build Micro Frontends

Building micro-frontends to speed up and scale our web development process..

blog.bitsrc.io

How we Build a Component Design System

Building a design system with components to standardize and scale our ui development process., the composable enterprise: a guide, to deliver in 2022, the modern enterprise must become composable., 7 tools for faster frontend development in 2022, tools you should know to build modern frontend applications faster, and have more fun..

Written by Fernando Doglio

I write about technology, freelancing and more. Check out my FREE newsletter if you’re into Software Development: https://fernandodoglio.substack.com/

More from Fernando Doglio and Bits and Pieces

Understanding Peer Dependencies in JavaScript

Peer dependencies are a must-know feature that many developers overlook.

Ruvani Jayaweera

Implementing the API Gateway Pattern in a Microservices Based Application with Node.js

Build your own api gateway using node.js in under 5 minutes.

Chameera Dulanga

Best-Practices for API Authorization

4 best practices for api authorization.

It’s 2024, you should be using React Server Components already

3 reasons why you should actually use rsc in all your projects, recommended from medium.

Deivison Isidoro

Building Robust Clean Architecture with TypeScript: A Detailed Look at the Project Structure

Introduction.

General Coding Knowledge

Stories to Help You Grow as a Software Developer

Coding & Development

Prathap Chandra

Typescript Cheatsheet 2023

Typescript is a statically typed superset of javascript that helps developers write more robust and maintainable code. one of typescript’s….

Ali Zeynalli

Master Plan to become a Solution Architect

Software architects are senior level actors in software development team. it takes time and experience to become the one. the skills and….

Somnath Singh

Level Up Coding

The Era of High-Paying Tech Jobs is Over

The death of tech jobs..

Obinna “Anderson” Asiegbulam

Cutting Through Complexity: The Vertical Slice Architecture in Action

In the world of software development, building applications that are maintainable, flexible, and user-focused is a constant challenge. one….

Text to speech

Flutter App Architecture: The Presentation Layer

Andrea Bizzotto

Updated   Sep 21, 2023 11 min read

When writing Flutter apps, separating any business logic from the UI code is very important.

This makes our code more testable and easier to reason about , and is especially important as our apps become more complex.

To accomplish this, we can use design patterns to introduce a separation of concerns between different components in our app.

And for reference, we can adopt a layered app architecture such as the one represented in this diagram:

I have already covered some of the layers above in other articles:

• Flutter App Architecture with Riverpod: An Introduction
• Flutter App Architecture: The Repository Pattern
• Flutter App Architecture: The Domain Model
• Flutter App Architecture: The Application Layer

And this time, we will focus on the presentation layer and learn how we can use controllers to:

• hold business logic
• manage the widget state
• interact with repositories in the data layer

This kind of controller is the same as the view model that you would use in the MVVM pattern . If you've worked with flutter_bloc before, it has the same role as a cubit .

We will learn about the AsyncNotifier class, which is a replacement for the StateNotifier and the ValueNotifier / ChangeNotifier classes in the Flutter SDK.

And to make this more useful, we will implement a simple authentication flow as an example.

Ready? Let's go!

A simple authentication flow

Let's consider a very simple app that we can use to sign in anonymously and toggle between two screens:

And in this article, we'll focus on how to implement:

• an auth repository that we can use to sign in and sign out
• a sign-in widget screen that we show to the user
• the corresponding controller class that mediates between the two

Here's a simplified version of the reference architecture for this specific example:

You can find the complete source code for this app on GitHub . For more info about how it is organized, read this: Flutter Project Structure: Feature-first or Layer-first?

The AuthRepository class

As a starting point, we can define a simple abstract class that contains three methods that we'll use to sign in, sign out, and check the authentication state:

In practice, we also need a concrete class that implements AuthRepository . This could be based on Firebase or any other backend. We can even implement it with a fake repository for now. For more details, see this article about the repository pattern .

For completeness, we can also define a simple AppUser model class:

And if we use Riverpod, we also need a Provider that we can use to access our repository:

Next up, let's focus on the sign-in screen.

The SignInScreen widget

Suppose we have a simple SignInScreen widget defined like so:

This is just a simple Scaffold with an ElevatedButton in the middle.

Note that since this class extends ConsumerWidget , in the build() method we have an extra ref object that we can use to access providers as needed.

Accessing the AuthRepository directly from our widget

As a next step, we can use the onPressed callback to sign in like so:

This code works by obtaining the AuthRepository with a call to ref.read(authRepositoryProvider) . and calling the signInAnonymously() method on it.

This covers the happy path (sign-in successful). But we should also account for loading and error states by:

• disabling the sign-in button and showing a loading indicator while sign-in is in progress
• showing a SnackBar or alert if the call fails for any reason

The "StatefulWidget + setState" way

One simple way of addressing this is to:

• convert our widget into a StatefulWidget (or rather, ConsumerStatefulWidget since we're using Riverpod)
• add some local variables to keep track of state changes
• set those variables inside calls to setState() to trigger a widget rebuild
• use them to update the UI

Here's how the resulting code may look like:

For a simple app like this, this is probably ok.

But this approach gets quickly out of hand when we have more complex widgets, as we are mixing business logic and UI code in the same widget class.

And if we want to handle loading in error states consistently across multiple widgets, copy-pasting and tweaking the code above is quite error-prone (and not much fun).

Instead, it would be best to move all these concerns into a separate controller class that can:

• mediate between our SignInScreen and the AuthRepository
• provide a way for the widget to observe state changes and rebuild itself as a result

So let's see how to implement it in practice.

A controller class based on AsyncNotifier

The first step is to create a AsyncNotifier subclass which looks like this:

Or even better, we can use the new @riverpod syntax and let Riverpod Generator do the heavy lifting for us:

Either way, we need to implement a build method, which returns the initial value that should be used when the controller is first loaded.

If desired, we can use the build method to do some asynchronous initialization (such as loading some data from the network). But if the controller is "ready to go" as soon as it is created (just like in this case), we can leave the body empty and set the return type to Future<void> .

Implementing the method to sign in

Next up, let's add a method that we can use to sign in:

A few notes:

• We obtain the authRepository by calling ref.read on the corresponding provider ( ref is a property of the base AsyncNotifier class)
• Inside signInAnonymously() , we set the state to AsyncLoading so that the widget can show a loading UI
• Then, we call AsyncValue.guard and await for the result (which will be either AsyncData or AsyncError )

AsyncValue.guard is a handy alternative to try / catch . For more info, read this: Use AsyncValue.guard rather than try/catch inside your StateNotifier subclasses

And as an extra tip, we can use a method tear-off to simplify our code even further:

This completes the implementation of our controller class, in just a few lines of code:

Note about the relationship between types

Note that there is a clear relationship between the return type of the build method and the type of the state property:

In fact, using AsyncValue<void> as the state allows us to represent three possible values:

• default (not loading) as AsyncData (same as AsyncValue.data )
• loading as AsyncLoading (same as AsyncValue.loading )
• error as AsyncError (same as AsyncValue.error )

If you're not familiar with AsyncValue and its subclasses, read this: How to handle loading and error states with StateNotifier & AsyncValue in Flutter

Time to get back to our widget class and wire everything up!

Using our controller in the widget class

Here's an updated version of the SignInScreen that uses our new SignInScreenController class:

Note how in the build() method we watch our provider and rebuild the widget when the state changes.

And in the onPressed callback we read the provider's notifier and call signInAnonymously() . And we can also use the isLoading property to conditionally disable the button while sign-in is in progress.

We're almost done, and there's only one thing left to do.

Listening to state changes

Right at the top of the build method, we can add this:

We can use this code to call a listener callback whenever the state changes.

This is useful for showing an error alert or a SnackBar if an error occurs when signing in.

Bonus: An AsyncValue extension method

The listener code above is quite useful and we may want to reuse it in multiple widgets.

To do that, we can define this AsyncValue extension :

And then, in our widget, we can just import our extension and call this:

By implementing a custom controller class based on AsyncNotifier , we've separated our business logic from the UI code .

As a result, our widget class is now completely stateless and is only concerned with:

• watching state changes and rebuilding as a result (with ref.watch )
• responding to user input by calling methods in the controller (with ref.read )
• listening to state changes and showing errors if something goes wrong (with ref.listen )

Meanwhile, the job of our controller is to:

• talk to the repository on behalf of the widget
• emit state changes as needed

And since the controller doesn't depend on any UI code, it can be easily unit tested , and this makes it an ideal place to store any widget-specific business logic.

In summary, widgets and controllers belong to the presentation layer in our app architecture:

But there are three additional layers: data , domain , and application , and you can learn about them here:

Or if you want to dive deeper, check out my Flutter Foundations course. 👇

Flutter Foundations Course Now Available

I launched a brand new course that covers Flutter app architecture in great depth, along with other important topics like state management, navigation & routing, testing, and much more:

Flutter Foundations Course

Learn about State Management, App Architecture, Navigation, Testing, and much more by building a Flutter eCommerce app on iOS, Android, and web.

Invest in yourself with my high-quality Flutter courses.

Flutter & Firebase Masterclass

Learn about Firebase Auth, Cloud Firestore, Cloud Functions, Stripe payments, and much more by building a full-stack eCommerce app with Flutter & Firebase.

The Complete Dart Developer Guide

Learn Dart Programming in depth. Includes: basic to advanced topics, exercises, and projects. Fully updated to Dart 2.15.

Flutter Animations Masterclass

Master Flutter animations and build a completely custom habit tracking application.

• Engineering Mathematics
• Discrete Mathematics
• Operating System
• Computer Networks
• Digital Logic and Design
• C Programming
• Data Structures
• Theory of Computation
• Compiler Design
• Computer Org and Architecture
• Computer Network Tutorial

Basics of Computer Network

• Basics of Computer Networking
• Introduction to basic Networking Terminology
• Goals of Networks
• Basic characteristics of Computer Networks
• Challenges of Computer Network
• Physical Components of Computer Network

Network Hardware and Software

• Types of Computer Networks
• LAN Full Form
• How to Set Up a LAN Network?
• MAN Full Form in Computer Networking
• MAN Full Form
• WAN Full Form
• Introduction of Internetworking
• Difference between Internet, Intranet and Extranet
• Protocol Hierarchies in Computer Network
• Network Devices (Hub, Repeater, Bridge, Switch, Router, Gateways and Brouter)
• Introduction of a Router
• Introduction of Gateways
• What is a network switch, and how does it work?

Network Topology

• Types of Network Topology
• Difference between Physical and Logical Topology
• What is OSI Model? - Layers of OSI Model
• Physical Layer in OSI Model
• Data Link Layer
• Session Layer in OSI model

Presentation Layer in OSI model

• Application Layer in OSI Model
• Protocol and Standard in Computer Networks
• Examples of Data Link Layer Protocols
• TCP/IP Model
• TCP/IP Ports and Its Applications
• What is Transmission Control Protocol (TCP)?
• TCP 3-Way Handshake Process
• Services and Segment structure in TCP
• TCP Connection Establishment
• TCP Connection Termination
• Fast Recovery Technique For Loss Recovery in TCP
• Difference Between OSI Model and TCP/IP Model

Medium Access Control

• MAC Full Form
• Channel Allocation Problem in Computer Network
• Multiple Access Protocols in Computer Network
• Carrier Sense Multiple Access (CSMA)
• Collision Detection in CSMA/CD
• Controlled Access Protocols in Computer Network

SLIDING WINDOW PROTOCOLS

• Stop and Wait ARQ
• Sliding Window Protocol | Set 3 (Selective Repeat)
• Piggybacking in Computer Networks

IP Addressing

• What is IPv4?
• What is IPv6?
• Introduction of Classful IP Addressing
• Classless Addressing in IP Addressing
• Classful Vs Classless Addressing
• Classless Inter Domain Routing (CIDR)
• Supernetting in Network Layer
• Introduction To Subnetting
• Difference between Subnetting and Supernetting
• Types of Routing
• Difference between Static and Dynamic Routing
• Unicast Routing - Link State Routing
• Distance Vector Routing (DVR) Protocol
• Fixed and Flooding Routing algorithms
• Introduction of Firewall in Computer Network

Congestion Control Algorithms

• Congestion Control in Computer Networks
• Congestion Control techniques in Computer Networks
• Computer Network | Leaky bucket algorithm
• TCP Congestion Control

Network Switching

• Circuit Switching in Computer Network
• Message switching techniques
• Packet Switching and Delays in Computer Network
• Differences Between Virtual Circuits and Datagram Networks

Application Layer:DNS

• Domain Name System (DNS) in Application Layer
• Details on DNS
• Introduction to Electronic Mail
• E-Mail Format
• World Wide Web (WWW)
• HTTP Full Form
• Streaming Stored Video
• What is a Content Distribution Network and how does it work?

CN Interview Quetions

• Top 50 Networking Interview Questions (2024)
• Top 50 TCP/IP interview questions and answers
• Top 50 IP addressing interview questions and answers
• Last Minute Notes - Computer Networks
• Computer Network - Cheat Sheet
• Network Layer
• Transport Layer
• Application Layer

Prerequisite : OSI Model

Introduction : Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model. This layer is also known as Translation layer, as this layer serves as a data translator for the network. The data which this layer receives from the Application Layer is extracted and manipulated here as per the required format to transmit over the network. The main responsibility of this layer is to provide or define the data format and encryption. The presentation layer is also called as Syntax layer since it is responsible for maintaining the proper syntax of the data which it either receives or transmits to other layer(s).

Functions of Presentation Layer :

The presentation layer, being the 6th layer in the OSI model, performs several types of functions, which are described below-

• Presentation layer format and encrypts data to be sent across the network.
• This layer takes care that the data is sent in such a way that the receiver will understand the information (data) and will be able to use the data efficiently and effectively.
• This layer manages the abstract data structures and allows high-level data structures (example- banking records), which are to be defined or exchanged.
• This layer carries out the encryption at the transmitter and decryption at the receiver.
• This layer carries out data compression to reduce the bandwidth of the data to be transmitted (the primary goal of data compression is to reduce the number of bits which is to be transmitted).
• This layer is responsible for interoperability (ability of computers to exchange and make use of information) between encoding methods as different computers use different encoding methods.
• This layer basically deals with the presentation part of the data.
• Presentation layer, carries out the data compression (number of bits reduction while transmission), which in return improves the data throughput.
• This layer also deals with the issues of string representation.
• The presentation layer is also responsible for integrating all the formats into a standardized format for efficient and effective communication.
• This layer encodes the message from the user-dependent format to the common format and vice-versa for communication between dissimilar systems.
• This layer deals with the syntax and semantics of the messages.
• This layer also ensures that the messages which are to be presented to the upper as well as the lower layer should be standardized as well as in an accurate format too.
• Presentation layer is also responsible for translation, formatting, and delivery of information for processing or display.
• This layer also performs serialization (process of translating a data structure or an object into a format that can be stored or transmitted easily).

Features of Presentation Layer in the OSI model: Presentation layer, being the 6th layer in the OSI model, plays a vital role while communication is taking place between two devices in a network.

List of features which are provided by the presentation layer are:

• Presentation layer could apply certain sophisticated compression techniques, so fewer bytes of data are required to represent the information when it is sent over the network.
• If two or more devices are communicating over an encrypted connection, then this presentation layer is responsible for adding encryption on the sender’s end as well as the decoding the encryption on the receiver’s end so that it can represent the application layer with unencrypted, readable data.
• This layer formats and encrypts data to be sent over a network, providing freedom from compatibility problems.
• This presentation layer also negotiates the Transfer Syntax.
• This presentation layer is also responsible for compressing data it receives from the application layer before delivering it to the session layer (which is the 5th layer in the OSI model) and thus improves the speed as well as the efficiency of communication by minimizing the amount of the data to be transferred.

Working of Presentation Layer in the OSI model : Presentation layer in the OSI model, as a translator, converts the data sent by the application layer of the transmitting node into an acceptable and compatible data format based on the applicable network protocol and architecture.  Upon arrival at the receiving computer, the presentation layer translates data into an acceptable format usable by the application layer. Basically, in other words, this layer takes care of any issues occurring when transmitted data must be viewed in a format different from the original format. Being the functional part of the OSI mode, the presentation layer performs a multitude (large number of) data conversion algorithms and character translation functions. Mainly, this layer is responsible for managing two network characteristics: protocol (set of rules) and architecture.

Presentation Layer Protocols : Presentation layer being the 6th layer, but the most important layer in the OSI model performs several types of functionalities, which makes sure that data which is being transferred or received should be accurate or clear to all the devices which are there in a closed network. Presentation Layer, for performing translations or other specified functions, needs to use certain protocols which are defined below –

• Apple Filing Protocol (AFP): Apple Filing Protocol is the proprietary network protocol (communications protocol) that offers services to macOS or the classic macOS. This is basically the network file control protocol specifically designed for Mac-based platforms.
• Lightweight Presentation Protocol (LPP): Lightweight Presentation Protocol is that protocol which is used to provide ISO presentation services on the top of TCP/IP based protocol stacks.
• NetWare Core Protocol (NCP): NetWare Core Protocol is the network protocol which is used to access file, print, directory, clock synchronization, messaging, remote command execution and other network service functions.
• Network Data Representation (NDR): Network Data Representation is basically the implementation of the presentation layer in the OSI model, which provides or defines various primitive data types, constructed data types and also several types of data representations.
• External Data Representation (XDR): External Data Representation (XDR) is the standard for the description and encoding of data. It is useful for transferring data between computer architectures and has been used to communicate data between very diverse machines. Converting from local representation to XDR is called encoding, whereas converting XDR into local representation is called decoding.
• Secure Socket Layer (SSL): The Secure Socket Layer protocol provides security to the data that is being transferred between the web browser and the server. SSL encrypts the link between a web server and a browser, which ensures that all data passed between them remains private and free from attacks.

Please Login to comment...

Similar reads.

• What are Tiktok AI Avatars?
• Poe Introduces A Price-per-message Revenue Model For AI Bot Creators
• Truecaller For Web Now Available For Android Users In India
• Google Introduces New AI-powered Vids App
• 30 OOPs Interview Questions and Answers (2024)

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Create your address on the web.

• Domain Check

Move your domain name to IONOS.

• Free Domain

Secure site traffic and build trust.

Create your own website easily.

Create your own online store.

Fast, scalable hosting for any website.

Optimized for speed, reliablity and control.

Reach out with your own email address.

Secure and share your data on the go.

Powerful Exchange email and Microsoft's trusted productivity suite.

Pay as you go with your own scalable private server.

• Virtual Private Servers (VPS)

Get enterprise hardware with unlimited traffic

Individually configurable, highly scalable IaaS cloud

• Business Name Generator
• Logo Creator
• Favicon Generator
• Whois Lookup
• Website Checker
• SSL Checker
• IP Address Check

What is the presentation layer in the OSI model?

The presentation layer is the sixth layer in the OSI model and is responsible for converting different file formats. This allows two systems to communicate. Other tasks carried out by the sixth layer include data compression and encryption.

What is the presentation layer?

What does the presentation layer do, which format does the presentation layer use, presentation layer protocols, skipping the presentation layer.

The presentation layer is the sixth layer of the OSI model. It is primarily used to convert different file formats between the sender and the receiver . The OSI model is a reference model that is used to define communication standards between two devices within a network . The development of this standard began in the 1970s and it was first published at the beginning of the following decade. This standard enables seamless interaction between different technical systems.

The model is made up of a total of seven different layers, all having their own clearly defined tasks. While there are clear boundaries between the layers, the layers interact with each other, with each layer building off the one below it. The different layers are as follows:

• Physical layer
• Data link layer
• Network layer
• Transport layer
• Session layer
• Presentation layer
• Application layer

The presentation layer interacts closely with the application layer, which is located directly above it. The presentation layer’s main task is to present data in such a way that it can be understood and interpreted from both the system sending the data and the system receiving it. After this has been accomplished, the application layer then determines how the data should be structured and what sort of data and values are permissible.

Using these entries, a command set, or an abstract transfer syntax, is then automatically created. The presentation layer now has the task of transferring the data in such a way that it is readable without changing the information contained within it.

The presentation layer is often also responsible for the encryption and decryption of data . The information is first encrypted on the sender’s side and then sent to the receiver in an encrypted state. Keys and encryption methods are then exchanged in the presentation layer. The recipient is then able to decrypt the unreadable data and convert it into a format that can be understood and interpreted.

If data is shown during a transfer, we often use the term transfer syntax. These are separated into the abstract transfer syntax , in which the transferred values are written, and the concrete syntax, which contains a definition of the value coding.

The receiver can only process and understand the data they receive if they receive all of the information from the presentation layer. The most common definition language is Abstract Syntax Notation One (ASN.1) , which is also recommended by the ISO. The ISO is an organization that is responsible for developing international standards in technology, management and manufacturing.

The presentation layer has many different formats. The most common text formats are the ASCII (American Standard Code for Information Interchange) and EBCDIC (Extended Binary-Coded Decimal Interchange Code). The most common image formats are GIF, JPEG and TIFF. Widely used video formats include MIDI, MPEG and QuickTime.

There are many different presentation layer protocols as well as transfer and encryption technologies in the presentation layer. These include:

The tasks which are carried out by the presentation layer are not always necessary for communication between two systems. In instances where both systems use the same formats, data conversion is not necessary. Additionally, encryption and compression are not required for every interaction and can also be carried out in another layer of the OSI model. If this is the case, the presentation layer can be skipped and the application layer (7) can communicate directly with the session layer (5) instead .

• Encyclopedia

Build or host a website, launch a server, or store your data and more with our most popular products for less.

By Katrina Miller

Follow our live updates on the total solar eclipse .

Reliable paper-framed glasses are by far the most popular option for safely watching the total solar eclipse on Monday. But they’ve gotten more difficult to find in some places ahead of the event.

If you’ve checked everywhere — your local planetarium, public library and even online — fear not: There is still a way to watch the eclipse safely, using items around the house. Here are a few options.

Use your hands

Palms up, position one hand over the other at a 90-degree angle. Open your fingers slightly in a waffle pattern, and allow sunlight to stream through the spaces onto the ground, or another surface. During the eclipse, you will see a projection of the moon obscuring the surface of the sun.

This method works with anything with holes, such as a straw hat, a strainer, a cheese grater or even a perforated spoon. You will also notice this effect when light from the partially eclipsed sun streams through leaves on a tree.

Set up a cardstock screen

For this option, you need a couple of white index cards or two sheets of cardstock paper. First, punch a small hole in the middle of one of the cards using a thumbtack or a pin.

Then, facing away from the sun, allow light to stream through this pinhole. Position the second card underneath to function as a screen. Adjust the spacing between the two cards to make the projection of the sun larger or smaller.

Make a box projector

If you’re up for a bit of crafting, you can make a more sophisticated pinhole projector . Start with a cardboard box — empty cereal boxes are often used, but you can use a larger box, too. You’ll also need scissors, white paper, tape, aluminum foil and a pin or thumbtack.

Cut the piece of paper to fit the inside bottom of the cardboard box to act as a screen. Use tape to hold it in place.

On the top of the box, cut two rectangular holes on either side. (The middle should be left intact — you can use tape to secure this if needed.)

Tape a piece of aluminum foil over one of the rectangular cutouts. Punch a tiny hole in the middle of the foil with the tack or pin. The other cutout will serve as a view hole.

With your back to the sun, position the foil side of the box over your shoulder, letting light stream through the pinhole. An image of the sun will project onto the screen at the bottom of the box, which you can see through the view hole. A bigger box will create a bigger image.

Enjoy the show through any of these makeshift pinholes. And remember, during totality, you can view the sun directly with your naked eye. But you should stop looking at the sun as soon as it reappears.

Katrina Miller is a science reporting fellow for The Times. She recently earned her Ph.D. in particle physics from the University of Chicago. More about Katrina Miller