DEV Community: Rohit Cdy

Advanced Optimization Techniques for High-Performance Angular Applications.

Rohit Cdy — Fri, 31 Jan 2025 11:17:49 +0000

Angular is a powerful framework for building dynamic web applications, but as your app grows, performance issues can arise. Optimizing your Angular application ensures a better user experience, faster load times, and smoother interactions. Here are some essential tips to enhance the performance of your Angular application.

1. Use OnPush Change Detection Strategy

By default, Angular has a Default change detection strategy that checks all components for changes, even when there is no need. Changing it to OnPush will make Angular check the component only when its input properties change, which can significantly boost performance.

@Component({
selector: 'app-example',
templateUrl: './example.component.html',
changeDetection: ChangeDetectionStrategy.OnPush
})
export class ExampleComponent {
@Input() data: any;
}

2. Lazy Load Modules

Lazy loading loads modules only when they are required, reducing the initial bundle size and improving load times.

const routes: Routes = [
{ path: 'feature', loadChildren: () => import('./feature/feature.module').then(m => m.FeatureModule) }
];

3. Use Ahead-of-Time (AOT) Compilation

AOT compiles your Angular templates at build time rather than runtime, resulting in faster rendering and smaller bundle sizes. Enable AOT compilation in angular.json:

"angularCompilerOptions": {
"enableIvy": true
}

4. Minimize Bundle Size

Analyze and reduce your application's bundle size by using tools like webpack-bundle-analyzer. Remove unnecessary dependencies and also perform tree shaking to eliminate unused code.

npm install -g webpack-bundle-analyzer
ng build --prod --stats-json
webpack-bundle-analyzer dist/stats.json

5. Optimize DOM Manipulation with TrackBy in ngFor

Using trackBy improves performance by reducing DOM manipulations when updating lists.

trackByFn(index, item) {
return item.id;
}

6. Use Server-Side Rendering (SSR) with Angular Universal

SSR enhances performance by rendering pages on the server, thus reducing the time it takes for users to load pages.

ng add @nguniversal/express-engine

7. Minimize HTTP Requests by Implementing Caching

Caching responses from APIs avoid redundant requests, hence improving application performance.

this.http.get(url).pipe(shareReplay(1));

8. Optimize Images and Assets

Compressed images, lazy loading of images, and serving static assets efficiently.

9. Enable Production Mode

Always ensure your Angular application is running in production mode to enable optimizations.

if (environment.production) {
enableProdMode();
}

10. Use Web Workers for Heavy Tasks

Offload expensive computations to web workers to avoid blocking the main thread.

const worker = new Worker(new URL('./app.worker', import.meta.url));

Conclusion

The implementation of these optimization techniques will definitely improve the performance of your Angular application, making it much faster and efficient. Profiling and monitoring regularly will keep your app responsive and scalable.

This will enable you to deliver the best experience for your users and maintain a performance-optimized Angular application.

Mastering Angular Routing & Guards: Secure and Seamless Navigation!

Rohit Cdy — Fri, 31 Jan 2025 10:37:22 +0000

In an SPA, Angular routing is basically the functionality allowing users to travel between various parts of your app. At that point, the route guards, which will make navigation smarter and more secure.

Why Would We need Angular Guard Protection?

Block Access: Let unauthorized users have no access to the routes you select.
Role-Based Access Control: Grant or deny access according to user roles.
Avoid Unsaved Data Loss: Prompt the user for unsaved changes when navigating away from the page.
Preloading of Data Before Navigation: Load data needed before a component is routed in.
Lazy Loading Optimization: Manage lazy loading of modules efficiently.

Types of Route Guards in Angular

There are five different types of route guards in Angular:

canActivate: Checks whether the user can go to a certain route.
canActivateChild: Determines whether users should be able to reach child routes.
canDeactivate: Prevents users from leaving a route unless they meet some condition.
resolve: It pre-loads data ahead of the route's activation.
canLoad: Disallows loading of lazy-loaded modules if the condition is not met.

How to Use Route Guards in Angular

1. `canActivate` - Block Access

This guard prevents unauthorized access to certain routes.

Implementation:

import { Injectable } from '@angular/core';
import { CanActivate, Router } from '@angular/router';

@Injectable({ providedIn: 'root' })
export class AuthGuard implements CanActivate {
  constructor(private router: Router) {}

  canActivate(): boolean {
    const isAuthenticated =!!localStorage.getItem('token');
    if (!isAuthenticated) {
      this.router.navigate(['/login']);
      return false;
    }
return true;
  }
}

Usage:

{ path: 'dashboard', component: DashboardComponent, canActivate: [AuthGuard] }

2. `canActivateChild` - Protect Child Routes

This guard restricts access to child routes just like canActivate does for parent routes.

Implementation:

import { Injectable } from '@angular/core';
import { CanActivateChild, Router } from '@angular/router';

@Injectable({ providedIn: 'root' })
export class ChildAuthGuard implements CanActivateChild {
  constructor(private router: Router) {}

  canActivateChild(): boolean {
const hasPermission =!!localStorage.getItem('admin');
    if (!hasPermission) {
      this.router.navigate(['/']);
      return false;
    }
    return true;
  }
}

