FluentValidation: What Is It?
An open-source validation toolkit for.NET called FluentValidation offers a fluid interface for creating and implementing validation rules. It makes validation logic easy to comprehend, write, and maintain by enabling developers to describe it succinctly and clearly.

.NET 8's FluentValidation
Installing the FluentValidation NuGet package is required in order to use FluentValidation in.NET 8. The following command can be used to accomplish this in the.NET CLI or Package Manager Console:

dotnet add package FluentValidation

Verifying a Basic User Model
Let's construct a straightforward example in which we wish to validate a User class. To make sure the user's email address is legitimate and their name is not empty, we will use FluentValidation.

using FluentValidation;

public class User
{
    public string Name { get; set; }
    public string Email { get; set; }
}

public class UserValidator : AbstractValidator<User>
{
    public UserValidator()
    {
        RuleFor(user => user.Name).NotEmpty().WithMessage("Name cannot be empty");
        RuleFor(user => user.Email).NotEmpty().EmailAddress().WithMessage("Invalid email address");
    }
}

In this instance:

• We provide properties for Name and Email in our User class definition.
• We construct a class called UserValidator, which is derived from AbstractValidator<User>.
• We define validation rules for the Name and Email properties inside the UserValidator constructor using the RuleFor method.

Applying FluentValidation to Your Software
Let's look at how we can utilize FluentValidation in our application now that we have our User class and matching validator:

class Program
{
    static void Main()
    {
        var user = new User { Name = "Mahesh Chand", Email = "[email protected]" };
        var validator = new UserValidator();

        var validationResult = validator.Validate(user);

        if (validationResult.IsValid)
        {
            Console.WriteLine("User is valid");
        }
        else
        {
            foreach (var error in validationResult.Errors)
            {
                Console.WriteLine($"Validation Error: {error.ErrorMessage}");
            }
        }
    }
}

In this instance:

• We construct an instance of the User class and set its properties.
• We instantiate a UserValidator object.
• By handing in the User instance, we invoke the Validate method on the validator.
• We verify the validity of the validation result. We print a success message if it is. If not, we repeat the mistakes and print them.

.NET 8's FluentValidation offers a tidy and expressive approach to handling validation in your applications. You can confidently design and run validation rules thanks to its fluid interface and simple syntax. Using FluentValidation makes it possible to isolate your validation logic apart from your business logic, as seen in our example, which makes your codebase easier to read and manage.

Cross-Origin Resource Sharing (CORS) is a vital security feature that controls how resources on a web page can be accessed by web applications from different domains. In an ASP.NET Core project, enabling CORS involves configuring the server to allow or restrict access to its resources from different origins. Here's a step-by-step guide on establishing CORS in your ASP.NET Core application.

Step 1. Set up the middleware for CORS

Installing the Microsoft.AspNetCore.Cors package is the first step. Using the NuGet Package Manager Console, you may accomplish this.

Install-Package Microsoft.AspNetCore.Cors

Alternatively, you can add it to your project's .csproj file:
<PackageReference Include="Microsoft.AspNetCore.Cors" Version="x.x.x" />

Replace x.x.x with the latest version available.

Step 2. Configure CORS in Startup.cs
Open your Startup.cs file and locate the ConfigureServices method. Add the CORS service by calling AddCors in the ConfigureServices method.
public void ConfigureServices(IServiceCollection services)
{
    // Other configurations

    services.AddCors(options =>
    {
        options.AddPolicy("AllowSpecificOrigin",
            builder =>
            {
                builder.WithOrigins("https://example.com")
                       .AllowAnyHeader()
                       .AllowAnyMethod();
            });
    });

    // Other configurations
}

In the code snippet above:

• The CORS services are added to the application's service container via AddCors.
• AddPolicy generates a specified CORS policy that identifies permitted origins, headers, and methods ("AllowSpecificOrigin" in this example).

To designate which domains are permitted to access your resources, modify WithOrigins. To accept requests from any origin, use a "*".

Step 3. Turn on the CORS middleware
Add the CORS middleware to Startup.cs's Configure function.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // Other configurations

    app.UseCors("AllowSpecificOrigin");

    // Other configurations
}

This middleware must be added before other middleware that may handle requests, such as MVC or static file middleware.

Step 4: Verify Your CORS Setup
Once set up, make queries to your ASP.NET Core APIs from various origins to test the CORS settings. Make that the methods, headers, and permitted origins meet the needs of your application.

In summary
For secure communication between your application and clients from different domains, and to control access to your resources, you must implement CORS in your ASP.NET Core project. You can increase the security of your application while enabling critical cross-origin communication by defining CORS policies, which allow you to control which origins can access your APIs.

Always keep in mind to properly set your CORS policies based on the security requirements of your application, keeping in mind the possible hazards related to cross-origin requests.

One of the most frequent problems that developers encounter in the intricate and ever-changing process of software creation is the "class explosion." This happens when a software system has a lot of classes—often more than what was planned or organized in the first place. We will examine the reasons behind the class explosion, how it affects software systems, and management and mitigation techniques in this post.

