- In software engineering, a design pattern is a reusable solution to a commonly occurring problem within a software design. It's like a blueprint or template that can be adapted to different situations.
- Imagine you're building a house.
- You have different parts to construct: the foundation, walls, roof, plumbing, electrical system, etc. Each part has its own complexities.
- A design pattern is like a proven blueprint for solving such common building problems.
- For example, you might face the challenge of how to connect the plumbing, electrical, and heating systems efficiently. Instead of figuring out a new solution every time, you can use a proven blueprint (design pattern) that outlines how to combine these systems effectively.
- Design patterns provide a shared vocabulary for software developers and can speed up the development process by providing proven solutions to common design problems.
- To work with these complex web applications developers use different design patterns to lay out their projects, to make the code less complex and easier to work with. The most popular of these patterns is MVC also known as Model View Controller.
- Lets say you are building a simple To-do list application where users can add, view, and delete tasks. Without a clear structure, the code for managing data, handling user input, and displaying the interface can get mixed up. This makes the codebase harder to manage, debug, and extend.
- To resolve this what if we kinda seperate our code and define some sort of structure or a standard pattern? this kind of seperate of layers MVC help us to do.
- The MVC framework includes the following 3 components:
- Controller
- Model
- View
- Workflow
- As a client you request for a data from a server using a web page. The web page could be static (having static contents) or dynamic (values generated by server).
- Now if its a static content you just display the html file, but when a dynamic content is required, there are lot of works happens behind the scene.
- Controller is the one which gets the request from the client. So lets say the client is requesting for a student data and on the browser it hits the page /getStudentInfo.
- The Controller will get this request , it has multiples views or page, since the client has request for /getStudentInfo. It will call that view, but hold on this is a dynamic page, it requires data.
- Database stores all the data, now the Controller passes the request to Service Layer, Service Layer passes the request to DAO (Data Access Object) and DAO fetch the data from the database.
- The data transfers between these layers are of object. DTO(Data Transfer Object) is used to transfer the data between classes and modules of your application.
- DAO Layer sends back this data to the Service Layer, Service Layer handles business logic, interacts with the DAO to retrieve data, and performs necessary data transformations or calculations, sends back this data to the Controller.
- Now the data received by Controller needs to be store somewhere right? so here Model comes into picture.
- So Controller sends the data to Model, this data is in the Model form which is passed to the View.
- View sends back the response to the client, thus generating a dynamic content on its page.
Note
In some study cases, model has the capabilites to handle business logics and also perform interaction with the database.
- The Controller receives the client's request. It's responsible for handling the initial request logic, determining which action to take, and which data to fetch.
- The Controller forwards the request to the appropriate Service Layer method, initiating the process to gather the necessary data.
- The Service Layer acts as an intermediary between the Controller and the DAO. It contains the business logic and orchestrates the workflow for processing the request.
- The Service Layer calls the DAO to retrieve data from the database, encapsulating business rules and possibly data transformations.
- The DAO is responsible for interacting with the database. It executes database queries, fetches the necessary data, and returns it to the Service Layer.
- The DAO abstracts and encapsulates all access to the data source, providing a clean API to the Service Layer.
- The data retrieved by the DAO is passed back up to the Service Layer. The Service Layer may process this data, applying any necessary business logic, and then returns it to the Controller.
- DTOs or Data Transfer Objects are objects that carry data between processes
- Data Transfer Object (DTO) is a useful concept for transferring data between different components of the application. It is often used to encapsulate data and pass it between the Model, View, and Controller.
- DTO should only contain private fields for your data, getters, setters, and constructors.
- DTO is not recommended to add business logic methods to such classes, but it is OK to add some util methods.
- E.g
public class StudentDTO
{
public string Name { get; set; }
public int id { get; set; }
public string city { get; set; }
// Additional properties can be added as per your requirements
}
- The Model is responsible for representing the application's data structure, often as objects that the application can easily manipulate.
- The Controller may use the Model to store and organize the data before passing it to the View.
-
The View is responsible for presenting data to the user. It takes the data, now organized by the Model, and formats it for display in the web page.
-
The View sends the final rendered content back to the client, displaying the dynamic content as requested.
-
Reference video.
- Mono means single and lithic means stone. It means a single stone.
- A monolithic architecture in software refers to a design where all components of an application, including the user interface, business logic, and data access layers, are integrated into a single, unified codebase.
- Lets say if the application consist of multiple teams, all teams will work on the same code base.
- Since the code base is same for all the teams, if we consider a java programming language we will have build artifact called a war file.
- This war file is deployed on the server like tomcat via CI/CD pipeline.
- Monolithic architecture could be useful where the complexity won't increase in time, like a to-do list application.
- Single Executable: The entire application is packaged and deployed as a single executable file. All components and modules are bundled together.
- Tight Coupling: The components and modules within the application are highly interconnected and dependent on each other. Changes made to one component may require modifications in other parts of the application.
- Shared Memory: All components within the application share the same memory space. They can directly access and modify shared data structures.
- Monolithic Deployment: The entire application is deployed as a single unit. Updates or changes to the application require redeploying the entire monolith.
- Centralized Control Flow: The control flow within the application is typically managed by a central module or a main function. The flow of execution moves sequentially from one component to another.
- In a monolithic architecture, all elements of the application — from the user interface and business logic to the data access code — are built and bundled together in a single codebase and repository. This architecture typically uses concepts such as templates/themes and the Model-View-Controller (MVC) design pattern.
- The most common type of multi-tier architecture in distributed systems is a three-tier client-server architecture. In this architecture, the entire application is organized into three computing tiers
- Presentation tier
- Application/Service tier
- Data-tier
- The presentation tier consist of UI/UX frontend technologies which can be comprises of different tech stacks like Angular or React. It is the user interface and topmost tier in the architecture. Its purpose is to take request from the client and displays information to the client.
- It communicates with other tiers using a web browser as it gives output on the browser. If we talk about Web-based tiers then these are developed using languages like HTML, CSS, JavaScript.
- It is the middle tier of the architecture also known as the logic tier as the information/request gathered through the presentation tier is processed in detail here. It also interacts with the server that stores the data. It processes the client’s request, formats, it and sends it back to the client. It is developed using languages like- Python, Java, PHP, SpringBoot etc.
- This layer may consist of all the API which communicates with the database to fetch or perform database operations. This middle tier will have a seperate codebase which can have different tech stacks
- The presentation layer communicates with service layer with Rest API's calls.
- The codebase of the service tier consist of a different CI/CD pipeline to build a artifact.
- It is the last tier of the architecture also known as the Database Tier. It is used to store the processed information so that it can be retrieved later on when required. It consists of Database Servers like- Oracle, MySQL, DB2, etc. The communication between the Presentation Tier and Data-Tier is done using middle-tier i.e. Application Tier.
- Logical separation is maintained between Presentation Tier, Application Tier, and Database Tier.
- Enhancement of Performance as the task is divided on multiple machines in distributed machines and moreover, each tier is independent of other tiers.
- Increasing demand for adding more servers can also be handled in the architecture as tiers can be scaled independently.
- Developers are independent to update the technology of one tier as it would not impact the other tiers.
- Programmers can easily maintain the database, presentation code, and business/application logic separately. If any change is required in business/application logic then it does not impact the presentation code and codebase.
- Security is improved as the client cannot communicate directly with Database Tier. Moreover, the data is validated at Application Tier before passing to Database Tier.
- The MVC pattern takes place in the presentation tier of the above architecture (for a webapp):
- Data Tier
- Application/Service Tier
- Presentation Tier
- controller: intercepts the HTTP request and returns the HTTP response;
- model: stores data to be displayed/treated;
- view: organises output/display.
- Typical flow:
- The user sends the HTTP request;
- The controller intercepts it;
- The controller calls the appropriate service;
- The service calls the appropriate dao, which returns some persisted data (for example);
- The service treats the data, and returns data to the controller;
- The controller stores the data in the appropriate model and calls the appropriate view;
- The view get instantiated with the model's data, and get returned as the HTTP response.
- Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are:
- Independently deployable
- Loosely coupled
- Services are typically organized around business capabilities. Each service is often owned by a single, small team.
- Microservices are an architectural approach to develop software applications as a collection of small, independent services that communicate with each other over a network. Instead of building a monolithic application where all the functionality is tightly integrated into a single codebase, microservices break down the application into smaller, loosely coupled services.
- Each microservice is designed to perform a specific business function and can be developed, deployed, and scaled independently. It allows you to take a large application and decompose or break it into easily manageable small components with narrowly defined responsibilities. It is considered the building block of modern applications. Microservices can be written in a variety of programming languages, and frameworks, and each service acts as a mini-application on its own.
- The single big deployable unit is seperated into small different deployable units which is based on the business functionality. So here we can see there codebase is now seperated into different functionality , each teams works on their respected codebase and each codebase have different CI/CD.
- So each unit has a seperate database.
- Here API gateway is required because, today there could be less microservices or less functionality, but in future if the scope increases, then the frontend stack requires a gateway to call services based on the request of client.
- Microservices are the individual, self-contained services that encapsulate specific business capabilities. Each microservice focuses on a distinct function or feature.
- API Gateway is a central entry point for external clients to interact with the microservices. It manages requests, handles authentication, and routes requests to the appropriate microservices.
- Monolithic
- Monolithic architecture as almost zero latency thus increases the performance.
- All the interactions are handled in a single deployed machine through the functions called directly the monolithic architecture the user interface middleware and everything is composed into single deployable unit deployed in a single unit.
- 3-Tier
- In case of 3-Tier we have dedicated deployable unit for each layer so the user interface can be deployed in separate machine which communicates with the application or service layer through the network via rest api calls due to which there is network latency during this network call.
- The network latency is compatibly high in this entire architecture when compared with the monolithic architecture.
- Microservices
- In case of the microservices the network latency is higher than both, the monolithic and the 3-Tier architecture because here we have many smaller independent deployable units modeled around the business domain in addition to that we also have API gateway which acts as abstraction layer and pass-through for the micro services
- In addition to that this micro services also may need to communicate with each other so there is a network latency, thus by impacting the performance.
- Monolithic
- Monolithic architecture does not have code seperation here all the user interface middleware and db scripts are present in the same code base so all the teams will be working on the same code base.
- For every code change the team need to make sure that it does not break any other part of code for example if you are from user interface team and you want to make some security vulnerability code fix you need to make sure it does not break the other functionality layer which is dependent on user module since all the code are interdependent or tightly couple, this makes it hard for the developers.
- The problem further increases when the complexity of the application increases here we have one CI/CD pipeline. The pipeline running time also higher because we need to build a bigger deployment artifact bundling all the code and running all the unit test cases.
- If any of these unit test cases fails, the CI/CD job will fail. Thus again fixing the case and re-deploying it will take much time.
- 3-Tier
- 3-Tier architecture there is a code seperation because there will be separate code base for each layer or tire that is user interface will have a separate code base and middleware will have its own code base and separate code base for the db scripts.
- So here the user interface team can work independently likewise the application/service team can work independently, still if the middleware/application/service is big there will be more than one team that can be working on the same.
- Microservices
- Code base in the microservices architecture it has a well-defined code seperation because there will be separate code base and independent deployable unit for each microservice
- Since the deployable units are based on business domain each unit can have a dedicated team and well-defined automated testing suit.
- Each services will have seperated CI/CD pipelines
- Monolithic
- Monolithic architecture are not scalable and there is a concern in optimized resource utilization for example if there are more functionality added there will be increases in the load on the middleware, suppose now we want to scale the back-end alone which is not possible because in the monolithic.
- Since there's a single large deployable unit so we need to deploy the complete artifact file in the multiple instances we might not really need to deploy the user interface.
- In addition to this if you want to monitor the service how much time each request takes and it becomes difficult to pinpoint where there is a lag or which unit causing.
- 3-Tier
- In the 3-Tier architecture since there is a separate deployable unit for each layer here we can scale moderately
- Still in the middleware layer it is single deployable unit in the entire architecture so there is a issue in scaling individual business unit for example if you found that the resource utlized by a functionality is higher than other functionality, to scale that particular functionality is not possible, because all the modular layer is bundled as a single artificate.
- Microservices
- The microservice architecture solves is the scalability and optimized resource utilization.
- Here we have independent deployable artifact based on the business unit. Each deployable artifact can be scaled as per the need that is we can provide three instances.
- Api monitoring of the each service can be done at the api gateway level or at the individual microservice level. Due to this we can keep optimizing specific unit and provide improved performance.
- Monolithic
- Since we have single deployable file all the code must be of same programming language and same or compatible technology we can't really make use of two completely different programming language.
- 3-Tier
- We can use different technologies or programming language for each tier or layer in the calorie counter application.
- The frontend interface can be written in javascript framework , react.js and the backend can be in the java framework springboot.
- Microservices
- In the microservice each deployable unit is independent which communicate with each other through the rest api calls because of which each independent component can be developed with different tech stack so we can bring variety of each programming language to our application.
- Monolithic
- When it comes to deployment monolithic applications need to be deployed in traditional application server which will be of a same type.
- Example in case of Java web services, we need to deploy war file in tomcar, WebSphere or in Glass Fish only.
- 3-Tier
- In the 3-Tier architecture each tire deployable unit can be deployed independently in their own server we can use container or web server or the application server.
- Microservices
- In the microservices architecture we have the flexibility to deploy it based on our need.
- Each unit can be deployed on different infrastructure like cloud, container or on a web server.
- Monolithic and 3-Tier
- When it comes to fault tolerance if there is an issue in the deployed component in the entire service goes down which brings the complete application down.
- This is totally undesirable in today competitive world.
- Microservices
- In the case of micro service architecture one of the biggest pros is that it is fault tolerance.
- With the well orchestrated micro service and well defined circuit breaker pattern it is really possible to have the application running even if one of the application service fails.
- There is no single architecture which is suitable for all the application needs some application suits monolithic architecture better, some application suits 3-Tier architecture and enterprise applications suits microservice.
- For example if you want to develop a very simple application with one or two units, it is better to stick to the monolithic architecture there is no point in separating the application to smaller units. if the application is very small in that case you will have a single deployable unit so it is cost effective and highly performant because there is no network latency.
- On the other hand if you want to develop an enterprise application which need to be highly scalable and highly available then the micro services are the way to go because of the enterprise applications increasing complexity over time and will have different team to tackle each services in the component and also it will be easy to maintain.