Logging/Clean arch

Question 1

Logging

Answer 1

Logging is the process of recording run-time actions as they happen in real-time.

Helps us to understand the failures and performance bottlenecks of the application.

Question 2

ILogger levels

Answer 2

Debug
ILogger.LogDebug(“log_message”);
Logs that provide details & values of variables for debugging purpose.

Information
ILogger.LogInformation(“log_message”);
Logs that track the general flow of the application execution.

Warning
ILogger.LogWarning(“log_message”);
Logs that highlight an abnormal or unexpected event.

Error
ILogger.LogError(“log_message”);
Logs to indicate that flow of execution is stopped due to a failure.

Critical
ILogger.LogCritical(“log_message”)
Logs to indicate an unrecoverable application crash.

Question 3

Serilog

Answer 3

Serilog is a structured logging library for Asp.Net Core.

Supports variety of logging destinations, referred as “Sinks” - starts with Console, Azure, DataDog, ElasticSearch, Amazon CloudWatch, Email and Seq.

Question 4

Serilog - File Sink

Answer 4

The “Serilog.Sinks.File” logs into a specified file.
You can configure the filename, rolling interval, file size limit etc., using configuration settings.

Question 5

Serilog - Seq Sink

Answer 5

The “Serilog.Sinks.Seq” is a real-time search and analysis server for structured application log data.

Seq server can run on Windows, Linux or Docker.

Question 6

Serilog - RequestId

Answer 6

“RequestId” is the unique number (guid) of each individual requests, used to identify to which request the log belongs to.

RequestId is “TraceIdentifier” internally, that is generated by Asp.Net Core.

Question 7

Serilog - Enrichers

Answer 7

Enrichers are additional details that are added to LogContext; so they’re stored in logs.

Eg: MachineName[or]Custom Properties.

Question 8

Filters

Answer 8

Filters are the code blocks that execute before / after specific stages in “Filter Pipeline”.

Filters perform specific tasks such as authorization, caching, exeption handling etc.

Question 9

Overview of Types of Filters

Answer 9

Authorization Filter
Determines whether the user is authorized to access the action method.

Resource Filter
Invoking custom model binder explicitly
Caching the response.

Action Filter
Manipulating & validating the action method parameters.
Manipulating the ViewData.
Overriding the IActionResult provided by action method.

Exception Filter
Handling unhandled exception that occur in model binding, action filters or action methods.

Result Filter
Preventing IActionResult from execution.
Adding last-moment changes to response (such as adding response headers).

Question 10

Action Filter

Answer 10

When it runs

Runs immediately before and after an action method executes

‘OnActionExecuting’ method
It can access the action method parameters, read them & do necessary manipulations on them.
It can validate action method parameters.
It can short-circuit the action (prevent action method from execution) and return a different IActionResult.

‘OnActionExecuted’ method
It can manipulate the ViewData.
It can change the result returned from the action method.

Question 11

What are global filters?

Answer 11

Global filters are applied to all action methods of all controllers in the project.

Question 12

Filters [vs] Middleware

Answer 12

Middleware

Middleware pipeline is a superset of Filter pipeline, which contains the full-set of all middlewares added to the ApplicationBuilder in the application’s startup code (Program.cs).
Middleware pipeline execute for all requests.
Middleware handles application-level functionality such as Logging, HTTPS redirection, Performance profiling, Exception handling, Static files, Authentication etc., by accessing low-level abstractions such as HttpContext.

Filter
Filter pipeline is a subset of Middleware pipeline which executes under “EndPoint Middleware”.
In addition, filter pipeline executes for requests that reach “EndPoint Middleware”.
Filters handle MVC-specific functionality such as manipulating or accessing ViewData, ViewBag, ModleState, Action result, Action parameters etc.

Question 13

Exception Handling Middleware

Answer 13

Handles all errors occurred in filter pipeline (including model binding, controllers and filters).

Should be added to the application pipeline, before RoutingMiddleware.

Question 14

Custom Exceptions

Answer 14

A custom exception class is an exception class that inherits from System.Exception class & represents a domain-specific excpetion

Used to represent the domain-specific errors stand-out of system-related (.NET) related exceptions.

Question 15

UseExceptionHandler()

Answer 15

The built-in UseExceptionHandler() middleware redirects to the specified route path, when an unhandled exception occurs during the application execution.

Can be used as an alternative to custom exception handling middleware.

Catches and logs unhandled exceptions.

Re-executes the request in an alternative pipeline using the specified route path.

Question 16

Overview of SOLID Principles

Answer 16

“SOLID” is a set of five design patterns, whose main focus is to create loosely coupled, flexible, maintainabile code.

Broad goal of SOLID Principles:Reduce dependencies of various classes / modules of the application.

Question 17

5 solid principles

Answer 17

Single Responsibility Principle (SRP)
A software module or class should have one-and-only reason to change.

Liskov Subsitution Principle (LSP)
Subtypes must be substitutable for their base types.

Open-Closed Principle (OCP)
A class is closed for modifications; but open for extension.

Interface Segregation Principle (ISP)
No client class should be forced to depend on methods it does not use.

Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend upon abstractions.

Question 17

Dependency Inversion Principle (DIP)

