techbyfaiz.sezdah.com

Tag: backenddevelopment

  • Unit Test vs Integration Test vs End-to-End Test: Which One Should You Write?

    When I first started learning software testing, I thought:

    “Why do we need so many different types of tests?”

    If an End-to-End (E2E) test verifies the whole application, isn’t that enough?

    Over time, I realized that each type of test answers a different question.

    Understanding that changed how I think about testing.

    1. Unit Test

    A unit test verifies a single unit of code, usually a method or class, in isolation.

    Dependencies such as databases, APIs, or file systems are replaced with mocks or fakes.

    Example:

    • Does CalculateDiscount() return the correct value?
    • Does OrderService apply business rules correctly?

    Characteristics

    • Very fast
    • Easy to debug
    • Highly reliable
    • Runs frequently during development

    2. Integration Test

    An integration test verifies that multiple components work correctly together.

    Instead of mocking everything, it tests real interactions.

    Example:

    • Can the API save data to the database?
    • Does Entity Framework Core correctly persist entities?
    • Does the application communicate properly with Redis or RabbitMQ?

    Characteristics

    • Slower than unit tests
    • Tests real infrastructure
    • Catches configuration and integration issues

    3. End-to-End (E2E) Test

    An End-to-End test validates the entire application from the user’s perspective.

    Example:

    1. User logs in.
    2. Creates an order.
    3. Makes a payment.
    4. Receives a confirmation.

    Everything—from the UI to the database—is tested together.

    Characteristics

    • Slowest type of test
    • Closest to real user behavior
    • Excellent for validating critical business workflows

    Quick Comparison

    FeatureUnit TestIntegration TestEnd-to-End Test
    ScopeSingle method/classMultiple componentsEntire application
    DependenciesMockedRealReal
    SpeedFastMediumSlow
    PurposeVerify business logicVerify component interactionVerify complete user journey

    Which One Should You Write?

    The answer isn’t one or the other.

    A healthy test suite usually contains all three.

    • Write Unit Tests for business logic.
    • Write Integration Tests for APIs, databases, and external services.
    • Write End-to-End Tests for critical user journeys.

    Each type catches different kinds of problems.

    Final Thoughts

    One lesson I’ve learned is this:

    The goal of testing isn’t to increase the number of tests. It’s to increase confidence in your software.

    The best strategy is to balance speed, reliability, and coverage by choosing the right test for the right scenario.

  • ASP.NET Core Filters: Stop Repeating the Same Code in Every Controller

    ASP.NET Core Filters: Stop Repeating the Same Code in Every Controller

    When I first started building ASP.NET Core APIs, I noticed a pattern.

    Many controller actions contained the same code:

    • Validate requests.
    • Check permissions.
    • Log execution time.
    • Handle exceptions.
    • Write audit logs.

    The APIs worked.

    But every new endpoint meant copying the same logic again.

    That’s when I discovered Filters.

    I realized they weren’t just another ASP.NET Core feature—they were a way to keep controllers focused on business logic while moving cross-cutting concerns to reusable components.

    What Are Filters?

    Filters allow you to execute code before or after an action method runs.

    Instead of repeating common logic in every controller, you write it once and apply it wherever it’s needed.

    Types of Filters

    Authorization Filter

    Runs first and determines whether the request is authorized.

    Example:

    • Check user permissions.
    • Validate custom authorization rules.

    Resource Filter

    Executes before model binding.

    Useful for:

    • Caching
    • Short-circuiting requests
    • Resource initialization

    Action Filter

    Runs before and after the controller action.

    Common use cases:

    • Input validation
    • Logging
    • Measuring execution time
    • Auditing

    Exception Filter

    Handles exceptions thrown by controller actions.

    Useful for:

    • Logging exceptions
    • Returning consistent error responses

    Result Filter

    Runs before and after the action result is executed.

    Useful for:

    • Modifying response headers
    • Wrapping API responses
    • Adding metadata

    When Should You Use Filters?

    Filters are ideal for logic that applies across multiple endpoints.

    Examples include:

    • Audit logging
    • Request validation
    • Performance monitoring
    • Response formatting
    • Custom authorization

    If you find yourself copying the same code into multiple controllers, it’s often a sign that a filter could help.

    When Should You Avoid Filters?

    Filters aren’t the answer for every problem.

    Choose the right tool for the job:

    • Middleware for application-wide concerns such as authentication, CORS, or request logging.
    • Filters for MVC or API action-specific behavior.
    • Services for business logic.

    Keeping these responsibilities separate leads to a cleaner architecture.

    Final Thoughts

    One lesson changed the way I structure APIs:

    Controllers should coordinate requests—not perform every supporting task themselves.

    Filters help eliminate duplication, improve maintainability, and keep your business logic where it belongs.

  • Background Job Processing: Just Because You Can Do It in the Request Doesn’t Mean You Should

    Background Job Processing: Just Because You Can Do It in the Request Doesn’t Mean You Should

    Early in my career, I had a simple approach.

    A user submitted a request, and the API did everything before returning a response.

    • Save the data.
    • Send an email.
    • Generate a PDF.
    • Upload files.
    • Notify other systems.

    The endpoint worked.

    But it was also slow.

    Then I realized something important:

    Not every task belongs in the request-response cycle.

    Some tasks don’t need to finish before the user receives a response.

    That’s where background job processing becomes valuable.

    What Is Background Job Processing?

    A background job allows your application to offload long-running or non-critical work to execute after the request has completed.

    Instead of making the user wait, the API responds quickly while the background worker processes the remaining tasks.

    What Should Run in the Background?

    Typical examples include:

    • Sending emails or SMS messages.
    • Generating PDF or Excel reports.
    • Processing uploaded files.
    • Creating thumbnails or resizing images.
    • Synchronizing data with external systems.
    • Publishing events or notifications.

    These operations don’t usually need to block the user’s request.

    Benefits

    • Faster API response times.
    • Better user experience.
    • Improved scalability under heavy load.
    • Better resilience when external services are slow.

    Things to Consider

    Background jobs introduce new responsibilities.

    Think about:

    • Retry policies.
    • Error handling.
    • Monitoring and logging.
    • Idempotency to avoid duplicate processing.
    • Queue management.

    Moving work to the background doesn’t remove complexity—it moves it to a different part of the system.

    Common Tools in .NET

    Depending on your requirements, you might choose:

    • Hangfire
    • Quartz.NET
    • Azure Functions
    • Worker Services
    • Message queues such as RabbitMQ or Azure Service Bus

    The best tool depends on your application’s architecture and operational needs.

    Final Thoughts

    One lesson changed how I design APIs:

    Respond as soon as you’ve completed the work the user actually needs.

    Everything else should be evaluated to see whether it belongs in a background job.

    Fast APIs aren’t always the ones that do less work.

    They’re often the ones that do the right work at the right time.

  • Change Tracking in EF Core: What It Is and When Should You Use It?

    Change Tracking in EF Core: What It Is and When Should You Use It?

    One of the most powerful features of Entity Framework Core is Change Tracking.

    It allows EF Core to automatically detect changes made to entities and persist them to the database.

    But while it’s incredibly useful, it’s not always necessary.

    Understanding when to use Change Tracking—and when to disable it—can significantly improve your application’s performance.

    What Is Change Tracking?

    When EF Core retrieves an entity, it keeps track of its original state.

    If you modify one of its properties, EF Core detects the change.

    When you call SaveChanges(), only the modified values are sent to the database.

    Example:

    var product = await context.Products
    .FirstAsync(p => p.Id == 1);

