A fundamental component of practically all.NET applications is data access. Performance, scalability, and long-term maintainability are all impacted by how an application interacts with its database. Entity Framework Core and Dapper are two widely used data access solutions in the.NET environment.

 Despite having the same goal, they approach it in somewhat different ways. Performance and control are prioritized in one, while developer productivity and abstraction are the focus of the other. The distinctions between Entity Framework Core and Dapper are explained in this article, which also assists you in determining whether to utilize either.

Comprehending the Entity Framework Core
Microsoft offers Entity Framework Core, a feature-rich object-relational mapper. Instead of writing raw SQL queries, it enables developers to work with databases using highly typed C# objects.

Change tracking, relationship management, and query translation are all automatically handled by EF Core. Instead than concentrating on database specifics, developers can concentrate more on business logic. Because of this abstraction, EF Core is particularly appealing for applications that need to be developed quickly and have their schemas changed frequently.

But there is a price for this convenience. Performance overhead may be introduced by the extra abstraction layer, particularly in complex or big queries.

Comprehending Dapper
The Stack Overflow team created the lightweight micro-ORM known as Dapper. Dapper does not attempt to conceal SQL from developers, in contrast to EF Core. Rather, it gives the developer complete control over SQL while mapping query results straight to C# objects.

Dapper is incredibly quick and memory-efficient due to its avoidance of features like change tracking and intricate abstractions. It is often chosen for scenarios where performance is critical or where queries must be carefully optimized.

Having to manually write and maintain SQL is a trade-off that can make development more difficult and limit flexibility when database schemas change.

Aspects of Performance
One of the main reasons developers pick Dapper over Entity Framework Core is performance. Dapper does less work in the background, which allows it to run queries more quickly and consume less resources.

Despite not being sluggish, Entity Framework Core adds overhead with capabilities like dynamic SQL generation and entity state tracking. This overhead is tolerable for the majority of business applications, but it can become apparent for systems with a lot of traffic or data.

In other words, Dapper typically has the edge if performance is the primary concern.

Productivity and Maintainability
Entity Framework Core excels in developer productivity. Its LINQ-based querying, automatic migrations, and change tracking significantly reduce boilerplate code and speed up development. It also improves maintainability by keeping database logic strongly typed and closely aligned with the domain model.

Dapper, on the other hand, offers less abstraction. While this gives developers more control, it also means more manual work. SQL queries must be written, tested, and maintained explicitly, which can slow development and increase the risk of errors if not managed carefully.

When to Choose Entity Framework Core?
Entity Framework Core is a strong choice when development speed, maintainability, and ease of use are more important than maximum performance. It works particularly well for CRUD-heavy applications and systems where the data model evolves frequently.

Typical scenarios include enterprise applications, internal tools, administrative dashboards, and projects where a clean domain model is a priority.

When to Choose Dapper?
Dapper is ideal when performance and control matter most. It is commonly used in read-heavy systems, reporting tools, and APIs that must handle a large number of requests efficiently.

It is also well suited for applications that rely on complex or highly optimized SQL queries, where developers want full visibility and control over database interactions.
Using Entity Framework Core and Dapper Together

Many real-world applications successfully use both technologies. A common approach is to use Entity Framework Core for standard data operations and Dapper for performance-critical or complex queries.

This hybrid strategy combines the productivity of EF Core with the speed and efficiency of Dapper, allowing developers to use the right tool for each scenario.

Conclusion
There is no single best choice between Entity Framework Core and Dapper. Each tool has its strengths and weaknesses, and the right decision depends on the specific requirements of your application. Choose Entity Framework Core when productivity, maintainability, and rapid development are your main goals. Choose Dapper when performance, simplicity, and full SQL control are essential. In many cases, using both together provides the best balance. Making an informed choice will help you build better, more efficient .NET applications

The ideal method for creating cloud-native, scalable, and maintainable systems is microservices architecture. Microservices are not the initial state of the majority of real-world systems, though. They begin as monolithic programs that run crucial business logic and were frequently created years ago.

It's a frequent misperception that implementing microservices necessitates a total overhaul. Rewriting a monolith from scratch is actually costly, hazardous, and rarely successful.
This article describes how to use the Strangler Fig Pattern, a secure and tried-and-true migration technique, to create microservices within an existing monolith in .NET Core.