Reasons for the Explosion of Classes
Excessively Fine-Grained Design: An excessively fine-grained design is one of the main reasons for class explosion. The number of classes can grow rapidly when every task or feature is included within a distinct class without a clear and obvious goal in mind.

class UserManager { }

Inadequate Abstraction: An excessive number of classes may result from improper abstraction. Class fragmentation occurs when developers are unable to recognize and produce meaningful abstractions, leading to an abundance of tiny, specialized classes.

class User { }
class UserValidationHelper { }
class UserPersistenceManager { }

Insufficient Planning: In some cases, inadequate upfront planning can contribute to class explosion. If the design lacks a clear structure and roadmap, developers might introduce new classes in a reactionary manner, leading to an unmanageable number of classes.

class FeatureAProcessor { }
class FeatureBProcessor { }
class FeatureCProcessor { }

The effects of the class explosion

• Complexity and Cognitive Load: The system's total complexity rises with the number of classes. The relationships and responsibilities of each class may be difficult for developers to understand, which will raise their cognitive load.
• Maintenance Challenges: Having a lot of classes may make maintenance difficult. It becomes more difficult to make modifications or add new features since developers have to work their way through a complex class hierarchy.
• Decreased Reusability: Decreased reusability may result from an excessive number of classes. It's possible that developers will have to start from scratch if they try to utilize tiny, specialized classes in other areas of the system.

Techniques to Control Class Explosion
Refactoring: Examine and reorganize the codebase on a regular basis to find and remove superfluous classes. Combine features into classes that are well-thought-out and integrated.

class UserManager { }

Abstraction and Encapsulation: Emphasize proper abstraction and encapsulation to ensure that classes have well-defined responsibilities. Avoid creating classes for every minor task and focus on creating meaningful, high-level abstractions.
    class User { }
    class UserManager { }

​​​Design Patterns: Utilize design patterns to manage class complexity. Patterns like the Singleton pattern, Factory pattern, and Strategy pattern can help organize and streamline class hierarchies.

class UserFactory { }

Modularization: Modularize the system into manageable modules or components. Divide the system into cohesive parts, each with a distinct responsibility, to prevent the proliferation of classes.
class AuthenticationModule { }

Guidelines and Code Reviews: Establish coding guidelines and conduct regular code reviews to ensure that the development team adheres to best practices. Enforce consistency in class design and encourage developers to think about the overall system architecture.

Example: Refactoring a Class Explosion
Consider a scenario where a class explosion has occurred in a system responsible for handling various geometric shapes:

class SquareValidator { }
class SquareCalculator { }
class CircleValidator { }
class CircleCalculator { }
class TriangleValidator { }
class TriangleCalculator { }

There are numerous classes as a result of this design's lack of abstraction. Let's rework this situation by adding an abstract and more unified design:

abstract class Shape { }
class Square extends Shape { }
class Circle extends Shape { }
class Triangle extends Shape { }

class ShapeValidator { }
class ShapeCalculator { }

We've added an abstract Shape class as part of this refactoring, which eliminates duplication and creates a more organized and manageable design.

In summary
Although class explosion is a typical problem in software design, it may be controlled and lessened with careful planning, frequent refactoring, and strict code standards. Developers can design systems that are not only scalable but also easier to understand and manage over time by placing a strong emphasis on appropriate abstraction, encapsulation, and modularization. Recall that a well-designed system prioritizes the classes' meaningful order and coherence over their quantity.

REST API: What is it?
REpresentational State Transfer is what the acronym REST stands for. It's an architectural design that lays forth a set of guidelines for building Web services. REST recommends generating an object from the data a client requests and responding to the user with the object's values via a client-server conversation. For instance, you can construct an object on the server-side if the user requests a Bangalore taxi reservation at a specific location and time. You have an object over here, and you are transmitting the object's state. As a result, Representational State Transfer, or REST, is its name.

An application can be made more appropriate for the internet by utilizing the reduced bandwidth usage provided by the REST architectural style. It is entirely dependent on the resources and is frequently referred to as the "language of the internet."

REST API Fundamentals
The six REST guiding principles are listed below:

Without a state

The body of the request contains the current status of the resource, and the URL is used to identify the resource specifically. The client receives a response from the server via headers, body, or status once the request has been processed. All the necessary information is included in the requests that clients send to servers so that the servers can comprehend the requests. This may appear in the body, headers, query-string arguments, or even the URL. The server API does not cache any state, thus each request is independent of the others. Additionally helpful in scaling the API service in a cloud context is its RESTful characteristic.

Client-Server
The client-server architecture enables a uniform interface and separates clients from the servers. This enhances the portability across multiple platforms as well as the scalability of the server components.

Uniform Interface
To obtain the uniformity throughout the application, REST has the following four interface constraints:

• Resource identification
• Resource Manipulation using representations
• Self-descriptive messages
• Hypermedia as the engine of application state

Cacheable
To provide a better performance, the applications are often made cacheable. This is done by labeling the response from the server as cacheable or non-cacheable either implicitly or explicitly. If the response is denied as cacheable, then the client cache can reuse the response data for equivalent responses in the future.
Minimal APIs in .Net 8 or .Net 7