Usage:

{
  path: 'admin',
  component: AdminComponent,
  canActivateChild: [ChildAuthGuard],
  children: [
    { path: 'users', component: UsersComponent },
    { path: 'settings', component: SettingsComponent }]
}

3. `canDeactivate` - Prevent Accidental Data Loss

This guard prevents the user from navigating away from a certain component if there are unsaved changes.

Solution:

import { Injectable } from '@angular/core';
import { CanDeactivate } from '@angular/router';
import { Observable } from 'rxjs';

export interface CanComponentDeactivate {
  canDeactivate: () => Observable<boolean> | Promise<boolean> | boolean;
}

@Injectable({ providedIn: 'root' })
export class CanLeaveGuard implements CanDeactivate<CanComponentDeactivate> {
  canDeactivate(component: CanComponentDeactivate): boolean {
return component.canDeactivate? component.canDeactivate() : true;
  }
}

Component Implementation:

import { Component } from '@angular/core';
import { CanComponentDeactivate } from './guards/can-leave.guard';

@Component({
  selector: 'app-profile',
  templateUrl: './profile.component.html'
})
export class ProfileComponent implements CanComponentDeactivate {
  unsavedChanges = true;

  canDeactivate(): boolean {
    return this.unsavedChanges? confirm('You have unsaved changes. Leave anyway?') : true;
  }
}

Usage:

{ path: 'profile', component: ProfileComponent, canDeactivate: [CanLeaveGuard] }

4. `resolve` - Fetch Data Before Route Activation

This ensures that data are fetched before the route is activated.

Implementation:

import { Injectable } from '@angular/core';
import { Resolve } from '@angular/router';
import { Observable, of } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class UserResolver implements Resolve<any> {
  resolve(): Observable<any> {
    return of({ name: 'John Doe', age: 30 }); // Example API call
  }
}

Usage:

{ path: 'user', component: UserComponent, resolve: { userData: UserResolver } }

How to access resolved data in Component:

import { ActivatedRoute } from '@angular/router';

constructor(private route: ActivatedRoute) {}

ngOnInit() {
  const user = this.route.snapshot.data['userData'];
  console.log(user);
}

5. `canLoad` - Blocking Lazy Module Loading

This guard prevents lazy-loaded modules to be loaded in case conditions aren't met.

Implementation:

import { Injectable } from '@angular/core';
import { CanLoad, Route, UrlSegment, Router } from '@angular/router';

@Injectable({ providedIn: 'root' })
export class AdminLoadGuard implements CanLoad {
  constructor(private router: Router) {}

  canLoad(route: Route, segments: UrlSegment[]): boolean {
    const isAdmin =!!localStorage.getItem('admin');
    if (!isAdmin) {
      this.router.navigate(['/']);
      return false;
    }
    return true;
  }
}

Usage:

{ path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule), canLoad: [AdminLoadGuard] }

Conclusion

Route guards in Angular play a great role in route protection, navigation control, and optimization of performance. You will efficiently manage your users' access and data flow within your applications by implementing the different guards of canActivate, canActivateChild, canDeactivate, resolve, and canLoad.

Advanced implementation of Licensing Validation in angular applications.

Rohit Cdy — Tue, 28 Jan 2025 08:16:27 +0000

Licensing validation is any application's most important feature, allowing only authorized users to access its functionalities. In an Angular application, the licensing validation normally takes place by the following:

The Angular app is loaded.
The licensing information is fetched from a backend API or local storage.
The licensing data is validated.

That does the job but there's more grace in doing a license check without loading up the Angular application first. Using what's called an AppInitializer in Angular.

What is AppInitializer in Angular?

The AppInitializer is a special Angular provider for running some code before Angular has fully initialized the application. It's used everywhere when one needs for example:

Loading settings.
Services initialization.

We can use AppInitializer for license validation so that the application checks for a license before it loads up, adding to both security and user experience.

How to Use AppInitializer for Licensing Validation in Angular

Here's how you can validate licensing using AppInitializer in Angular:

1. Create a License Service

The logic for validation will be carried out by the license service. This may call a license data from the local storage or from an external server. The implementation may look like this.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class LicenseService {
  constructor(private http: HttpClient) {}

  validateLicense(): Observable<boolean> {
this.licenseService.validateLicense('/api/validate-license').subscribe(
  success => {
    if (!success) {
      alert('Invalid License!');
      // You can redirect or stop the app from initializing
    }
  },
  error => {
    alert('License validation failed!');
  }
);
  }
}

Implement the AppInitializer Function The AppInitializer function will make sure to validate the license before the app starts. It calls the LicenseService's validateLicense method and waits for the result.

import { LicenseService } from './license.service';
import { APP_INITIALIZER } from '@angular/core';

export function licenseInitializer(licenseService: LicenseService) {
  return () => {
    return licenseService.validateLicense().toPromise().catch(() => {
      alert('Invalid or missing license!');
      // Handle invalid license (e.g., redirect or block app initialization)
      return Promise.reject();
    });
  };
}

3. Provide the AppInitializer in the AppModule