Answer 17

Dependency Problem

Higher-level modules depend on lower-level modules.

Means, both are tightly-coupled.

The developer of higher-level module SHOULD WAIT until the completion of development of lower-level module.

Requires much code changes in to interchange an alternative lower-level module.

Any changes made in the lower-level module effects changes in the higher-level module.

Difficult to test a single module without effecting / testing the other module.

Question 18

Dependency Inversion Principle

Answer 18

Dependency Inversion Principle (DIP) is a design principle (guideline), which is a solution for the dependency problem.

“The higher-level modules (clients) SHOULD NOT depend on low-level modules (dependencies).

Both should depend on abstractions (interfaces or abstract class).”

“Abstractions should not depend on details (both client and dependency).

Details (both client and dependency) should depend on abstractions.”

Question 19

Single Responsibility Principle (SRP)- class

Answer 19

A class should have one-and-only reason to change.

A class should implement only one functionality.

Avoid multiple / tightly coupled functionalities in a single class.

Eg: A class that performs validation should only involve in validation.

But it should not read configuration settings from a configuration file.

But instead, it call a method of another class that reads configuration settings.

Question 20

Single Responsibility Principle (SRP)- interface

Answer 20

Create alternative implementation of the class by implementing the same interface.

Benefit: Makes the class independent of other classes, in terms of its purpose / functionality.

So that, the classes become easier to design, write, debug, maintain and test.

Question 21

Interface Segregation Principle (ISP)

Answer 21

No client class should be forced to depend on methods it doesn’t use.

We should prefer to make many smaller interfaces rather than one single big interface.

The client classes may choose one or more interfaces to implement.

Benefit: Makes it easy to create alternative implementation for a specific functionality, rather than recreating entire class.

Assume, a class has two methods: GetPersons() and AddPerson().

Instead of creating both methods in a single interface, create them as two different interfaces: IPersonGetter, IPersonAdder

interface IPersonsGetter (methods to get persons data)

interface IPersonsAdder(methods to create person)

Question 22

Open/Closed Principle (OCP)

Answer 22

A class is closed for modifications; but open for extension.

You should treat each class as readonly for development means; unless for bug-fixing.

If you want to extend / modify the functionality of an existing class; you need to recreate it as a separate & alternative implementation; rather than modifying existing code of the class.

Eg:

Assume, a class has a method: GetPersons().

The new requirement is to get list of sorted persons.

Instead of modifying existing GetPersons() method, you need to create an alternative class that gets sorted persons list.

Benefit: Not modifying existing code of a class doesn’t introduce new bugs; and keeps the existing unit tests stay relavant and needs no changes.

Interfaces
Create alternative implementation of the class by implementing the same interface.

Inheritance
Create a child class of the existing class and override the required methods that needs changes.

Question 23

Liskov Substitution Principle (LSP)

Answer 23

Functions that use references of base classes must be able to use objects of derived classes without breaking / changing its functionality.

The child classes that override methods of base class, should provide same behavior.

Using object of parent class
ParentClass variable = new ParentClass();
variable.Method(); //executes ParentClass.Method

Using object of child class
ParentClass variable = new ChildClass();
variable.Method(); //executes ChildClass.Method
[Both methods should offer same functionality]

Functions that use references of base classes must be able to use objects of derived classes without breaking / changing its functionality.

The child classes that override methods of base class, should provide same behavior.

If a derived class overrides a method of base class; then the method of derived class should provide same behavior:

With same input, it should provide same output (return value).

The child class’s method should not introduce (throw) any new exceptions than what were thrown in the base implementation.

The child class’s method should not implement stricter rules than base class’s implementation.

Benefit: Prevents code to break - if by mistake or wantedly, someone has replaced the derived class with its base class (or even vice versa), as its behavior doesn’t change.

Question 24

Overview of Clean Architecture

Answer 24

Instead of “business logic” depend on “data access logic”, this dependency is inverted; that means, the “data access logic” depend on “business logic”.

Benefit: The business logic is highly clean-separated, independent of data storage and UI, unit-testable.

Question 25

Traditional Three-Tier / N-Tier Architecture

Answer 25

User Interface (UI)

Business Logic Layer (BLL)

Repository Layer (RL)

Data Access Layer (DAL)

Question 26

Clean Architecture elements

Answer 26

UI
Controllers, Views, View Models
Filters, Middleware

Core
Business Logic Services
Business Logic Interfaces
Data Transfer Objects (DTO)

Domain
Repository Interfaces
Entity Classes

Infrastructure
DbContext, Repositories
External API Calls

Question 27

Clean Architecture benefits

Answer 27

Changing external system
Allows you to change external systems (external APIs / third party services) easily, without affecting the application core.

Scalable
You can easily scale-up or scale-out, without really affecting overall architecture of the application.

Database independent
The application core doesn’t depend on specific databases; so you can change it any time, without affecting the application core.

Testable
The application core doesn’t depend on any other external APIs or repositories; so that you can write unit tests against business logic services easily by mocking essential repositories.

Clean architecture is earlier named as “Hexagonal architecture”, “Onion architecture”, “Domain-Driven Design”, “Vertical Slice Architecture”. Over time, it is popular as “clean architecture”.