Minimal APIs are architected to create HTTP APIs with minimal dependencies. They are ideal for microservices and apps that want to include only the minimum files, features, and dependencies in ASP.NET Core.

Limitations of Minimal API

• No support for filters: For example, no support for IAsyncAuthorizationFilter, IAsyncActionFilter, IAsyncExceptionFilter, IAsyncResultFilter, and IAsyncResourceFilter.
• No support for model binding, i.e. IModelBinderProvider, IModelBinder. Support can be added with a custom binding shim.
• No support for binding from forms. This includes binding IFormFile. We plan to add support for IFormFile in the future.
• No built-in support for validation, i.e. IModelValidator
• No support for application parts or the application model. There's no way to apply or build your own conventions.
• No built-in view rendering support. We recommend using Razor Pages for rendering views.
• No support for JsonPatch
• No support for OData
• No support for ApiVersioning. See this issue for more details.

With the following APIs,

REST APIs follow standard HTTP Verbs like GET, POST, PUT, DELETE, PATCH which are basically CRUD operation on an object. The APIs are arranged to form an internet resource. For example in the above example, we have resource as “todoitem” which can be created, modified, deleted using APIs, and URL format is formed accordingly.

using Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddDbContext < TodoDb > (opt => opt.UseInMemoryDatabase("TodoList"));
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment()) {
    app.UseSwagger();
    app.UseSwaggerUI();
}
app.MapGet("/", () => "Hello World!");
app.MapGet("/todoitems", async (TodoDb db) => await db.Todos.ToListAsync());
app.MapGet("/todoitems/complete", async (TodoDb db) => await db.Todos.Where(t => t.IsComplete).ToListAsync());
app.MapGet("/todoitems/{id}", async (int id, TodoDb db) => await db.Todos.FindAsync(id)
    is Todo todo ? Results.Ok(todo) : Results.NotFound());
app.MapPost("/todoitems", async (Todo todo, TodoDb db) => {
    db.Todos.Add(todo);
    await db.SaveChangesAsync();
    return Results.Created($ "/todoitems/{todo.Id}", todo);
});
app.MapPut("/todoitems/{id}", async (int id, Todo inputTodo, TodoDb db) => {
    var todo = await db.Todos.FindAsync(id);
    if (todo is null) return Results.NotFound();
    todo.Name = inputTodo.Name;
    todo.IsComplete = inputTodo.IsComplete;
    await db.SaveChangesAsync();
    return Results.NoContent();
});
app.MapDelete("/todoitems/{id}", async (int id, TodoDb db) => {
    if (await db.Todos.FindAsync(id) is Todo todo) {
        db.Todos.Remove(todo);
        await db.SaveChangesAsync();
        return Results.Ok(todo);
    }
    return Results.NotFound();
});
app.Run();
class Todo {
    public int Id {
        get;
        set;
    }
    public string ? Name {
        get;
        set;
    }
    public bool IsComplete {
        get;
        set;
    }
}
class TodoDb: DbContext {
    public TodoDb(DbContextOptions < TodoDb > options): base(options) {}
    public DbSet < Todo > Todos => Set < Todo > ();
}

In summary
The REST architecture style offers a common method for clients to access and retrieve server data as well as a standard approach to arrange resources across the internet. Minimal APIs need to have the least amount of code possible and can be quickly and simply created without the need for authentication or with very little dependencies by sitting behind a gateway that does.

Logging: What Is It?
The technique of recording events in real time and adding details like execution time and infrastructure information is known as logging in software. It is essential to every software program, especially when debugging problems. Logs are useful for deciphering errors, locating performance snags, and assisting in issue solving.

Logs are commonly kept in files, databases, or consoles according to the convenience and severity of the application. Although logs can contain a variety of data, error and informational messages are frequently recorded. Informational messages record routine activities such as method calls, user logins, or product checkouts, whereas error messages offer detailed information for troubleshooting.

By offering a generic logging interface that is uniform throughout the framework and external libraries, ASP.NET Core streamlines logging. Problem diagnosis and log navigation are made easier by this standardization. Users can set log verbosity and route logs to various locations, including files, consoles, and databases, using the framework.

Logs are stored by logging providers in ASP.NET Core, and users can set up several providers for their apps. Logging providers like Console, Debug, EventSource, and EventLog (unique to Windows) are part of the standard ASP.NET Core configuration.

Recognizing the Difference: Software System Logging vs. Monitoring

ASP.NET Core has helpful tools for logging—a process of recording events in your applications. System events, user actions, performance indicators, and other events and processes are all recorded in detail through logging. This data, which is commonly kept in a database or log file, enables you to see problems and resolve them, enhance performance, and comprehend how your program is utilized.

Contrarily, monitoring entails keeping an eye on and gauging the performance of your application in real time. When specific criteria are met, such as when the program takes too long to react or experiences an error, it can send warnings or notifications. Monitoring offers important insights for performance optimization and assists in identifying and resolving issues before they affect users.

There are well-known tools in ASP.NET Core, such as Microsoft.Extensions.Helping with logging include Serilog, NLog, and logging. These tools assist you in maintaining a robust and effective software system by making it simpler to handle and analyze the data that your application generates.