By providing APP_INITIALIZER in the AppModule, the app will wait for the license validation to complete before proceeding to load.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { LicenseService } from './license.service';
import { licenseInitializer } from './app-initializer';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, HttpClientModule],
  providers: [
    {
      provide: APP_INITIALIZER,
      useFactory: licenseInitializer,
      deps: [LicenseService],
      multi: true
    }
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

4. Handle Invalid License

In the case of an invalid license or no license, the AppInitializer can prevent the app from loading and inform the user. You may want to show an alert or navigate the user to a license activation page.

Why AppInitializer for Licensing?

Using AppInitializer to validate licenses has several advantages:

Avoids Unauthorized Access: Because the app will only load if the license is valid.
Enhanced Security: The validation occurs before any application logic is executed.
Enhanced User Experience: Provides appropriate messaging for invalid licenses without partially loading the app.
Centralized Logic: All initialization tasks, including licensing, can be handled in a clean and organized manner.

Conclusion

AppInitializer in Angular provides a very handy way to perform some crucial operations before the application is fully loaded. It can be combined with license validation to further increase the security, reliability, and user experience of your application. The approach will provide you with certainty that only valid users will access your application's features, which equals peace of mind for both you and the users.

Third-party API Integration using ASP.Net Core web API.

Rohit Cdy — Sat, 16 Mar 2024 12:48:56 +0000

Third-party API integration guidelines

Identify the API

Read their documentation thoroughly and understand its features, authentication requirements, and request and response formats.

Create a Separate Service

Create a separate service or class to encapsulate the logic related to the third-party API integration. This will help to keep the code organized and maintainable.

Add necessary dependencies

If the third-party API requires additional dependencies or SDKs, install them using NuGet packages in our ASP.Net Core Web API.

Handle authentication

Determine the authentication mechanism required by the third-party API. Implement the necessary authentication logic in our service. Store any sensitive information such as API keys or secrets in a secure configuration store, like environment variables.

Make HTTP Requests

Use the HttpClient class in ASP.NET Core to send HTTP requests to the third-party API. Construct the request payload and headers according to the API documentation. You can use the System.Net.Http namespace for this purpose.

Handle Responses

Handle the responses from the third-party API by parsing the returned data according to the API documentation. If needed, map the response data to your domain models or DTOs (Data Transfer Objects).

Error handling

Implement error handling logic to handle any exceptions or error responses from the third-party API. Consider implementing retries for temporary failures or rate-limited scenarios. You can use policies provided by libraries like Polly to handle retries and transient errors.

Caching and rate limiting

If the third-party API has rate limits or if you want to optimize performance, consider implementing caching mechanisms to store and reuse API responses. Caching can be done using an in-memory cache or distributed cache options like Redis.

Unit Testing

Write unit tests for your service to ensure that the integration with the third-party API works as expected. You can use mocking frameworks like Moq to mock the API responses and test various scenarios.

Logging and Monitoring

Implement logging to record any important events, errors, or debug information related to the integration with the third-party API. Consider using a logging framework like Serilog or the built-in logging capabilities of ASP.NET Core. Additionally, you can monitor API usage and performance using tools like Application Insights.

These are the guidelines for third-party API integration.
I will provide code implementation in the next part.

Implementing Soft Delete With EF Core.

Rohit Cdy — Sat, 16 Mar 2024 08:21:09 +0000

What is soft delete?

Prevents permanent deletion of records.
Flag set on record, indicating "delete".
Allows for easy restoration and maintains data integrity.

How to implement:

Create Marker Interface.

Define a marker interface ISoftDelete to mark entities that support soft delete.

public interface ISoftDelete
{
    bool IsDeleted { get; set; }
    DateTime? DeleteOnUtc { get; set; }
}

Implement Soft Delete Interceptor.

Create a class SoftDeleteInterceptor to handle soft deletes in EF Core.

public sealed class SoftDeleteInterceptor: SaveChangesInterceptor
{
    public override ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData,
        InterceptionResult<int> result,
        CancellationToken cancellationToken = default)
    {
        if (eventData.Context is null)
        {
            return base.SavingChangesAsync(eventData, result, cancellationToken);
        }

        IEnumerable<EntityEntry<ISoftDeletable>> entries =
            eventData.Context.ChangeTracker.Entries<ISoftDeletable>()
                .Where(e => e.State == EntityState.Deleted);

        foreach (EntityEntry<ISoftDeletable> softDeletable in entries)
        {
            softDeletable.State = EntityState.Modified;
            softDeletable.Entity.IsDeleted = true;
            softDeletable.Entity.DeletedOnUtc = DateTime.UtcNow;
        }

        return base.SavingChangesAsync(eventData, result, cancellationToken);
    }
}

Configure Application Context.

Configure EF Core to use the soft delete interceptor and global query filters.

public class ApplicationDbContext: DbContext
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }

    public DbSet<User> Users { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        // HasQueryFilter is used to filter soft-deleted data automatically.
        modelBuilder.Entity<User>().HasQueryFilter(r => !r.IsDeleted);

        modelBuilder.Entity<User>()
        .HasIndex(r=> r.IsDeleted)
        .HasFilter("IsDeleted=0");

        // This HasFilter method accepts the SQL filter for records that will be 
            included in the index.
        // You can also create a filtered index using SQL:
         /*
           Create index IX_Users_IsDeleted on User(IsDeleted) where IsDelete =0;
         */
    }
}