product.Price = 1200;

await context.SaveChangesAsync();

    Notice that we never call Update().

    EF Core already knows that Price changed.

    How Does It Work?

    When an entity is loaded:

    • EF Core stores the original values.
    • It monitors property changes.
    • During SaveChanges(), it compares the current values with the original values.
    • Only the necessary SQL UPDATE statement is generated.

    This makes updates simple and reduces boilerplate code.

    When Should You Use Change Tracking?

    Change Tracking is ideal when:

    • Updating existing records.
    • Inserting related entities.
    • Managing relationships.
    • Performing CRUD operations where data will be modified.

    When Should You Avoid It?

    If you’re only reading data, Change Tracking adds unnecessary overhead.

    In those cases, use:

    var products = await context.Products
    .AsNoTracking()
    .ToListAsync();

    This avoids tracking every entity and can improve performance, especially for large result sets.

    Change Tracking vs AsNoTracking()

    With Change Tracking

    var product = await context.Products
    .FirstAsync();

product.Price = 1200;

await context.SaveChangesAsync();

    ✅ Changes are automatically detected and saved.

    With AsNoTracking()

    var product = await context.Products
    .AsNoTracking()
    .FirstAsync();

    The entity is not tracked.

    If you modify it and call SaveChanges(), nothing happens unless you explicitly attach or update the entity.

    Performance Considerations

    Tracking every entity consumes:

    • Memory
    • CPU
    • Change detection time

    For read-heavy APIs or reporting queries, disabling tracking can provide noticeable performance improvements.

    However, don’t disable tracking if you intend to modify the entities afterwards.

    Best Practices

    ✅ Use Change Tracking for create, update, and delete operations.

    ✅ Use AsNoTracking() for read-only queries.

    ✅ Avoid tracking thousands of entities unnecessarily.

    ✅ Understand whether your query needs tracked or untracked entities before optimizing.

    Final Thoughts

    Change Tracking is one of the reasons EF Core makes data updates so convenient.

    But like any feature, it should be used intentionally.

    A simple rule I follow is:

    • Reading data? → Use AsNoTracking().
    • Updating data? → Let EF Core track the entity.

    Choosing the right approach helps you build applications that are both clean and efficient.

  • Monolith vs Microservices: Which Architecture Should You Choose?

    Monolith vs Microservices: Which Architecture Should You Choose?

    One of the most common architecture debates is:

    Should I build a Monolith or Microservices?

    Many developers assume microservices are always the better choice because large companies like Netflix, Amazon, and Uber use them.

    The reality?

    Most applications don’t need microservices on day one.

    Let’s compare both approaches.

    What Is a Monolithic Architecture?

    In a monolithic application, all modules—such as authentication, products, orders, and payments—are part of a single application and are deployed together.

    Advantages

    ✅ Simple to develop and deploy.

    ✅ Easier to debug.

    ✅ Lower operational complexity.

    ✅ Faster to get started.

    Challenges

    • Scaling means scaling the entire application.
    • A bug in one module can affect the whole system.
    • Large codebases become harder to maintain over time.

    What Are Microservices?

    In a microservices architecture, the application is divided into independent services.

    For example:

    • Authentication Service
    • Order Service
    • Product Service
    • Payment Service

    Each service can be developed, deployed, and scaled independently.

    Advantages

    ✅ Independent deployments.

    ✅ Scale only the services that need it.

    ✅ Better fault isolation.

    ✅ Teams can work independently.

    Challenges

    • More complex infrastructure.
    • Service-to-service communication.
    • Distributed logging and monitoring.
    • Data consistency across services.
    • Higher operational cost.

    When Should You Choose a Monolith?

    A monolith is often the better choice when:

    • You’re building a new product or MVP.
    • The team is small.
    • Requirements are still evolving.
    • Deployment simplicity is important.

    A well-designed modular monolith can support significant growth before microservices become necessary.

    When Should You Choose Microservices?

    Microservices become more valuable when:

    • Different parts of the system have different scaling needs.
    • Multiple teams work independently.
    • Independent deployments are required.
    • The application has grown too large for a single codebase.

    Comparison

    FeatureMonolithMicroservices
    DeploymentSingle deploymentIndependent deployments
    ScalabilityEntire applicationIndividual services
    ComplexityLowerHigher
    DevelopmentEasier initiallyMore planning required
    Team CollaborationBetter for small teamsBetter for multiple teams
    InfrastructureSimpleMore complex

    My Rule of Thumb

    • Small to medium applications: Start with a modular monolith.
    • Large, rapidly growing systems with multiple teams: Consider microservices when there is a clear business or technical need.

    Choosing microservices too early can introduce unnecessary complexity.

    Final Thoughts

    Architecture isn’t about following trends.

    It’s about solving the right problem with the right level of complexity.

    A well-structured monolith is often a better choice than poorly designed microservices.

    Start simple, measure your application’s needs, and evolve your architecture when the benefits outweigh the added complexity.

  • Lazy Loading vs Eager Loading vs Explicit Loading in EF Core: Which One Should You Use?

    Lazy Loading vs Eager Loading vs Explicit Loading in EF Core: Which One Should You Use?

    When working with Entity Framework Core, loading related data efficiently is just as important as writing correct queries.

    EF Core provides three approaches:

    • Eager Loading
    • Lazy Loading
    • Explicit Loading

    Each has its own strengths and trade-offs.

    Choosing the wrong one can lead to unnecessary database calls and poor application performance.

    Let’s explore when to use each.

    1. Eager Loading

    Eager loading retrieves the main entity and its related data in a single query using Include().

    Example:

    var orders = await context.Orders
    .Include(o => o.Customer)
    .ToListAsync();

    Here, both Orders and their related Customer data are loaded together.

    Use Eager Loading When:

    • You know you’ll need the related data.
    • You want to minimize database round trips.
    • You’re building APIs that return complete object graphs.

    Pros

    • Fewer database queries.
    • Better performance in many scenarios.
    • Easy to understand.

    Cons

    • Can retrieve unnecessary data if overused.
    • Multiple Include() calls may produce complex SQL queries.

    2. Lazy Loading

    With lazy loading, related data isn’t loaded until it’s actually accessed.

    Example:

    var order = await context.Orders.FirstAsync();