Additional Information
Logging in.NET Core allows you to monitor activity within your application. It aids in behavior monitoring, problem solving, and performance analysis. Logging is made organized and efficient with the help of the ILogger API. You can store logs in several locations using different logging providers; built-in and third-party choices are available.

Let's now discuss the distinctions between tracing and logging. The goal of logging is to capture important events in your program and produce a sort of summary. However, tracing goes beyond by providing you with an in-depth overview of all the actions taking place within your application, providing a comprehensive history of its operations.

The six main logging levels in .NET

• Critical: This is for really serious issues that could make your app stop working, like running out of memory or space on the disk.
• Error: Use this when something goes wrong, like a database error preventing data from being saved. The app can still work for other things despite encountering errors.
• Warning: Not as severe as errors, but it indicates a potential problem that might lead to more serious errors. It's a heads-up for administrators.
• Information: Gives details about what's happening in the app. Helpful for understanding the steps leading to an error.
• Debug: Useful during development for tracking detailed information. It's not typically used in a live/production environment.
• Trace: Similar to Debug but may include sensitive info. Rarely used and not utilized by framework libraries.

Implement the External Logging Source to Logging Information of API  and Windows Service - Serilog

Packages need: Serilog.AspNetCore

• Dot Net CLI - dotnet add package Serilog.AspNetCore --version 8.0.0
• Package Manager - Install-Package Serilog.AspNetCore -Version 8.0.0

Confiuration of Serilog in API
Settings File

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Serilog": {
    "Using": [ "Serilog.Sinks.File" ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "File",
        "Args": {
          "path": "C:/Log001/log_.log",
          "rollOnFileSizeLimit": true,
          "rollingInterval": "Day"
        }
      }
    ]
  }
}

Application Startup updates for Logging
using Serilog;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

/// Step 1
builder.Host.UseSerilog((context, configuration) =>
{
    configuration.ReadFrom.Configuration(context.Configuration);
}
);

var app = builder.Build();


/// Step 2
app.UseSerilogRequestLogging();

app.Run();

Using the setup to Log actions.
In this setup, we employ the "Assembly - Microsoft.Extensions.Logging.Abstractions, Version=8.0.0.0" for logging actions, and we utilize Serilog to write these logs into files. The ILogger interface is injected into the constructor to facilitate logging functionality.
private readonly ILogger<WeatherForecastController> _logger;

public WeatherForecastController(ILogger<WeatherForecastController> logger)
{
    _logger = logger;
}

[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    _logger.LogInformation("Method Entered");

    var list = Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
        TemperatureC = Random.Shared.Next(-20, 55),
        Summary = Summaries[Random.Shared.Next(Summaries.Length)]
    })
    .ToArray();

    string message = $"WeatherForecast Count {list.Length}";

    _logger.LogInformation(message);

    _logger.LogInformation("Method Exit");
    return list;
}

Now, to test the logging functionality, run the application and inspect the specified path. Refer to the image below for guidance.

Application Startup updates for Logging
using Serilog;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

/// Step 1
builder.Host.UseSerilog((context, configuration) =>
{
    configuration.ReadFrom.Configuration(context.Configuration);
}
);

var app = builder.Build();


/// Step 2
app.UseSerilogRequestLogging();

app.Run();

Using the setup to Log actions.

In this setup, we employ the "Assembly - Microsoft.Extensions.Logging.Abstractions, Version=8.0.0.0" for logging actions, and we utilize Serilog to write these logs into files. The ILogger interface is injected into the constructor to facilitate logging functionality.
private readonly ILogger<WeatherForecastController> _logger;

public WeatherForecastController(ILogger<WeatherForecastController> logger)
{
    _logger = logger;
}

[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    _logger.LogInformation("Method Entered");

    var list = Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
        TemperatureC = Random.Shared.Next(-20, 55),
        Summary = Summaries[Random.Shared.Next(Summaries.Length)]
    })
    .ToArray();

    string message = $"WeatherForecast Count {list.Length}";

    _logger.LogInformation(message);

    _logger.LogInformation("Method Exit");
    return list;
}

Now, to test the logging functionality, run the application and inspect the specified path. Refer to the image below for guidance.

We will learn how to construct and configure the splash screen in.NET MAUI in this tutorial. If you are new to.NET MAUI, I recommend that you read the articles in this series listed below. When you launch the program, a splash screen appears till the application initialization procedure is complete. The Splash screen is removed once the application is ready for usage.

Let's start by making a new.NET MAUI project to learn how to design or edit the Splash Screen. I've started a new project called SplashScreenExample.

When you run the program on an Android device, you will see the default Splash Screen, as shown in the image below.

A splash screen in.NET MAUI can be provided in a single location within the application. In the "ResourcesSplash folder," you will find a scalable vector graphic, splash.svg, with a build action of MauiSplashScreen in the settings box.

Scalable vector graphics have the advantage of being able to be adjusted to the suitable resolution for the target application. Let's swap out the splash screen icon for something new. I already have a medical icon that I will display on the Splash Screen. I removed the splash.svg icon and replaced it with the medical.svg image, with the build action MauiSplashScreen. Make sure the name of the icon you're adding to the Splash screen is lowercase, begins and finishes with a letter character, and only contains alphanumeric characters or underscore.

