Interface Segregation Principle - SOLID Principle

In this article we are going to see the Interface Segregation Principle, which is used to separate the interfaces with corresponding methods, because classes should not define the interface methods which is not used. 

For example we will have to interface IWork, which consists of two methods one is DoWork and another one is TakeFood. this interface is deriving in classes named HumanWorker and RobotWorker where RobotWorker doesnt need to use the method TakeFood so it should not implemented, please see the below example.

  internal interface IWork

    {

        void DoWork();

        void TakeFood();

    }

    internal class HumanWorker : IWork

    {

        public void DoWork()

        {

            Console.WriteLine("Working");

        }

        public void TakeFood()

        {

            Console.WriteLine("Eating Food");

        }

    }

    internal class RobotWorker : IWork

    {

        public void DoWork()

        {

            Console.WriteLine("Working");

        }

        public void TakeFood()

        {

            throw new NotImplementedException("N/A");

        }

    }

After implementing the ISP, the above interface is segregated in to two interfaces and apply the interface which is really required for that classes.

    internal interface IWork

    {

        void DoWork();

    }

    internal interface ITakeFood

    {

        void TakeFood();

    }

    internal class HumanWorker : IWork, ITakeFood

    {

        public void DoWork()

        {

            Console.WriteLine("Working");

        }

        public void TakeFood()

        {

            Console.WriteLine("Eating Food");

        }

    }

    internal class RobotWorker : IWork

    {

        public void DoWork()

        {

            Console.WriteLine("Working");

        }

    }

From this article we can learn interface segregation principle ISP in SOLID Principle.

Liskov Substitution Principle - SOLID Principle using C# in .NET10

In this article are going to see what is Liskov Substitution Principle, Objects of the super class can be replaced by objects of the sub classes with out breaking the correctness of the program..