var customer = order.Customer;

    The second line triggers another database query.

    Use Lazy Loading When:

    • Related data is rarely needed.
    • Simplicity is more important than maximum performance.

    Pros

    • Loads data only when needed.
    • Cleaner code.

    Cons

    • Can generate many hidden database queries.
    • May lead to the N+1 query problem.
    • Less predictable performance.

    3. Explicit Loading

    Explicit loading gives you full control over when related data is retrieved.

    Example:

    var order = await context.Orders.FirstAsync();

await context.Entry(order)
    .Reference(o => o.Customer)
    .LoadAsync();

    The related entity is loaded only when you explicitly request it.

    Use Explicit Loading When:

    • You only need related data in specific scenarios.
    • You want predictable database access.
    • You’re optimizing performance-critical code.

    Pros

    • Full control over database queries.
    • Avoids unnecessary loading.

    Cons

    • Requires additional code.
    • Easier to forget loading related entities.

    Beware of the N+1 Query Problem

    Consider this:

    var orders = await context.Orders.ToListAsync();

foreach (var order in orders)
{
    Console.WriteLine(order.Customer.Name);
}

    If lazy loading is enabled, EF Core may execute:

    • 1 query for all orders.
    • 1 additional query for each customer.

    If there are 100 orders, that could result in 101 database queries.

    This is known as the N+1 query problem, and it can significantly impact performance.

    Which One Should You Choose?

    ScenarioRecommended
    You already know you’ll need related data✅ Eager Loading
    Related data is optional and rarely used✅ Lazy Loading
    You need precise control over when data is loaded✅ Explicit Loading

    Final Thoughts

    There isn’t a single “best” loading strategy.

    The right choice depends on your application’s requirements.

    My general rule is:

    • Prefer Eager Loading for APIs and common queries.
    • Use Explicit Loading when you need fine-grained control.
    • Use Lazy Loading carefully, especially in high-performance applications, to avoid hidden database queries.

    Understanding these loading strategies can help you build faster, more efficient EF Core applications.

  • Entity Framework vs Entity Framework Core: What’s the Difference?

    Entity Framework vs Entity Framework Core: What’s the Difference?

    Many developers assume Entity Framework (EF6) and Entity Framework Core (EF Core) are simply different versions of the same framework.

    They’re not.

    EF Core was redesigned from the ground up to meet the needs of modern .NET applications. While both are Object-Relational Mappers (ORMs), they differ significantly in architecture, performance, and capabilities.

    Let’s explore the key differences.

    What is Entity Framework (EF6)?

    Entity Framework 6 is the classic ORM designed primarily for the .NET Framework.

    It simplifies database access by allowing developers to work with C# objects instead of writing SQL for every operation.

    EF6 is mature, stable, and still maintained, making it a suitable choice for many existing .NET Framework applications.

    What is Entity Framework Core?

    Entity Framework Core is Microsoft’s modern ORM for .NET (formerly .NET Core).

    It was rewritten with a focus on:

    • Cross-platform support
    • High performance
    • Better extensibility
    • Modern application development
    • Cloud-native workloads

    It powers most new ASP.NET Core applications today.

    Key Differences

    FeatureEntity Framework (EF6)Entity Framework Core
    Target Platform.NET FrameworkModern .NET (.NET 6/7/8/9+)
    Cross-Platform❌ No✅ Yes
    PerformanceGoodBetter for most workloads
    LINQ TranslationMatureMore optimized and actively evolving
    Dependency InjectionLimitedBuilt-in support
    Batch OperationsLimitedImproved support
    MigrationsSupportedMore flexible and actively developed
    Cloud & ContainersLimitedDesigned with modern deployment in mind

    Performance

    EF Core generally performs better because it was designed with performance in mind.

    It includes improvements such as:

    • Faster query execution
    • Better SQL generation
    • More efficient change tracking
    • Compiled queries
    • Split queries for complex object graphs

    These features can make a noticeable difference in high-traffic applications.

    Which One Should You Choose?

    Choose EF6 if:

    • You’re maintaining an existing .NET Framework application.
    • Migrating to modern .NET isn’t currently feasible.
    • The application is stable and doesn’t require new EF Core features.

    Choose EF Core if:

    • You’re starting a new project.
    • You’re building an ASP.NET Core application.
    • You need cross-platform support.
    • Performance and scalability are important.
    • You want access to the latest features and ongoing improvements.

    Migration Considerations

    Migrating from EF6 to EF Core isn’t always a simple package upgrade.

    Some APIs and behaviors differ, and applications with heavy customizations may require code changes and testing.

    Plan the migration carefully and validate functionality before moving to production.

    Final Thoughts

    Both EF6 and EF Core are capable ORMs, but they’re designed for different generations of .NET development.

    • Maintaining a legacy .NET Framework application? EF6 is still a solid choice.
    • Building a modern application? EF Core should be your default choice.

    Technology evolves, and EF Core represents Microsoft’s long-term direction for data access in the .NET ecosystem.

  • Repository Pattern vs Unit of Work in .NET: Do You Really Need Both?

    Repository Pattern vs Unit of Work in .NET: Do You Really Need Both?

    If you’ve worked on ASP.NET Core projects, you’ve probably seen classes like:

    • CustomerRepository
    • OrderRepository
    • UnitOfWork

    But with Entity Framework Core, an important question arises:

    Do we still need Repository and Unit of Work, or is DbContext enough?

    The answer depends on your application’s complexity and architectural goals.

    What Is the Repository Pattern?

    A Repository acts as an abstraction between your business logic and the data access layer.

    Instead of writing database queries throughout your application, all data operations are centralized.

    Example:

    public interface IProductRepository
{
    Task<Product?> GetByIdAsync(int id);
    Task AddAsync(Product product);
    Task DeleteAsync(Product product);
}

    The service interacts with the repository instead of directly with Entity Framework.

    Benefits

    • Separates business logic from data access.
    • Easier to mock during unit testing.
    • Centralizes reusable queries.
    • Improves maintainability in large projects.

    What Is the Unit of Work Pattern?

    The Unit of Work coordinates multiple repositories so they participate in a single transaction.

    Instead of saving changes after every repository operation, you commit them together.

    Example:

    await unitOfWork.Products.AddAsync(product);