Now edit the .csproj file of the project as shown in the below image.

Add the BaseSize of a splash screen, which represents the image's baseline density. If no base size is supplied for the vector picture, the dimensions specified in the image are utilized as the base size. BaseSize is supplied using the BaseSize="W,H" syntax, where W is the image's width and H is its height. The BaseSize value supplied must be divisible by 8. In my case, BaseSize="128,128" is divisible by 8.

Use the TintColor property to modify the color of the SVG icon, and the Color property to adjust the backdrop color.

<!-- Images -->
<MauiSplashScreen Include="Resources\Splash\medical.svg" BaseSize="128,128" Color="#F5F7F8" TintColor="#BE3144"/>

Let's create and execute the app in the Android emulator now. You will notice that the Splash Screen with the medical.svg icon is displayed as per the MauiSplashScreen setup.

ASP.NET Core is a strong platform for building robust and scalable web applications. Middleware, which is essential in managing HTTP requests and responses, is one of its important characteristics. Middleware is a software component that lies between the client and the server, allowing developers to add additional logic to the request processing pipeline.

What exactly is middleware?
In the context of ASP.NET Core, middleware refers to a collection of components that are triggered in the request pipeline to handle requests and responses. Each middleware component receives an HTTP request, performs particular duties, and then either forwards the request or provides a response.

The Request Pipeline's Middleware
In ASP.NET Core, the request pipeline is made up of a series of middleware components. When the server receives a request, it passes it through this pipeline, and each middleware component can.

• Respond to the Request: Execute tasks such as logging, authentication, and authorization, among others.
• Process the Response: Make changes to the response before returning it to the client.

Developing Custom Middleware
ASP.NET Core custom middleware allows developers to add their own logic to the request processing pipeline. Here's a step-by-step tutorial on developing bespoke middleware.
using Microsoft.AspNetCore.Http;
using System.Threading.Tasks;

public class CustomMiddleware
{
    private readonly RequestDelegate _next;

    public CustomMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Logic before the next middleware
        await _next(context);
        // Logic after the next middleware
    }
}

Step 2: In Startup.cs, configure the Middleware
Add your custom middleware to Startup.cs's Configure function using the UseMiddleware extension method

public void Configure(IApplicationBuilder app)
{
    app.UseMiddleware<CustomMiddleware>();
    // Other middleware configurations
}

Step 3: Put Middleware Logic in Place
You can implement your required logic before and after invoking the next middleware in your custom middleware's InvokeAsync method. This can include authentication, logging, and altering requests/responses, among other things.

Custom Middleware Use Cases
Custom middleware can be used for a variety of applications, including.

• Authentication: Before forwarding the request to the application, implement custom authentication logic.
• Logging: For debugging purposes, log request details or errors.
• Caching: To boost application performance, use caching methods.
• Response Modification: Make changes to the response before returning it to the client.

Conclusion
In ASP.NET Core, middleware is a sophisticated framework that allows developers to alter the request pipeline. Creating custom middleware gives flexibility in processing requests and answers, allowing developers to smoothly integrate their own logic into the application flow. Developers may improve the functionality, performance, and security of their ASP.NET Core apps by understanding and exploiting middleware.

As the world of microservices evolved, so did the strategy and technologies that surrounded it. Communication across multiple services is one of the most critical components of microservices. Remote procedure calls are one method of communication that is employed, and gRPC provides a complex framework for it.

As the acronym suggests, gRPC stands for Google remote procedure call. It was the framework that Google utilized before opening it out to the open-source community. It employs the HTTP2 protocol.

It has a few advantages, such as.

• Messages that are brief
• It is quick
• It supports full-duplex communication

gRPC is generally used for internal service communication, however it does support web gRPC, which may be accessed via browsers.

Unlike RESTful services, the service signature and message property must be known by both the client and the server.

It offers versatility. Both the client and the server can be constructed in various technology stacks and still communicate effectively.

Now, begin building gRPC in.Net Core, but note that the.Net API project can have both Rest API and gRPC services, and in this tutorial, we will add gRPC to the already existing

RestFull API Project
For Rest API, I use Mediator and CQRS architecture, but you can use any technique.

Step 1: Make a Prototype file.

Now, define the RPC Service structure.

service EventCatalogService {
      rpc GetAllCategories(GetCategoriesRequest) returns (CategoriesResponse);
}

As we can see, the Name is GetAllCategories, the request it is taking is GetCategoriesRequest, and the Response is sending CategoriesResponse.

Now, Create the request and response messages for services.

message GetCategoriesRequest
{
}

message CategoriesResponse {
    repeated CategoryItem Categories = 1;
}

message CategoryItem {
    string CategoryId = 1;
    string Name = 2;
}

The repeated is defining the collection here.

You can see the number against each attribute defining the position of the attribute in the message. We can also reserve some position for future use.
syntax = "proto3";
option csharp_namespace = "EventCatalog.gRPC";

import "google/protobuf/timestamp.proto";