We take one example we take Shape class where we have the Area method which will calculate the area, but when you see the Square which will break the behaviour, if the values are not Equal. the Values of the variable are needs to be Equal for Square

    internal abstract class Shape

    {

        public int Width { get; set; }

        public int Height { get; set; }

        public abstract int Area();

    }

    internal class Rectangle : Shape

    {

        public override int Area()

        {

            return this.Width * this.Height;

        }

    }

    internal class Square : Shape

    {

        public override int Area()

        {

            if(this.Width != this.Height)

                throw new InvalidOperationException("All sides

                        are must be equal for square");

            return this.Width * this.Height;

        }

    }

public class LiskovSubstitutionPrinciple

    {

        public void CalculateArea()

        {

            Shape obj1 = new Rectangle();

            obj1.Width = 10;

            obj1.Height = 20;

            obj1.Area();

            Shape obj2 = new Square();

            obj2.Width = 20;

            obj2.Height = 10;

            obj2.Area(); // Here Base class behaviour is broken because of exception

        }

    }

Liskov Substitution Principle

How we make this class to LSP, the Base class behaviour should not broke, so we slightly change the code which adhere to Liskov substitution principle.

    internal abstract class Shape

    {

        public abstract int Area();

    }

    internal class Square(int SideLength) : Shape

    {

        public override int Area()

        {

            return SideLength * SideLength;

        }

    }

    internal class  Rectangle(int Width, int Height) : Shape

    {

        public override int Area()

        {

            return Width * Height;

        }

    }

    public class LiskovSubstitutionPrinciple

    {

        public void CalculateArea()

        {

            List<Shape> shapes = new List<Shape>

            {

                new Square(7),

                new Rectangle(4, 6)

            };

            foreach (var shape in shapes)

            {

                Console.WriteLine($"Area of {shape.GetType().Name}: {shape.Area()}");

            }

        }

    }

From the above code you can learn what is Liskov Substitution Principle.

Open Closed Principle - SOLID Principle

In this article we are going to see what is Open Closed Principle (OCP) in SOLID.  OCP is open for extension and closed for modification. that means a class can be extended through override and not allow to modify.

we see Employee class in which GetSalary is used to fetch the salary this method can be override in Manager class which is derived from employee class but not allow to modify the employee class.

From this article you can learn the Open Closed Principle

SOLID - Single Responsibility Principle

In this article we are going to see what is single responsibility principle (SRP) in SOLID. The SRP is about the class should have only one responsibility or we can say like it should talk about only one entity. For Example if it is a Employee class, then it should have behaviour and properties only about Employee. simply says the class should have only one reason to change.

First we will see a class which violating the SRP.

In the above class Salary we see that three methods

1. one is calculating Salary.

2. another one is save to DB

3. another one is Print to Salary. 

So the first one is application logic , second one is DB layer, third one is UI layer code, all are three different behaviour, now this is violating the SRP. 

How we can convert this to SRP.

Now if you see above example three classes in which each one have one responsibility, first one is business logic, second one is DB logic, third one is UI logic.

Now we can see a Logger class which is in SRP.

The above class is Logger, which have only one responsibility or talks about only one entity Logging message. if we have another method like  PrintMessage() in the class then that is irrelevant to the class then that is violating the SRP

Implementation of Repository pattern and Unit Of Work in .NET10 - Example 2

 In this post we are going to see the example 2 of implementation of repository pattern and unit of work in .Net10. we separate the project in to four layers. 

1. Domain or Entities

2. Application or UseCase

3. Infrastructure

4. Controllers

Dependencies:

Solution Structure

Domain or Entities:

1. It is consists of Entities.
2. It is consists of Repositories and Unit Of Work Interfaces.

Application or UseCase

1. It is consists of declaration of Application Service Interfaces with public access.
2. It is consists of Implementation of Application Services with internal access,
3. Usage of Repositories in the Application Services
4. To register the services in main program, we have to declare composition root.

Infrastructure

1. Consists of implementation of Repositories and Unit Of Work with internal access, which can be changed easily,in the future so business logic wont get change, because the application layer work with abstractions.
2. To register the repositories in main program we have to declare composition root.

Controller

1. Uses the Register method from application layer and infrastructure layer.

Let we see this with example.

Domain:

Application or Use Case:

Infrastructure Layer:

Controllers:

From this article you can learn a example of how to implement the Repository pattern and Unit Of Work. 

Implementation of Repository Pattern and UnitOfWork in .NET10

In this article we are going to see the what is the repository pattern and it's usage. we will see the implementation of Repository Pattern and UnitOfWork in .NET10.

using repository pattern we can decouple the abstraction and its implementation of DB layer, we can work with abstraction the implementation of that abstraction will be change based on the requirement and we can change the DB layer easily.

Abstraction interface: Domain Layer

Now we will see the interface or abstraction of UnitOfWork.

We have a Domain class named Authors:

Authors:

Create this IRepository class in the Domain layer where it will be referred in App Layer for usage, the implementation must be in infrastructure layer.

Application Layer or UseCase Layer

AuthorService

Infrastructure Layer where the actual implementation will be it can be anything like EFCore or SQL Layer etc. for example we will see that the EF-Core example. and implementation of UnitOfWork.

UnitOfWork:

Controller Layer

We have to use the composition root for register the services in infrastructure layer. and use it in the controller layer.

From this article we can learn the repository pattern and its implementation  along with UnitOfWork in .NET10.

Create and Extract Zip Files using C# .Net 10

In this article we are going to see how to create and extract a zip files using C# and .Net10. we will take one source folder and zip file name, one destination path for extract and two output folders.

From this article you can learn how to create and extract a zip files using C# and .Net10

Store Application Insights in Disk and Send it to Azure Monitor when Button Clicks in Asp.Net Core

In this post we are going to see how to store the application insights in Disk and send it to azure monitor when button click, both this two operation must be in same AppDomain or AppContext. 

Configure the ITelemetryChannel as store the logs in Disk path, we will store that in AppData Local Storage. The folder what we given here must be already created inside AppData. Then only the logs will be created.

Install the following package Microsoft.ApplicationInsights.AspNetCore in Asp.Net core Project. Then add the below lines in program.cs

          Inject (ITelemetryChannel channel)

          this.channel.Flush();

From this article you can learn how to save the application insights locally in Disk and send it later when you required to Azure Monitor.

What are the various ways to add Custom Properties in Application Insights

 In this tutorial we are going to see what are the various ways to add custom properties in application insights.

1. Direct in Logger
2. Using Scopes
3. Using Telemetry Client
4. Using Telemetry Initializer
5. Using Telemetry Processor

Direct in Logger:

When ever you give message to Log Methods if you pass parameters and value in methods using {paramname}, then this will consider as custom properties. for example below two custom properties are there one is Id another one is AuthorTimeStamp.

Using Scopes:

Using BeginScope we can pass the Custom Properties for entire scope, that means whatever log method is inside this scope will add this custom properties. Both LogDebug and LogError will have AuthorRequest and AuthorId Custom Properties.

Using Telemetry Client:

This is a direct message added using Telemetry client where you can add the custom properties with the telemetry. for example we are using below ExceptionTelemetry and TraceTelemetry.

Using Telemetry Initializer:

This will run in pipeline before telemetries are send to Azure monitor. In below code we are attaching or adding one custom property to all Trace Telemetry.

Using Telemetry Processor:

This will run in pipeline after Telemetry Initializer, Here we are adding custom property to Request Telemetry when it have response code 200.

From this tutorial you can learn how to add the Custom properties in various ways in application insights.

How to use Application Insights in ASP.Net Core

In this tutorial we are going to see how to use the Application Insights in asp.net core. and also explain about how to use some features of application insights. First we see few steps for basic level of logging, then we will see other features present in application insights.

Additional Features:

1. Use Custom Properties
2. Log Different messages
3. Controller Level Configuration
4. Remove or Filter Modules

Steps for Basic Level of Logging:

First we have to install Microsoft.ApplicationInsights.AspNetCore in Asp.Net Core Project. Configure program.cs like below to use application insights.

           builder.Services.AddApplicationInsightsTelemetry();

The Default LogLevel for ApplicationInsightsLoggerProvider is Warning.  if you try to Log Debug or Trace it won't Log, because default level is Warning.

 

Setting Log Level of Default Provider (ApplicationInsightsLoggerProvider) to Debug
will get change based on the Environment you deploy your application, so load the
LogLevel from configuration and set to Default Provider (ApplicationInsightsLoggerProvider).

Before that we have know that LogLevel will work in Bottom to Top order. If you give value of enum Critical as LogLevel, then only Critical will log. if you give LogLevel value as Warning, then Logs from "Critical", "Error" and "Warning" will Log. it will log from Bottom to Top approach until which LogLevel will you give. So the Default Value now is Warning, to log Debug, we have to remove the default Rule and create one. When you give Empty value in AddFilter for first param then it will take default provider with log level what we mention in second parameter.

Above code will make default log level to Debug, so now up to Log Debug will work. Now you can log the messages in your code, Make sure you are getting the log level from configuration File. Now we see different features present in Application Insights, above 2 steps is enough to log messages up to Debug Level, if you don't want Log Debug, then change that to higher level like LogLevel.Error for AddFilter of ApplicationInsightsLoggerProvider.

1. Use Custom Properties

we will take a example of custom TelemetryProcesssor where custom properties for each HttpRequest will be logged.

2. Log Different Messages

We have to inject ILogger<ControllerName> then use the object and call the methods inside that. Here we are using two methods LogDebug and LogError.

3. Controller Level Configuration

How to set the LogLevel configuration at controller level, we have to do the below config in program.cs. You can see that AuthorController logs only Error, even though if you have LogDebug method  in code, but in insights it wont get logged.

4. Remove or Filter Modules

In Module level we can filter the messages like in Dependencies are logged in application insights, if we don't want SQL Text from EF core wont need to log then configure EnableSqlCommandTextInstrumentation item as "false". 

if you don't want the Dependencies are not allow to log then we have to remove the module like below in Program.cs.

Before Remove Module: you can see Dependency, After Remove Module: you can see Dependency(0). From this tutorial you can learn how to use the Application Insights in Asp.Net Core.

How to create a custom component or control in React Typescript

 In this tutorial we are going to see how to create a custom control or component in React Typescript.

1. Props and Ref as Input
2. Html Template 
3. Css

Why we need Props and Ref as Input, Props means input parameters that needs for component. Ref is used for Referring your component using Ref when it is accessed or used in the Html.

From the above you can see when RButton component is used we referred it as using UseRef. 

useImperativeHandle  used to expose the methods and properties to access a the parent component when it is referred at the time of usage, in this example we are exposing Id and click event for the ref. Now we can see the full implementation of RButton Component.

Full Component Implementation

Component CSS:

Now we can use it like Below

Output:

From this tutorial you can learn how to write the custom component in React Typescript