What Is a Monolithic Application?
A monolith is an application where:

• All features live in a single codebase
• Components are tightly coupled
• Deployment happens as one unit

Challenges of a Monolith

• Slow deployments
• Difficult scaling
• High risk when changing code
• Hard to adopt new technologies

Despite these challenges, monoliths are not “bad”. They are often stable and business-critical, which is why careful evolution is needed.

Why Not Rewrite Everything as Microservices?
A full rewrite introduces:

• Business downtime
• Loss of domain knowledge
• New bugs and regressions
• Long time-to-market

Instead of replacing the monolith, a gradual migration is the safest approach.

What Does “Microservices via Monolith” Mean?
“Microservices via Monolith” means:

• Keeping the existing monolith alive
• Gradually extracting features into microservices
• Letting both systems coexist during the transition

This approach allows teams to:

• Reduce risk
• Deliver value incrementally
• Learn microservices without breaking production

The Strangler Fig Pattern
The Strangler Fig Pattern is a migration strategy where:

• New features are built as microservices
• Existing functionality is slowly moved out
• The monolith eventually becomes obsolete

Named after the strangler fig tree, which grows around an existing tree until it replaces it.

High-Level Architecture

Client
  |
API Gateway / Reverse Proxy
  |
----------------------------
|          |               |
Monolith  Microservice A  Microservice B

Step-by-Step Migration in .NET Core
Step 1: Modularize the Monolith

Before extracting services, clean up the monolith:

• Separate business logic from controllers
• Use layered architecture (API, Application, Domain, Infrastructure)
• Identify bounded contexts

Tip: If your monolith is already in ASP.NET Core, you are halfway there.

Step 2: Identify a Candidate Microservice
Good candidates:

• Low coupling with other modules
• Clear business boundaries
• High change frequency

Examples:

• Authentication
• Notifications
• Reporting
• Payments

Step 3: Create a New ASP.NET Core Microservice
Create a new project:
dotnet new webapi -n NotificationService

This service should:

• Own its database
• Expose REST APIs
• Be independently deployable

Step 4: Route Traffic Using an API Gateway
Use tools like:

• YARP (Yet Another Reverse Proxy)
• Ocelot
• Azure API Management

Example with YARP:
    /api/notifications → Microservice
    /api/orders → Monolith

This makes the migration invisible to clients.

Step 5: Data Management Strategy
Avoid sharing databases.

Common approaches:

• Database per service
• Data synchronization via events
• Read replicas for legacy data

Never let microservices directly access the monolith database.

Step 6: Communication Between Monolith and Microservices
Preferred methods:

• REST APIs
• Asynchronous messaging (RabbitMQ, Azure Service Bus)

Example:

• Monolith publishes OrderCreated event
• Microservice listens and processes it

Example: Extracting Notification Service

Before (Monolith)
public class OrderService
{
    public void CreateOrder()
    {
        // Order logic
        SendEmail();
    }
}

After (Microservice)
// Monolith
PublishEvent(new OrderCreatedEvent());

// Notification Microservice
public class OrderCreatedHandler
{
    public Task Handle(OrderCreatedEvent evt)
    {
        SendEmail();
    }
}

Result:

• Loose coupling
• Independent scaling
• Faster deployments

Benefits of Microservices via Monolith
✔ Lower migration risk
✔ Continuous delivery
✔ Independent scaling
✔ Better maintainability
✔ Cloud readiness

Common Mistakes to Avoid
❌ Extracting too many services at once
❌ Sharing databases
❌ Overusing synchronous calls
❌ Ignoring observability (logs, metrics, tracing)

Tools Commonly Used in .NET Core Microservices

• ASP.NET Core
• Docker
• Kubernetes
• YARP / Ocelot
• Serilog
• OpenTelemetry
• RabbitMQ / Azure Service Bus

When Should You Stop?
The migration ends when:

• The monolith no longer handles business logic
• Remaining code is minimal or retired
• All core features live in microservices
• At this point, the monolith can be safely decommissioned.

Conclusion
Migrating from a monolith to microservices does not require a risky rewrite. By using the Microservices via Monolith approach with .NET Core and the Strangler Fig Pattern, teams can modernize their applications safely, incrementally, and confidently.

This strategy is battle-tested, production-friendly, and ideal for organizations that want the benefits of microservices without the pain of starting over.