service EventCatalogService {
    rpc GetAllCategories(GetCategoriesRequest) returns (CategoriesResponse);
}

message GetCategoriesRequest {}

message EventByCategoryIdRequest {
    string CategoryId = 1;
}

message EventByEventIdRequest {
    string EventId = 1;
}

message EventByCategoryIdResponse {
    string EventId = 1;
    string Name = 2;
    int32 Price = 3;
    string Artist = 4;
    google.protobuf.Timestamp Date = 5;
    string Description = 6;
    string ImageUrl = 7;
    string CategoryId = 8;
    string CategoryName = 9;
}

message EventByEventIdResponse {
    string EventId = 1;
    string Name = 2;
    int32 Price = 3;
    string Artist = 4;
    google.protobuf.Timestamp Date = 5;
    string Description = 6;
    string ImageUrl = 7;
    string CategoryId = 8;
    string CategoryName = 9;
}

message CategoriesResponse {
    repeated CategoryItem Categories = 1;
}

message CategoryItem {
    string CategoryId = 1;
    string Name = 2;
}

The proto file is ready.

Step 2. Add gRPC to your .Net project
Add the proto file as a connected service.

Click on project connected service.

Now, create the grpc server by giving the proto file path.

It will include the proto file as well as other necessary Nuget packages in the project.

Step 3: Add the gRPC to your service layer
First, establish the gRPC service that will inherit the basic class of gRPC service, and then integrate your business layer into it. Because I'm using mediatr, I'll get the message from the gRPC service, pass it to my application layer, and then provide a response.

using EventCatalog.gRPC;

using FOA.Application.Mapper;

using Grpc.Core;

using MediatR;

using TicketManagement.Services.EventCatalog.Application.Feature.Category.Queries;

using static EventCatalog.gRPC.EventCatalogService;

namespace TicketManagement.Services.EventCatalog.RPCServices;

public class EventCatalogRPCService : EventCatalogServiceBase

{
    private readonly IMediator _mediator;
    public EventCatalogRPCService(IMediator mediator)
    {
        _mediator = mediator;
    }
    public override async Task<CategoriesResponse> GetAllCategories(GetCategoriesRequest request,ServerCallContext context)

    {
        var serviceResult = await _mediator.Send(new GetAllCategoriesRequest());
        var result =  gRPCMappers.Mapper.Map<List<CategoryItem>>(serviceResult);
        var response = new CategoriesResponse();
        response.Categories.AddRange(result);
        return response;

    }

}

Step 5. Add gRPC to your program.cs
// adding grpc

builder.Services.AddGrpc(cfg => cfg.EnableDetailedErrors = true);

After build, add the following line.
app.MapGrpcService<EventCatalogRPCService>();

Now the server is ready, we need a client to test it.

Step 6. Create gRPC Client
Create a new .Net API project and the Client gRPC through the connected service, but this time, instead of the server, select client.
As the client is only going to send and receive messages from the server, there will be not much code other than basic communication.
var channel = GrpcChannel.ForAddress(_serviceURL);
var client = new EventCatalogServiceClient(channel);
var request = new GetCategoriesRequest();
var response = client.GetAllCategories(request);

It is creating a channel through the service URL, which is the URL of our gRPC Server, and then creating a client through that channel and calling the service through that client.

Step 7. Add authorization to your service
So, adding security to your gRPC service is very easy. As the gRPC is added as a middleware to your application, the already implemented authentication or Authorization is already available to you.

You just need to add an Authorization tag to your service.
[Authorize]
public override async Task<CategoriesResponse> GetAllCategories(GetCategoriesRequest request,ServerCallContext context)
{
        var serviceResult = await _mediator.Send(new GetAllCategoriesRequest());
        var result =  gRPCMappers.Mapper.Map<List<CategoryItem>>(serviceResult);
        var response = new CategoriesResponse();
        response.Categories.AddRange(result);
        return response;

}

.NET MAUI is a powerful platform for building cross-platform mobile applications, and with the right tools and resources, it's easy to add barcode scanning functionality to your app. In this tutorial, we'll walk you through the steps of implementing a barcode scanner in .NET MAUI using the ZXing.Net.MAUI plugin.

Project Setup
Launch Visual Studio 2022, and in the start, window click Create a new project to create a new project.

In the Create a new project window, select MAUI in the All project types drop-down, select the .NET MAUI App template, and click the Next button.

In the configure your new project window, name your project, choose a suitable location for it, and click the Next button.  .Net MAUI - Zxing Barcode Scanner

In the Additional information window, click the Create button.

Once the project is created, we can able to see the Android, iOS, Windows, and other running options in the toolbar. Press the emulator or run button to build and run the app.

Implementation
The successor to ZXing.Net.Mobile: barcode scanning and generation for .NET MAUI applications. First, we need to add the ZXing.Net.MAUI library to our project as a dependency. To do this, open the NuGet Package Manager and search for "ZXing.Net.MAUI". Install the package in your .NET MAUI project.