await unitOfWork.Orders.AddAsync(order);

await unitOfWork.SaveChangesAsync();

    If one operation fails, the entire transaction can be rolled back.

    Doesn’t EF Core Already Provide These?

    Yes—and this is where many developers get confused.

    DbSet<T> behaves much like a Repository

    It already provides methods such as:

    • Add()
    • Remove()
    • Find()
    • Update()

    DbContext behaves like a Unit of Work

    It:

    • Tracks entity changes.
    • Coordinates updates.
    • Executes a single SaveChanges() or SaveChangesAsync().
    • Wraps changes in a transaction when appropriate.

    Because of this, many developers consider custom Repository and Unit of Work implementations unnecessary for simple CRUD applications.

    When Should You Use Custom Repository and Unit of Work?

    They make sense when:

    • Your application is large and follows Clean Architecture or Domain-Driven Design (DDD).
    • Multiple data sources need a consistent abstraction.
    • You have complex queries reused across many services.
    • You want to isolate EF Core from the application layer.
    • You anticipate changing the data access technology in the future.

    When Might They Be Unnecessary?

    For smaller applications that use EF Core exclusively, adding generic repositories can introduce extra complexity without much benefit.

    In these cases, injecting DbContext directly into services is often simpler and perfectly acceptable.

    My Rule of Thumb

    • Small to medium CRUD applications: DbContext is usually enough.
    • Large enterprise applications: A well-designed Repository and Unit of Work layer can improve organization, testability, and maintainability.

    The important point isn’t to follow a pattern blindly—it’s to choose the level of abstraction your project actually needs.

    Final Thoughts

    Repository and Unit of Work are valuable patterns, but they’re not mandatory in every ASP.NET Core application.

    EF Core already implements many of their responsibilities.

    Before adding another abstraction layer, ask yourself:

    Does this simplify my application, or does it simply add more code to maintain?

    Good architecture isn’t about using more patterns—it’s about using the right patterns for the problem you’re solving.

  • 𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲-এ 𝗮𝗽𝗽.𝗨𝘀𝗲𝗦𝘄𝗮𝗴𝗴𝗲𝗿() এবং 𝗮𝗽𝗽.𝗨𝘀𝗲𝗦𝘄𝗮𝗴𝗴𝗲𝗿𝗨𝗜() কেন ব্যবহার করা হয়?

    𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲-এ 𝗮𝗽𝗽.𝗨𝘀𝗲𝗦𝘄𝗮𝗴𝗴𝗲𝗿() এবং 𝗮𝗽𝗽.𝗨𝘀𝗲𝗦𝘄𝗮𝗴𝗴𝗲𝗿𝗨𝗜() কেন ব্যবহার করা হয়?

    ধরুন, আপনি একটি নতুন Web API তৈরি করেছেন।

    সব endpoint ঠিকমতো কাজ করছে।

    আপনি Postman দিয়ে test করছেন।

    কিন্তু হঠাৎ আপনার টিমের একজন Developer এসে বলল,

    “API-এর documentation কোথায়?”

    আপনি বললেন,

    “Postman Collection আছে।”

    সে আবার বলল,

    “নতুন Developer join করলে কি Postman Collection দিয়েই সব বুঝতে হবে?”

    এখানেই Swagger-এর প্রয়োজনীয়তা শুরু।

    Swagger আসলে কী?

    Swagger হলো এমন একটি tool যা আপনার Web API-এর documentation automatically তৈরি করে।

    অর্থাৎ, আপনার API-তে কী কী endpoint আছে,

    • কোন URL
    • কোন HTTP Method (GET, POST, PUT, DELETE)
    • কী parameter লাগবে
    • কী response আসবে

    সবকিছু সুন্দরভাবে একটি UI-তে দেখিয়ে দেয়।

    তাহলে app.UseSwagger() কী করে?

    app.UseSwagger();

    এই লাইনটি Swagger-এর JSON documentation generate করে।

    যেমন:

    /swagger/v1/swagger.json

    এই JSON file-এর মধ্যেই আপনার পুরো API-এর description থাকে।

    অর্থাৎ এটি UI নয়।

    এটি শুধুমাত্র API-এর metadata তৈরি করে।

    তাহলে app.UseSwaggerUI() কী করে?

    app.UseSwaggerUI();

    এই লাইনটি সেই JSON file-কে একটি সুন্দর Web UI-তে দেখায়।

    ফলে Browser থেকে আপনি দেখতে পারেন—

    ✅ সব Endpoint

    ✅ Request Body

    ✅ Parameters

    ✅ Response

    ✅ এমনকি Browser থেকেই API Call করতে পারেন।

    বাস্তব উদাহরণ

    ধরুন আপনি একটি Food Delivery API বানিয়েছেন।

    Swagger UI খুললে দেখতে পারবেন—

    GET     /api/restaurants