Register SoftDeleteIntercepter with dependency injection.

services.AddSingleton<SoftDeleteInterceptor>();
services.AddDbContext<ApplicationDbContext>(
    sp, options)=>options
        .UseSqlServer(connectionString)
        .AddInterceptor(
               sp.GetRequiredService<SoftDeleteInterceptor>()));

Example Entity.

Create an example entity Review implementing the soft delete marker interface.

public class User: ISoftDeletable
{
    public int Id { get; set; }
    public string UserName { get; set; }
    public bool IsDeleted { get; set; }
    public DateTime? DeletedOnUtc { get; set; }
}

Benefits:

Flexibility in managing data.
Simplified queries with automatic exclusion of soft-deleted records.
Improved performance with filtered indexes.

Conclusion

Soft delete ensures data integrity and flexibility in managing records without compromising performance.

Prototype Design Pattern in C#

Rohit Cdy — Sat, 24 Feb 2024 13:37:30 +0000

Introduction
The Prototype design pattern is a creation design pattern that specifies creating new objects by copying an existing object, thus avoiding the need to create new classes. This pattern allows us to clone existing objects, creating new instances with the same data. Any changes made to the cloned object do not affect the original object. It’s especially handy when the cost of creating an object is more expensive or complex than copying an existing one.

Example to Understand Prototype Design Pattern
Let’s illustrate this with a simple example. Suppose we have an Employee class with properties like Name and Department. When we copy one employee object to another using the assignment operator (=), both objects share the same memory address. However, we want to create a new object without affecting the original. Here’s how you can achieve that:

using System;

namespace PrototypeDesignPattern
{
    class Employee
    {
        public string Name { get; set; }
        public string Department { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            // Create an instance of Employee
            var emp1 = new Employee { Name = "John", Department = "HR" };

            // Create another employee instance by assigning the existing one
            var emp2 = emp1;

            // Change the Name property of emp2
            emp2.Name = "Alice";

            // Both emp1 and emp2 share the same memory
            Console.WriteLine($"Employee 1: {emp1.Name}, {emp1.Department}");
            Console.WriteLine($"Employee 2: {emp2.Name}, {emp2.Department}");
        }
    }
}

In the above example, modifying emp2 also affects emp1 because they share the same memory. However, the Prototype Design Pattern allows us to create a new object without this shared reference.

When to Use Prototype Design Pattern?
The Prototype Design Pattern is particularly useful in scenarios where:

Object creation is costly in terms of resources and time.
You have an existing object similar to the one needed.

Real-Time Example of Prototype Design Pattern
In real-world scenarios, the Prototype Design Pattern is frequently used in game development. It allows instantiating multiple instances of game entities without the overhead of constructing each one from scratch.

Remember, the Prototype Design Pattern provides a way to create new or cloned objects from existing ones, making it a powerful tool for efficient object creation.

Factory Method Design Pattern in C#

Rohit Cdy — Sat, 24 Feb 2024 13:19:05 +0000

Introduction

The Factory Method Design Pattern is a creational design pattern that allows us to create objects without exposing the creation logic to the client. It provides a way to create objects based on input parameters and returns them using a common interface.

Real-Time Example
Suppose we’re building an application to display Credit Card Details. We have three credit card classes: MoneyBack, Titanium, and Platinum, all of which are subclasses of the CreditCard superclass (or super interface). Each credit card class implements methods like GetCardType, GetCreditLimit, and GetAnnualCharge.

Our task is to ask the user to select a credit card type. Based on their choice, we need to display relevant information about the selected credit card.

Example Without Using the Factory Pattern
Let’s first see how we might approach this without using the Factory Design Pattern:

// Without Factory Pattern
class Program
{
    static void Main()
    {
        // User selects a credit card type (e.g., "MoneyBack")
        string userChoice = GetUserInput();

        // Create an instance based on user choice
        CreditCard card;
        if (userChoice == "MoneyBack")
            card = new MoneyBack();
        else if (userChoice == "Titanium")
            card = new Titanium();
        else if (userChoice == "Platinum")
            card = new Platinum();
        else
            throw new ArgumentException("Invalid choice");

        // Display credit card details
        Console.WriteLine($"Card Type: {card.GetCardType()}");
        Console.WriteLine($"Credit Limit: {card.GetCreditLimit()}");
        Console.WriteLine($"Annual Charge: {card.GetAnnualCharge()}");
    }

    // Other methods...
}

Problems Without Factory Pattern
Tight Coupling: The client code is tightly coupled to specific credit card classes.
Maintenance Challenges: Adding new credit card types requires modifying the client code.
Testing Complexity: Unit testing becomes difficult due to direct dependencies on concrete classes.

Implementing the Factory Design Pattern
Now let’s use the Factory Design Pattern to address these issues:

// With Factory Pattern
class Program
{
    static void Main()
    {
        // User selects a credit card type (e.g., "MoneyBack")
        string userChoice = GetUserInput();

        // Create a credit card factory
        CreditCardFactory factory = new CreditCardFactory();

        // Get the appropriate credit card object
        CreditCard card = factory.CreateCreditCard(userChoice);

        // Display credit card details
        Console.WriteLine($"Card Type: {card.GetCardType()}");
        Console.WriteLine($"Credit Limit: {card.GetCreditLimit()}");
        Console.WriteLine($"Annual Charge: {card.GetAnnualCharge()}");
    }

    // Other methods...
}

// Factory class
class CreditCardFactory
{
    public CreditCard CreateCreditCard(string type)
    {
        switch (type)
        {
            case "MoneyBack":
                return new MoneyBack();
            case "Titanium":
                return new Titanium();
            case "Platinum":
                return new Platinum();
            default:
                throw new ArgumentException("Invalid choice");
        }
    }
}

// Credit card superclass
interface CreditCard
{
    string GetCardType();
    decimal GetCreditLimit();
    decimal GetAnnualCharge();
}

// Concrete credit card classes
class MoneyBack : CreditCard { /* Implementation */ }
class Titanium : CreditCard { /* Implementation */ }
class Platinum : CreditCard { /* Implementation */ }

Summary
The Factory Design Pattern provides flexibility, separation of concerns, and better maintainability. It allows us to create objects dynamically based on input parameters, without exposing the creation logic to the client. Choose the Factory Pattern when you need to create objects with varying behavior or when you want to promote loose coupling between client code and concrete classes

Repository Pattern Vs Entity Framework

Rohit Cdy — Sat, 24 Feb 2024 11:06:12 +0000

The "Repository Pattern Vs Entity Framework" is indeed a topic of debate among software developers, and there isn't a definitive answer that applies universally to all scenarios. Different developers and teams may have different preferences and experiences that influence their perspective on this matter.

The choice between the Repository Pattern and Entity Framework often depends on various factors, including the project's requirements, complexity, team expertise, existing infrastructure, and personal preferences.

Some developers prefer the Repository Pattern because it provides clear separation between the application's business logic and the database access layer, making it easier to test, maintain and switch between different data sources. It also allows for more flexibility and customization, as developer have full control over the repository implementations.

Lets see with and sample C# code:

// User model representing a user entity in the application
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

// UserRepository interface defining the contract for interacting with user data
public interface IUserRepository
{
    User GetById(int userId);
    User GetByEmail(string email);
    void Save(User user);
}

// Concrete implementation of the UserRepository interface using a relational database
public class DatabaseUserRepository : IUserRepository
{
    public User GetById(int userId)
    {
        // Database query to fetch user by id
        // ...
    }

    public User GetByEmail(string email)
    {
        // Database query to fetch user by email
        // ...
    }

    public void Save(User user)
    {
        // Database query to save the user
        // ...
    }
}

// Concrete implementation of the UserRepository interface using an external API
public class ExternalAPIUserRepository : IUserRepository
{
    public User GetById(int userId)
    {
        // API call to fetch user by id
        // ...
    }

    public User GetByEmail(string email)
    {
        // API call to fetch user by email
        // ...
    }

    public void Save(User user)
    {
        // API call to save the user
        // ...
    }
}

// Service layer or business logic layer using the UserRepository interface
public class UserService
{
    private readonly IUserRepository userRepository;

    public UserService(IUserRepository userRepository)
    {
        this.userRepository = userRepository;
    }

    public void CreateUser(string name, string email)
    {
        // Create a new user instance
        var user = new User { Name = name, Email = email };

        // Save the user using the repository
        userRepository.Save(user);
    }

    public User GetUserById(int userId)
    {
        // Fetch the user by id using the repository
        return userRepository.GetById(userId);
    }

    public User GetUserByEmail(string email)
    {
        // Fetch the user by email using the repository
        return userRepository.GetByEmail(email);
    }
}

In above code we can see that, the business logic layer is represented by the "UserService" class. It contains the method such as "CreateUser", "GetUserById" and "GetUserByEmail" that encapsulate the application's specific logic for creating users and retriving users based on different criteria.

The data access layer is seperated into the repository interfaces "IUserRepositoty" and their concrete implementations "DatabaseUserRepositoty" and "ExternalAPIUserRepository". These classes handle the actual interaction with the underling datasources, such as a relational database or an external API.

Now let's discuss how this code structure makes it easier to test, maintain and switch between different data sources.

Lets write a test.

[TestFixture]
public class UserServiceTests
{
    [Test]
    public void CreateUser_Should_Save_User_Using_Repository()
    {
        // Arrange
        Mock<IUserRepository> userRepositoryMock = new Mock<IUserRepository>();
        UserService userService = new UserService(userRepositoryMock.Object);
        string name = "Rohit Chaudhary";
        string email = "rohit@chaudhary.com";

        // Act
        userService.CreateUser(name, email);

        // Assert
        userRepositoryMock.Verify(repo => repo.Save(It.Is<User>(user => user.Name == name && user.Email == email)), Times.Once);
    }

    // Similar tests for other methods of UserService
}

Here, the business logic UserService depends on abstractions IUserRepository interface instead of concrete implementations. This allows for easier testing, as you can create mock implementations of the repositoty interface to isolate the business logic from the actual data storage.