Install ZXing.Net.MAUI
Install the ZXing.Net.MAUI NuGet package on your .NET MAUI application. Make sure to initialize the plugin first in your MauiProgram.cs, see below
// Add the using to the top
using ZXing.Net.Maui;
// ... other code
public static MauiApp Create() {
    var builder = MauiApp.CreateBuilder();
    builder.UseMauiApp & lt;
    App & gt;
    ().UseBarcodeReader(); // Make sure to add this line
    return builder.Build();
}

Now we just need to add the right permissions to our app metadata. Find below how to do that for each platform.

For Android go to your "AndroidManifest.xml" file (under the Platforms\Android folder) and add the following permissions inside of the "manifest" node.
<uses-permission android:name="android.permission.CAMERA" />

For iOS go to your "info.plist" file (under the Platforms\iOS folder) and add the following permissions inside of the "dict" node:
<key>NSCameraUsageDescription</key>
<string>This app uses barcode scanning to...</string>

Make sure that you enter a clear and valid reason for your app to access the camera. This description will be shown to the user.

Using ZXing.Net.Maui
If you're using the controls from XAML, make sure to add the right XML namespace in the root of your file, e.g:
xmlns:zxing="clr-namespace:ZXing.Net.Maui.Controls;assembly=ZXing.Net.MAUI"

<zxing:CameraBarcodeReaderView
  x:Name="cameraBarcodeReaderView"
  BarcodesDetected="BarcodesDetected" />

Full Code of MainPage.xaml
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:zxing="clr-namespace:ZXing.Net.Maui.Controls;assembly=ZXing.Net.MAUI"
             x:Class="MauiTutorial9.MainPage">
    <Grid>
        <zxing:CameraBarcodeReaderView
            Grid.Row="0"
            Grid.RowSpan="3"
            x:Name="barcodeView"
            BarcodesDetected="BarcodesDetected" />
        <Label Grid.Row="0"
               Text="Scan Barcode..."
               TextColor="White"
               FontSize="Subtitle"
               HorizontalOptions="Center"
               VerticalOptions="Center"/>
        <Label Grid.Row="2"
               Text=""
               x:Name="lbl"
               TextColor="White"
               FontSize="Subtitle"
               HorizontalOptions="Center"
               VerticalOptions="Center"/>
    </Grid>
</ContentPage>

Configure Reader options
cameraBarcodeReaderView.Options = new BarcodeReaderOptions {
    Formats = BarcodeFormats.OneDimensional,
        AutoRotate = true,
        Multiple = true
};

Toggle Torch
cameraBarcodeReaderView.IsTorchOn = !cameraBarcodeReaderView.IsTorchOn;

Flip between the Rear/Front cameras
cameraBarcodeReaderView.CameraLocation
  = cameraBarcodeReaderView.CameraLocation == CameraLocation.Rear ? CameraLocation.Front : CameraLocation.Rear;

Handle detected barcode(s)
protected void BarcodesDetected(object sender, BarcodeDetectionEventArgs e) {
    foreach(var barcode in e.Results)
    Console.WriteLine($ "Barcodes: {barcode.Format} -> {barcode.Value}");
}

Full code of MainPage.xaml.cs
using ZXing.Net.Maui;
namespace MauiTutorial9;
public partial class MainPage: ContentPage {
    public MainPage() {
        InitializeComponent();
    }
    protected void BarcodesDetected(object sender, BarcodeDetectionEventArgs e) {
        MainThread.BeginInvokeOnMainThread(() => {
            lbl.Text = $ "{e.Results[0].Format}->{e.Results[0].Format}";
            barcodeView.IsDetecting = false;
        });
    }
}

Demo

Full Code
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:zxing="clr-namespace:ZXing.Net.Maui.Controls;assembly=ZXing.Net.MAUI"
             x:Class="MauiTutorial9.MainPage">
    <Grid>
        <zxing:CameraBarcodeReaderView
            Grid.Row="0"
            Grid.RowSpan="3"
            x:Name="barcodeView"
            BarcodesDetected="BarcodesDetected" />
        <Label Grid.Row="0"
               Text="Scan Barcode..."
               TextColor="White"
               FontSize="Subtitle"
               HorizontalOptions="Center"
               VerticalOptions="Center"/>
        <Label Grid.Row="2"
               Text=""
               x:Name="lbl"
               TextColor="White"
               FontSize="Subtitle"
               HorizontalOptions="Center"
               VerticalOptions="Center"/>
    </Grid>
</ContentPage>

using ZXing.Net.Maui;
namespace MauiTutorial9;
public partial class MainPage: ContentPage {
    public MainPage() {
        InitializeComponent();
    }
    protected void BarcodesDetected(object sender, BarcodeDetectionEventArgs e) {
        MainThread.BeginInvokeOnMainThread(() => {
            lbl.Text = $ "{e.Results[0].Format}->{e.Results[0].Format}";
            barcodeView.IsDetecting = false;
        });
    }
}

Download Code
You can download the code from GitHub. If you have any doubts, feel free to post a comment. If you liked this article, and it is useful to you, do like, share the article & star the repository on GitHub.

Are you sick of hearing the term "Dependency Injection" and immediately visualizing complex web apps with flashy user interfaces? You're in for a treat, my fellow developers, because this post will show you how to use Dependency Injection in terminal apps!