GET     /api/restaurants/{id}

POST    /api/orders

PUT     /api/orders/{id}

DELETE  /api/orders/{id}

    প্রতিটি endpoint-এ ক্লিক করে আপনি Request পাঠাতে পারবেন।

    Postman খুলারও দরকার হবে না।

    যদি শুধু UseSwagger() লিখেন?

    তাহলে JSON তৈরি হবে।

    কিন্তু Browser-এ সুন্দর UI পাবেন না।

    যদি শুধু UseSwaggerUI() লিখেন?

    Swagger UI দেখানোর জন্য JSON দরকার।

    UseSwagger() না থাকলে UI কাজ করতে পারবে না।

    অর্থাৎ—

    দুইটি middleware একে অপরের উপর নির্ভরশীল।

    Development Environment-এ কেন বেশি ব্যবহার করা হয়?

    অনেক Project-এ আপনি এমন Code দেখবেন—

    if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

    কারণ Production Environment-এ অনেক সময় API documentation public রাখা হয় না।

    Security-এর কারণেও অনেক প্রতিষ্ঠান Production-এ Swagger disable করে রাখে।

    আমার পরামর্শ

    Swagger শুধু API দেখানোর জন্য নয়।

    এটি Team Collaboration অনেক সহজ করে।

    নতুন Developer onboarding, Frontend integration, QA testing—সব ক্ষেত্রেই Swagger অসাধারণ একটি tool।

    আমার মতে, ASP.NET Core শিখতে গেলে Swagger বোঝা বাধ্যতামূলক।

    কারণ এটি শুধু documentation নয়, এটি আপনার API-এর “Interactive User Manual”।

  • 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗖# 𝟭𝟰: 𝗠𝗼𝗱𝗲𝗿𝗻 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝗧𝗵𝗮𝘁 𝗠𝗮𝗸𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲 𝗖𝗹𝗲𝗮𝗻𝗲𝗿 𝗮𝗻𝗱 𝗠𝗼𝗿𝗲 𝗘𝘅𝗽𝗿𝗲𝘀𝘀𝗶𝘃𝗲

    𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗖# 𝟭𝟰: 𝗠𝗼𝗱𝗲𝗿𝗻 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝗧𝗵𝗮𝘁 𝗠𝗮𝗸𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲 𝗖𝗹𝗲𝗮𝗻𝗲𝗿 𝗮𝗻𝗱 𝗠𝗼𝗿𝗲 𝗘𝘅𝗽𝗿𝗲𝘀𝘀𝗶𝘃𝗲

    C# continues to evolve with every release, focusing on making developers more productive while keeping code clean, readable, and maintainable.

    C# 14 introduces several improvements that help developers write simpler and more expressive code.

    Here are some notable features:

    1. Extension Members

    C# 14 expands extension methods with a more powerful concept called extension members.

    Previously, extension methods allowed adding methods to existing types without modifying them.

    Now, extension members allow developers to add more than just methods, including properties and other members.

    This makes APIs easier to design and improves code organization.

    2. Null-Conditional Assignment

    C# 14 improves null handling by allowing assignments through null-conditional operators.

    Before:

    if (customer != null)
{
    customer.Name = "Faiz";
}

    With C# 14:

    customer?.Name = "Faiz";

    This reduces unnecessary null checks and improves readability.

    3. Field Keyword

    C# 14 introduces the field keyword, making property implementations cleaner.

    Before:

    private string _name;

public string Name
{
    get => _name;
    set => _name = value;
}

    With C# 14:

    public string Name
{
    get;
    set => field = value;
}

    This reduces boilerplate code while keeping control over property behavior.

    4. More Flexible Method Overloads

    C# 14 improves overload resolution and allows developers to create APIs with better flexibility and fewer workarounds.

    This helps when designing libraries and reusable components.

    5. Improved Developer Experience

    Besides new language features, C# 14 continues improving:

    ✅ Code readability
    ✅ Developer productivity
    ✅ Performance opportunities
    ✅ Modern application development patterns

    The goal of every C# update is not just adding features.

    The real goal is helping developers write code that is:

    ✔ Easier to understand
    ✔ Easier to maintain
    ✔ Less error-prone
    ✔ More aligned with modern software practices

    As .NET developers, staying updated with language evolution helps us make better technical decisions.

    💬 Which C# 14 feature are you most excited to use in your projects?

    ♻️ If you found this helpful, feel free to repost and share it with your network.

    Follow Engineer Faiz for more insights on software engineering and technology.

    #csharp #dotnet #softwareengineering #backenddevelopment #programming