Now suppose we want to switch from using a database repository to an API repository. We can simply create a new concrete implementation of the IUserRepository interface for the API repository, inject it into the UserService class, and business logic remains the same.
Here is an example:

// Concrete implementation of the UserRepository interface using an API
public class APIUserRepository : IUserRepository
{
    public User GetById(int userId)
    {
        // API call to fetch user by id
        // ...
    }

    public User GetByEmail(string email)
    {
        // API call to fetch user by email
        // ...
    }

    public void Save(User user)
    {
        // API call to save the user
        // ...
    }
}

// Switching to API repository
IUserRepository userRepository = new APIUserRepository();
UserService userService = new UserService(userRepository);

// Now, the UserService can seamlessly work with the API repository without any changes to its methods.

From above explanation we can conclude that, it gives the flexibility to adopt to changing requirements and incorporate different data sources based on our needs.

By utilizing the Repository Pattern, the above provided code structure enhances testability, maintainability, and flexibility in the following ways:

The business logic is decoupled from the data access layer, enabling easier testing and isolation of the business logic.
Changes in the data access layer can be made without affecting the business logic, leading easier maintenance.
Switching between different data sources becomes simpler by creating new concrete implementation of repository interfaces, allowing for seamless integration with different data storage technologies or APIs.

While the Repository Pattern offers clear benefits in terms of flexibility and separation of concerns, it's also worth considering the advantages of using Entity Framework (EF) as an alternative approach to data access.

Entity Framework is an Object-Relational Mapping (ORM) framework provided by Microsoft, which simplifies the interaction between the application and the database by allowing developers to work with database entities as .NET objects directly.
Here are some reasons why you might choose Entity Framework over the Repository Pattern:

Rapid Development: Entity Framework allows developers to quickly scaffold database models from existing databases or code-first approaches, reducing the amount of boilerplate code needed for data access.
LINQ Support: Entity Framework provides robust support for Language Integrated Query (LINQ), allowing developers to write queries using familiar C# syntax, which can lead to more concise and readable code.
Automatic Change Tracking: Entity Framework automatically tracks changes to entities, making it easier to manage updates and ensure data consistency without manually writing CRUD operations.
Optimized Queries: Entity Framework generates optimized SQL queries based on LINQ expressions, helping to improve performance and reduce the risk of SQL injection attacks.
Integration with Other Microsoft Technologies: Entity Framework integrates seamlessly with other Microsoft technologies such as ASP.NET Core, making it a natural choice for developers working in the Microsoft ecosystem.
Maturity and Community Support: Entity Framework has been around for many years and has a large community of users, which means there are plenty of resources, tutorials, and third-party libraries available to support development efforts.

Here's how the UserService class might look if implemented using Entity Framework:

public class UserService
{
    private readonly DbContext _dbContext;

    public UserService(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public void CreateUser(string name, string email)
    {
        var user = new User { Name = name, Email = email };
        _dbContext.Set<User>().Add(user);
        _dbContext.SaveChanges();
    }

    public User GetUserById(int userId)
    {
        return _dbContext.Set<User>().Find(userId);
    }

    public User GetUserByEmail(string email)
    {
        return _dbContext.Set<User>().FirstOrDefault(u => u.Email == email);
    }
}

In conclusion, while the Repository Pattern offers advantages in terms of flexibility and testability, Entity Framework provides a more streamlined approach to data access, particularly for developers working in the Microsoft ecosystem or those looking for rapid development and integration with other Microsoft technologies. Ultimately, the choice between the Repository Pattern and Entity Framework depends on the specific requirements and constraints of the project.

Builder Design Pattern in C#

Rohit Cdy — Sat, 24 Feb 2024 10:52:35 +0000

Introduction
The Builder Design Pattern builds a complex object using many simple objects and a step-by-step approach. The goal is to create a generic process for constructing the complex object, which can be used to create different representations of the same object. This pattern is especially handy when:

You need to create an object with many optional and required fields.
The object’s construction process is complex.
Multiple representations of the object are possible.

Real-Life Analogy
Imagine building a laptop. A laptop is a complex object composed of various smaller components like LCD displays, USB ports, hard drives, batteries, keyboards, and more. To construct a laptop, we follow a generic process:

Plug in the memory.
Plug in the hard drive.
Plug in the battery.
Plug in the keyboard.
Cover the laptop with a plastic case.

Using this process, we can create different types of laptops—some with 14-inch screens, others with 17-inch screens, varying RAM sizes, and so on. The Builder Design Pattern allows us to assemble these small components into a cohesive whole, following the same generic process.

Implementation in C#
In C#, you can use the Builder Design Pattern to create objects with many optional components or configurations. Here’s how it works:

Define a Builder class responsible for constructing the complex object step by step.
The Builder class has methods for adding components (e.g., memory, hard drive, battery).
A Director class orchestrates the construction process by invoking the Builder methods.
The final complex object is retrieved from the Builder.

Here’s a simplified example:

using System;

// Product class (complex object)
class Laptop
{
    public int MemorySize { get; set; }
    public string HardDriveType { get; set; }
    // Other properties...