"Console apps?" you might be wondering. Isn't that just for basic command-line utilities?" But wait a minute. Your basic console app can benefit from the same power and flexibility that ASP.NET Core developers have for their web applications thanks to Dependecy Injection. Doesn't it sound good? Let's get started and explore how we can make even the most basic console apps flexible and testable.

In this article, I'll walk you through the process of creating a basic console app with a ServiceCollection that any ASP.NET Core developer would recognize.

Adding NuGet packages
You must install the Microsoft.Extensions package.In your console program, include the DependencyInjection package.

Using the.NET CLI
dotnet package addition Microsoft.Extensions.Using Visual Studio to Implement Dependency Injection

Starting with Program.cs
When you first start a console app, the boilerplate code will include a Main method that prints "Hello, World!" to the console. Inside this method, we'll remove the Console.WriteLine() method and put up our own programs. My preference is to build a new class called "Application" in which my app's logic will reside. Then, Program.cs just bootstraps the Application class with dependency injection.

using Microsoft.Extensions.DependencyInjection
namespace MyApp
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            var services = CreateServices();

            Application app = services.GetRequiredService<Application>();
            app.MyLogic();
        }

        private static ServiceProvider CreateServices()
        {
            var serviceProvider = new ServiceCollection()
                .AddSingleton<Application>(new Application())
                .BuildServiceProvider();

            return serviceProvider;
        }
    }

    public class Application
    {
        public void MyLogic()
        {
            // Do something epic
        }
    }
}

Let's take a look at what's going on. On line 9, we set a ServiceProvider variable, which is the output of the CreateServices() function. We register a single service in the collection using this way. Because we'll be passing application flow to the Application class, a singleton instance is the best choice.

Line 11 begins the application logic by using the dependency injection container to resolve our singleton. In the Application class, you might wish to have a method called "Start", "Initialize", or something similar.

Following steps
This structure provides us with a versatile basis on which to build. In the following sections, we'll look at how we can enhance this and add certain components that you'll most likely want in your advanced console app.

Making Use of EF Core
When we install EF Core, we usually have to retrieve the connection string from IConfiguration, add our database context to the DI container, and perhaps run EF migrations when the application starts. Let's see how we can do this.

Add NuGet packages
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
dotnet add package Microsoft.Configuration.UserSecrets

Modifications to Program.cs
Don't forget about the new using statements that allow us to interact with EF Core and IConfiguration! There are two significant modifications to be aware of.

• An IConfiguration is produced in CreateServices, and for demonstration purposes, I'm assuming my connection string is saved in my User Secrets file. The MyDbContext class is now registered to the ServiceCollection. Again, I'm using the Sqlite service for demonstration purposes.
• Before beginning my Application class in the Main function, we request an instance of MyDbContext to perform database migrations. This ensures that when the logic of our app begins, the database is in the correct condition.

using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection

namespace MyApp
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            var services = CreateServices();

            MyDbContext context = services.GetRequiredService<MyDbContext>();
            context.Database.Migrate();

            Application app = services.GetRequiredService<Application>();
            app.MyLogic();
        }

        private static ServiceProvider CreateServices()
        {
            var configuration = new ConfigurationBuilder()
                .AddUserSecrets(Assembly.GetExecutingAssembly())
                .Build();

            string connectionString = configuration.GetConnectionString("MyApp");

            var serviceProvider = new ServiceCollection()
                .AddDbContext<MyDbContext>(options =>
                {
                    options.UseSqlite(connectionString);
                })
                .AddSingleton<Application>(new Application())
                .BuildServiceProvider();

            return serviceProvider;
        }
    }

    public class Application
    {
        public void MyLogic()
        {
            // Do something epic
        }
    }
}

ILogger is used for logging
Another popular component you may want to include in your console app is modern logging to replace all of those Console.WriteLine methods are used. We'll utilize the console logging provider as an example.

Add NuGet packages
dotnet add package Microsoft.Extensions.Logging.Console

Changes to Program.cs
On line 20, we're telling the dependency injection container that we're adding logging support. This comes from the using statement of Microsoft.Extensions.Logging. Then, I've modified the Application class so its constructor will receive an instance of ILogger which will come from our configured DI container. Take notice of how nothing needed to be changed on line 13 and 14. This is because our DI container will give us our configured singleton of Application, now with the ILogger<Application> included!

using System;
using Microsoft.Extensions.DependencyInjection
using Microsoft.Extensions.Logging;

namespace MyApp
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            var services = CreateServices();

            Application app = services.GetRequiredService<Application>();
            app.MyLogic();
        }

        private static ServiceProvider CreateServices()
        {
            var serviceProvider = new ServiceCollection()
                .AddLogging(options =>
                {
                    options.ClearProviders();
                    options.AddConsole();
                })
                .AddSingleton<Application>(new Application())
                .BuildServiceProvider();

            return serviceProvider;
        }
    }

    public class Application
    {
        private readonly ILogger<Application> _logger;

        public Application(ILogger<Application> logger)
        {
            _logger = logger;
        }

        public void MyLogic()
        {
            _logger.LogInformation("Hello, World!");
        }
    }
}