    public void DisplayInfo()
    {
        Console.WriteLine($"Laptop Info: Memory: {MemorySize}GB, Hard Drive: {HardDriveType}");
        // Display other properties...
    }
}

// Builder interface
interface ILaptopBuilder
{
    void AddMemory(int size);
    void AddHardDrive(string type);
    // Other methods for adding components...
    Laptop GetLaptop();
}

// Concrete builder
class LaptopBuilder : ILaptopBuilder
{
    private Laptop _laptop = new Laptop();

    public void AddMemory(int size)
    {
        _laptop.MemorySize = size;
    }

    public void AddHardDrive(string type)
    {
        _laptop.HardDriveType = type;
    }

    // Other component methods...

    public Laptop GetLaptop()
    {
        return _laptop;
    }
}

// Director
class LaptopManufacturer
{
    public Laptop ConstructLaptop(ILaptopBuilder builder)
    {
        builder.AddMemory(8); // Example: Add 8GB RAM
        builder.AddHardDrive("SSD"); // Example: Add SSD
        // Other component additions...
        return builder.GetLaptop();
    }
}

class Program
{
    static void Main()
    {
        var builder = new LaptopBuilder();
        var manufacturer = new LaptopManufacturer();
        var myLaptop = manufacturer.ConstructLaptop(builder);

        // Display laptop info
        myLaptop.DisplayInfo();
    }
}

Remember that the Builder Design Pattern allows you to create different representations of the same complex object using a consistent construction process. It’s a powerful tool when dealing with intricate object creation.

Abstract Factory Pattern in C#

Rohit Cdy — Sat, 24 Feb 2024 08:08:12 +0000

Introduction
The Abstract Factory pattern is a creational design pattern that provides a way to create families of related or dependent objects without specifying their concrete classes. 1 It is useful when you want to decouple the creation of objects from their usage and when you want to have multiple variants of the same family of objects.

Example
Let’s say you want to create a simulation of different types of vehicles, such as cars, trucks, and motorcycles. You want to have different families of vehicles, such as family vehicles, sports vehicles, and luxury vehicles. Each family of vehicles has its concrete implementation of the car, truck, and motorcycle interfaces.

To implement the Abstract Factory pattern, you need to define the following components:

An abstract product interface for each type of object, such as a Car, Truck, and Motorcycle.
A concrete product class for each variant of each type of object, such as Mustang, PickupTruck, and SportBike for the family vehicles family.
An abstract factory interface that declares methods for creating each type of object, such as VehicleFactory.
A concrete factory class for each family of objects that implements the abstract factory interface and returns the appropriate concrete products, such as FamilyVehicleFactory.

The following code shows the implementation of these components in C#:

// Abstract product interfaces
public interface Car
{
    void Drive();
}

public interface Truck
{
    void Drive();
}

public interface Motorcycle
{
    void Drive();
}

// Concrete product classes
public class Mustang : Car
{
    public void Drive()
    {
        Console.WriteLine("Driving a Mustang");
    }
}

public class PickupTruck : Truck
{
    public void Drive()
    {
        Console.WriteLine("Driving a Pickup Truck");
    }
}

public class SportBike : Motorcycle
{
    public void Drive()
    {
        Console.WriteLine("Riding a Sport Bike");
    }
}

// Abstract factory interface
public interface VehicleFactory
{
    Car CreateCar();
    Truck CreateTruck();
    Motorcycle CreateMotorcycle();
}

// Concrete factory classes
public class FamilyVehicleFactory : VehicleFactory
{
    public Car CreateCar()
    {
        return new Mustang();
    }

    public Truck CreateTruck()
    {
        return new PickupTruck();
    }

    public Motorcycle CreateMotorcycle()
    {
        return new SportBike();
    }
}

To use the Abstract Factory pattern, you need to create a client class that takes an abstract factory as a parameter and uses its methods to create and use the objects. The client class does not know which concrete products it receives from the factory, as it only uses the abstract product interfaces. This way, you can change the factory at runtime and get different variants of the same family of objects.

The following code shows an example of a client class in C#:

public class Client
{
    private VehicleFactory _vehicleFactory;

    public Client(VehicleFactory vehicleFactory)
    {
        _vehicleFactory = vehicleFactory;
    }

    public void CreateVehicles()
    {
        Car car = _vehicleFactory.CreateCar();
        Truck truck = _vehicleFactory.CreateTruck();
        Motorcycle motorcycle = _vehicleFactory.CreateMotorcycle();

        car.Drive();
        truck.Drive();
        motorcycle.Drive();
    }
}

To test the Abstract Factory pattern, you can create different concrete factories and pass them to the client class. The following code shows an example of how to do this in C#:

class Program
{
    static void Main(string[] args)
    {
        // Create a family vehicle factory
        VehicleFactory familyVehicleFactory = new FamilyVehicleFactory();
        // Create a client with the family vehicle factory
        Client client = new Client(familyVehicleFactory);
        // Create and use the family vehicles
        client.CreateVehicles();

        // Output:
        // Driving a Mustang
        // Driving a Pickup Truck
        // Riding a Sport Bike

        // Create another concrete factory here and pass it to the client to get different variants of the same family of objects
    }
}

Benefits and Drawbacks
The Abstract Factory pattern has the following benefits:

It promotes loose coupling by hiding the details of object creation from the client.
It supports the open/closed principle by allowing new variants of objects to be added without changing the existing code.
It supports the single responsibility principle by separating the creation of objects from their usage.

The Abstract Factory pattern has the following drawbacks:

It may introduce unnecessary complexity and extra work in the initial writing of code.
It may result in a large number of classes and interfaces, which can make the code harder to understand and maintain.
It may require changes in the abstract factory interface and all its subclasses if new types of objects are added to the family.

Delegate in C#

Rohit Cdy — Mon, 18 Dec 2023 18:40:22 +0000

What is a Delegate?

A delegate in C# is a type that represents references to methods with a specific parameter list and return type.
When you create an instance of a delegate, you can associate it with any method that has a compatible signature (matching parameters and return type).
Delegates allow you to pass methods as arguments to other methods.

Code Example

using System;
using System.Collections.Generic;

public class Program
{
    public class Person
    {
        public string Name { get; set; }
        public int Age { get; set; }
    }

    // Define a delegate to represent filtering methods
    public delegate bool FilterDelegate(Person p);

    public static void Main()
    {
        // Create some Person objects
        Person p1 = new Person() { Name = "Rohit", Age = 26 };
        Person p2 = new Person() { Name = "Lal", Age = 40 };
        Person p3 = new Person() { Name = "Prashant", Age = 65 };

        // Populate a list with Person objects
        List<Person> people = new List<Person>() { p1, p2, p3 };

        // Display people based on different filters
        DisplayPeople("Children", people, IsChild);
        DisplayPeople("Adults", people, IsAdult);
        DisplayPeople("Seniors", people, IsSenior);

        Console.Read();
    }

    // Display people based on a specified filter
    static void DisplayPeople(string title, List<Person> people, FilterDelegate filter)
    {
        Console.WriteLine(title + ":");
        foreach (Person p in people)
        {
            if (filter(p))
            {
                Console.WriteLine("{0}, {1} years old", p.Name, p.Age);
            }
        }
        Console.WriteLine();
    }

    // Filter methods
    static bool IsChild(Person p) => p.Age < 18;
    static bool IsAdult(Person p) => p.Age >= 18 && p.Age < 65;
    static bool IsSenior(Person p) => p.Age >= 65;
}

Key Concepts Explained

Delegate Declaration:

We define a FilterDelegate to represent filtering methods that take a Person object and return a boolean value.
This delegate allows us to dynamically choose different filters for our list of people.

Method Definitions:

We have three filter methods: IsChild, IsAdult, and IsSenior.
These methods determine whether a person falls into the child, adult, or senior category based on their age.

Displaying People:

The DisplayPeople method takes a title, a list of people, and a filter delegate.
It iterates through the list and displays relevant information based on the specified filter.

Output:

Children:
Rohit, 26 years old

Adults:
Rohit, 26 years old
Lal, 40 years old

Seniors:
Prashant, 65 years old

DEV Community: Rohit Cdy

Advanced Optimization Techniques for High-Performance Angular Applications.

1. Use OnPush Change Detection Strategy

2. Lazy Load Modules

3. Use Ahead-of-Time (AOT) Compilation

4. Minimize Bundle Size

5. Optimize DOM Manipulation with TrackBy in ngFor

6. Use Server-Side Rendering (SSR) with Angular Universal

7. Minimize HTTP Requests by Implementing Caching

8. Optimize Images and Assets

9. Enable Production Mode

10. Use Web Workers for Heavy Tasks

Conclusion

Mastering Angular Routing & Guards: Secure and Seamless Navigation!

Why Would We need Angular Guard Protection?

Types of Route Guards in Angular

How to Use Route Guards in Angular

1. canActivate - Block Access

Implementation:

Usage:

2. canActivateChild - Protect Child Routes

Implementation:

Usage:

3. canDeactivate - Prevent Accidental Data Loss

Solution:

Component Implementation:

Usage:

4. resolve - Fetch Data Before Route Activation

Implementation:

Usage:

How to access resolved data in Component:

5. canLoad - Blocking Lazy Module Loading

Implementation:

Usage:

Conclusion

Advanced implementation of Licensing Validation in angular applications.

What is AppInitializer in Angular?

How to Use AppInitializer for Licensing Validation in Angular

1. Create a License Service

3. Provide the AppInitializer in the AppModule

4. Handle Invalid License

Why AppInitializer for Licensing?

Conclusion

Third-party API Integration using ASP.Net Core web API.

Third-party API integration guidelines

Implementing Soft Delete With EF Core.

What is soft delete?

How to implement:

Benefits:

Conclusion

Prototype Design Pattern in C#

Factory Method Design Pattern in C#

Repository Pattern Vs Entity Framework

Builder Design Pattern in C#

Abstract Factory Pattern in C#

Delegate in C#

1. `canActivate` - Block Access

2. `canActivateChild` - Protect Child Routes

3. `canDeactivate` - Prevent Accidental Data Loss

4. `resolve` - Fetch Data Before Route Activation

5. `canLoad` - Blocking Lazy Module Loading