Back to: ASP.NET Core Web API Tutorials
Without Using the Repository Pattern in ASP.NET Core Web API
In this article, we will discuss Application Development Without Using the Repository Pattern in ASP.NET Core Web API. This is also a continuation of our previous article, where we built a sample E-Commerce system with multiple entities: Category, Product, Customer, Order, and Order Item. We used Entity Framework Core’s Code-First approach to define our models and seed initial data.
Now, before introducing abstractions like the Repository Pattern, it’s essential to understand how direct use of DbContext in controllers works, what problems it introduces, and why these become severe as the project grows.
Now, we will explore how to implement data access operations directly in ASP.NET Core Web API controllers using the EF Core DbContext without using any abstraction like the Repository Pattern. This approach will help us understand limitations such as code duplication, testing challenges, and tight coupling between controllers and EF Core, especially as application complexity grows, which motivates us to use the Repository Pattern.
Why Start Without the Repository Pattern?
DbContext is EF Core’s core API for data operations. In small projects or demo projects, injecting the ECommerceDbContext directly into API controllers and performing database CRUD operations is common. While this approach is quick and easy to set up, it results in several issues as the application grows:
- Tight Coupling: Controllers directly depend on EF Core’s DbContext implementation.
- Code Duplication: Common CRUD logic may be duplicated across controllers.
- Hard to Test: Mocking or unit testing controllers becomes cumbersome.
- Poor Maintainability: Business logic mixed with data access reduces code clarity.
- Scalability Issues: Difficult to extend and maintain as the application grows.
Implementing CRUD Operations Directly Using DbContext
We will demonstrate CRUD operations in multiple controllers to illustrate real-world scenarios. The Controllers manage CRUD operations directly using ECommerceDbContext.
CategoriesController: CRUD Operations for Categories
Create an Empty API controller named CategoriesController inside the Controllers folder and then copy and paste the following code. This controller manages operations related to product categories. It allows clients to retrieve all categories or a specific category by ID, create new categories, update existing ones, and delete categories. Encapsulating category management ensures that products can be organized logically, making it easier for clients to filter and browse products based on categories.
using ECommerceAPI.Data;
using ECommerceAPI.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
namespace ECommerceAPI.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class CategoriesController : ControllerBase
{
// Private readonly field to hold the injected database context
private readonly ECommerceDbContext _context;
// Constructor with dependency injection of DbContext
public CategoriesController(ECommerceDbContext context)
{
_context = context;
}
// GET: api/categories
// Retrieves the full list of categories from the database asynchronously
[HttpGet]
public async Task<IActionResult> GetAllCategories()
{
// Use AsNoTracking for read-only query to improve performance (no change tracking)
var categories = await _context.Categories.AsNoTracking().ToListAsync();
// Return HTTP 200 OK with the categories list in the response body
return Ok(categories);
}
// GET: api/categories/{id}
// Retrieves a single category by its primary key (id)
[HttpGet("{id}")]
public async Task<IActionResult> GetCategoryById(int id)
{
// Find the category asynchronously by primary key
var category = await _context.Categories.FindAsync(id);
// If category does not exist, return HTTP 404 Not Found
if (category == null)
return NotFound();
// Return HTTP 200 OK with the found category
return Ok(category);
}
// POST: api/categories
// Creates a new category using data from the request body
[HttpPost]
public async Task<IActionResult> CreateCategory([FromBody] Category category)
{
// Check if the incoming model is valid based on data annotations
if (!ModelState.IsValid)
// If invalid, return HTTP 400 Bad Request with validation errors
return BadRequest(ModelState);
// Add the new category to the DbSet (in-memory)
await _context.Categories.AddAsync(category);
// Save changes asynchronously to the database
await _context.SaveChangesAsync();
// Return HTTP 200 OK with the newly created category (including generated ID)
return Ok(category);
}
// PUT: api/categories/{id}
// Updates an existing category identified by id with the provided data
[HttpPut("{id}")]
public async Task<IActionResult> UpdateCategory(int id, [FromBody] Category updatedCategory)
{
// Verify that the id in the URL matches the ID in the payload
if (id != updatedCategory.CategoryId)
return BadRequest("Category ID mismatch.");
// Validate the incoming model
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Retrieve the existing category from the database
var existingCategory = await _context.Categories.FindAsync(id);
// If not found, return 404 Not Found
if (existingCategory == null)
return NotFound();
// Update only the mutable properties
existingCategory.Name = updatedCategory.Name;
existingCategory.Description = updatedCategory.Description;
// Mark the entity as modified
_context.Categories.Update(existingCategory);
// Persist the changes asynchronously
await _context.SaveChangesAsync();
// Return HTTP 204 No Content to indicate successful update with no response body
return NoContent();
}
// DELETE: api/categories/{id}
// Deletes a category identified by id
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteCategory(int id)
{
// Find the category by ID
var category = await _context.Categories.FindAsync(id);
// If not found, return 404 Not Found
if (category == null)
return NotFound();
// Remove the category from the DbSet
_context.Categories.Remove(category);
// Persist changes asynchronously
await _context.SaveChangesAsync();
// Return HTTP 204 No Content to indicate successful deletion
return NoContent();
}
}
}
ProductsController: CRUD Operations for Products
Create an Empty API controller named ProductsController inside the Controllers folder and then copy and paste the following code. The ProductsController handles all CRUD operations for products within the e-commerce system. It enables retrieving all products or individual product details along with their associated categories, adding new products, updating product information, and deleting products. This controller ensures that product data remains consistent and allows clients to perform essential product management and browsing functions.
using ECommerceAPI.Data;
using ECommerceAPI.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
namespace ECommerceAPI.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class ProductsController : ControllerBase
{
// Injected EF Core DbContext instance
private readonly ECommerceDbContext _context;
// Constructor with dependency injection of DbContext
public ProductsController(ECommerceDbContext context)
{
_context = context;
}
// GET: api/products
// Retrieves all products including their associated category
[HttpGet]
public async Task<IActionResult> GetAllProducts()
{
// Include Category navigation property, use AsNoTracking for better read performance
var products = await _context.Products
.Include(p => p.Category)
.AsNoTracking()
.ToListAsync();
// Return HTTP 200 OK with the list of products
return Ok(products);
}
// GET: api/products/{id}
// Retrieves a single product by ID including its category
[HttpGet("{id}")]
public async Task<IActionResult> GetProductById(int id)
{
// Find the product including category details, no tracking for read-only
var product = await _context.Products
.Include(p => p.Category)
.AsNoTracking()
.FirstOrDefaultAsync(p => p.ProductId == id);
// Return 404 Not Found if product does not exist
if (product == null)
return NotFound();
// Return 200 OK with the found product
return Ok(product);
}
// POST: api/products
// Creates a new product from the request body
[HttpPost]
public async Task<IActionResult> CreateProduct([FromBody] Product product)
{
// Validate incoming model using data annotations
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Verify the referenced category exists before adding product
var categoryExists = await _context.Categories.AnyAsync(c => c.CategoryId == product.CategoryId);
if (!categoryExists)
return BadRequest("Invalid CategoryId.");
// Add product to DbSet and save changes to database
await _context.Products.AddAsync(product);
await _context.SaveChangesAsync();
// Return 200 OK with created product including generated ID
return Ok(product);
}
// PUT: api/products/{id}
// Updates an existing product identified by ID with provided data
[HttpPut("{id}")]
public async Task<IActionResult> UpdateProduct(int id, [FromBody] Product updatedProduct)
{
// Validate that the URL ID matches the product ID in the request body
if (id != updatedProduct.ProductId)
return BadRequest("Product ID mismatch.");
// Validate the updated model
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Retrieve existing product from database
var existingProduct = await _context.Products.FindAsync(id);
if (existingProduct == null)
return NotFound();
// Validate referenced category exists
var categoryExists = await _context.Categories.AnyAsync(c => c.CategoryId == updatedProduct.CategoryId);
if (!categoryExists)
return BadRequest("Invalid CategoryId.");
// Update mutable properties of existing product
existingProduct.Name = updatedProduct.Name;
existingProduct.Description = updatedProduct.Description;
existingProduct.Price = updatedProduct.Price;
existingProduct.CategoryId = updatedProduct.CategoryId;
// Mark entity as updated and save changes
_context.Products.Update(existingProduct);
await _context.SaveChangesAsync();
// Return 204 No Content indicating successful update without response body
return NoContent();
}
// DELETE: api/products/{id}
// Deletes a product by ID
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteProduct(int id)
{
// Find the product to delete
var product = await _context.Products.FindAsync(id);
if (product == null)
return NotFound();
// Remove the product and save changes
_context.Products.Remove(product);
await _context.SaveChangesAsync();
// Return 204 No Content indicating successful deletion
return NoContent();
}
}
}
CustomersController: CRUD Operations for Customer
Create an Empty API controller named CustomersController inside the Controllers folder and then copy and paste the following code. This controller manages customer-related functionalities. It provides endpoints to fetch customer lists or individual customer details, register new customers, update customer profiles, and delete customers while enforcing business rules such as unique email addresses and preventing deletion if customers have existing orders. This centralizes customer management and maintains data integrity across the application.
using ECommerceAPI.Data;
using ECommerceAPI.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
namespace ECommerceAPI.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class CustomersController : ControllerBase
{
// Injected EF Core DbContext instance to interact with the database
private readonly ECommerceDbContext _context;
// Constructor with dependency injection for DbContext
public CustomersController(ECommerceDbContext context)
{
_context = context;
}
// GET: api/customers
// Retrieves all customers asynchronously from the database
[HttpGet]
public async Task<IActionResult> GetAlCustomers()
{
// Use AsNoTracking for performance when entities are only read, no updates
var customers = await _context.Customers.AsNoTracking().ToListAsync();
// Return 200 OK with the list of customers
return Ok(customers);
}
// GET: api/customers/{id}
// Retrieves a single customer by ID
[HttpGet("{id}")]
public async Task<IActionResult> GetCustomerById(int id)
{
// Find the customer by primary key asynchronously
var customer = await _context.Customers.FindAsync(id);
// If customer not found, return 404 Not Found
if (customer == null)
return NotFound();
// Return 200 OK with the customer data
return Ok(customer);
}
// POST: api/customers
// Creates a new customer record from the request body
[HttpPost]
public async Task<IActionResult> CreateCustomer([FromBody] Customer customer)
{
// Validate the incoming customer model based on data annotations
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Optional: Check if the email is already in use to ensure uniqueness
bool emailExists = await _context.Customers.AnyAsync(c => c.Email == customer.Email);
if (emailExists)
return BadRequest("Email already exists.");
// Add the new customer to the DbSet (tracked by DbContext)
await _context.Customers.AddAsync(customer);
// Save changes asynchronously to persist the new customer in database
await _context.SaveChangesAsync();
// Return 200 OK with the created customer (including generated ID)
return Ok(customer);
}
// PUT: api/customers/{id}
// Updates an existing customer identified by ID
[HttpPut("{id}")]
public async Task<IActionResult> UpdateCustomer(int id, [FromBody] Customer updatedCustomer)
{
// Check if the URL ID matches the customer ID in the payload
if (id != updatedCustomer.CustomerId)
return BadRequest("Customer ID mismatch.");
// Validate the updated customer model
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Retrieve the existing customer from the database
var existingCustomer = await _context.Customers.FindAsync(id);
// If customer does not exist, return 404 Not Found
if (existingCustomer == null)
return NotFound();
// Check if the updated email conflicts with another customer (excluding current one)
bool emailExists = await _context.Customers
.AnyAsync(c => c.Email == updatedCustomer.Email && c.CustomerId != id);
if (emailExists)
return BadRequest("Email already exists.");
// Update mutable properties
existingCustomer.FullName = updatedCustomer.FullName;
existingCustomer.Email = updatedCustomer.Email;
// Mark the entity as updated in the DbContext
_context.Customers.Update(existingCustomer);
// Persist changes asynchronously to the database
await _context.SaveChangesAsync();
// Return 204 No Content indicating successful update without response body
return NoContent();
}
// DELETE: api/customers/{id}
// Deletes a customer by ID
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteCustomer(int id)
{
// Find the customer to delete
var customer = await _context.Customers.FindAsync(id);
// If customer not found, return 404 Not Found
if (customer == null)
return NotFound();
// Optional: Prevent deletion if customer has existing orders
bool hasOrders = await _context.Orders.AnyAsync(o => o.CustomerId == id);
if (hasOrders)
return BadRequest("Cannot delete customer with existing orders.");
// Remove the customer entity from the DbSet
_context.Customers.Remove(customer);
// Save changes asynchronously to persist deletion
await _context.SaveChangesAsync();
// Return 204 No Content indicating successful deletion
return NoContent();
}
}
}
OrdersController: CRUD Operations for Customer
Create an Empty API controller named OrdersController inside the Controllers folder and then copy and paste the following code. The OrdersController facilitates the creation, retrieval, updating, and deletion of orders along with their related order items. It includes validation to ensure that customers and products exist before processing orders, calculates total order amounts, and manages complex operations like adding, updating, or removing order items within an order. This controller plays a crucial role in handling purchase transactions and maintaining accurate order data.
using ECommerceAPI.Data;
using ECommerceAPI.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
namespace ECommerceAPI.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class OrdersController : ControllerBase
{
// Injected EF Core DbContext instance for database operations
private readonly ECommerceDbContext _context;
// Constructor with dependency injection of DbContext
public OrdersController(ECommerceDbContext context)
{
_context = context;
}
// GET: api/orders
// Retrieves all orders including their order items and product details
[HttpGet]
public async Task<IActionResult> GetOrders()
{
// Use Include and ThenInclude to eagerly load related OrderItems and Products, and also Customer
var orders = await _context.Orders
.Include(o => o.OrderItems)
.ThenInclude(oi => oi.Product)
.Include(o => o.Customer)
.ToListAsync();
// Return HTTP 200 OK with list of orders including related data
return Ok(orders);
}
// GET: api/orders/{id}
// Retrieves a specific order by its ID, including order items and product details
[HttpGet("{id}")]
public async Task<IActionResult> GetOrder(int id)
{
// Find the order by ID including related entities, or return null if not found
var order = await _context.Orders
.Include(o => o.OrderItems)
.ThenInclude(oi => oi.Product)
.Include(o => o.Customer)
.FirstOrDefaultAsync(o => o.OrderId == id);
// If no order is found, return 404 Not Found
if (order == null)
return NotFound();
// Return 200 OK with the order and related details
return Ok(order);
}
// POST: api/orders
// Create a new order along with its order items
[HttpPost]
public async Task<IActionResult> CreateOrder([FromBody] Order order)
{
// Validate the incoming model using data annotations
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Validate the referenced customer exists
var customerExists = await _context.Customers.AnyAsync(c => c.CustomerId == order.CustomerId);
if (!customerExists)
return BadRequest("Invalid CustomerId.");
// Validate each product in order items exists
foreach (var item in order.OrderItems)
{
var productExists = await _context.Products.AnyAsync(p => p.ProductId == item.ProductId);
if (!productExists)
return BadRequest($"Invalid ProductId: {item.ProductId}");
}
// Calculate order amount based on sum of (quantity * unit price) for all order items
order.OrderAmount = order.OrderItems.Sum(i => i.Quantity * i.UnitPrice);
// Set the order date to current UTC time
order.OrderDate = DateTime.UtcNow;
// Add the order entity along with its related order items to the DbSet
await _context.Orders.AddAsync(order);
// Save changes asynchronously to the database
await _context.SaveChangesAsync();
// Return HTTP 200 OK with the created order including generated IDs
return Ok(order);
}
// PUT: api/orders/{id}
// Update an existing order and its order items
[HttpPut("{id}")]
public async Task<IActionResult> UpdateOrder(int id, [FromBody] Order updatedOrder)
{
// Check if the ID in URL matches the order ID in the request body
if (id != updatedOrder.OrderId)
return BadRequest("Order ID mismatch.");
// Validate the updated model
if (!ModelState.IsValid)
return BadRequest(ModelState);
// Retrieve the existing order including related order items
var existingOrder = await _context.Orders
.Include(o => o.OrderItems)
.FirstOrDefaultAsync(o => o.OrderId == id);
// If order not found, return 404 Not Found
if (existingOrder == null)
return NotFound();
// Validate the customer exists
var customerExists = await _context.Customers.AnyAsync(c => c.CustomerId == updatedOrder.CustomerId);
if (!customerExists)
return BadRequest("Invalid CustomerId.");
// Validate all products in updated order items exist
foreach (var item in updatedOrder.OrderItems)
{
var productExists = await _context.Products.AnyAsync(p => p.ProductId == item.ProductId);
if (!productExists)
return BadRequest($"Invalid ProductId: {item.ProductId}");
}
// Update scalar properties on the order
existingOrder.CustomerId = updatedOrder.CustomerId;
existingOrder.OrderDate = updatedOrder.OrderDate; // You may choose to keep existing date instead
// Update the total order amount by recalculating from updated items
existingOrder.OrderAmount = updatedOrder.OrderItems.Sum(i => i.Quantity * i.UnitPrice);
// Handle removal of deleted order items
foreach (var existingItem in existingOrder.OrderItems.ToList())
{
// If an existing item is not present in updated list, remove it
if (!updatedOrder.OrderItems.Any(i => i.OrderItemId == existingItem.OrderItemId))
{
_context.OrderItems.Remove(existingItem);
}
}
// Update existing items and add new items
foreach (var updatedItem in updatedOrder.OrderItems)
{
// Try to find matching existing order item by ID
var existingItem = existingOrder.OrderItems
.FirstOrDefault(i => i.OrderItemId == updatedItem.OrderItemId);
if (existingItem != null)
{
// Update properties of the existing item
existingItem.ProductId = updatedItem.ProductId;
existingItem.Quantity = updatedItem.Quantity;
existingItem.UnitPrice = updatedItem.UnitPrice;
}
else
{
// This is a new order item, add it to the existing order
existingOrder.OrderItems.Add(new OrderItem
{
ProductId = updatedItem.ProductId,
Quantity = updatedItem.Quantity,
UnitPrice = updatedItem.UnitPrice
});
}
}
// Mark the order entity as updated
_context.Orders.Update(existingOrder);
// Save changes asynchronously to the database
await _context.SaveChangesAsync();
// Return 204 No Content to indicate successful update with no body
return NoContent();
}
// DELETE: api/orders/{id}
// Deletes an order by ID, cascade deletes related order items if configured
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteOrder(int id)
{
// Find the order entity by ID
var order = await _context.Orders.FindAsync(id);
// If order not found, return 404 Not Found
if (order == null)
return NotFound();
// Remove the order entity from DbSet
_context.Orders.Remove(order);
// Save changes asynchronously
await _context.SaveChangesAsync();
// Return 204 No Content to indicate successful deletion
return NoContent();
}
}
}
Observing Limitations in This Approach
When you build an application by placing all your data access logic directly inside API controllers, it may work fine initially for small, simple projects. But as the application grows in complexity and size, this approach quickly becomes unmanageable and problematic. Let me explain why, using real-world scenarios to highlight the challenges.
Controllers Take on Too Many Responsibilities
Imagine your API controller handles HTTP requests and manages all database queries, validation, business rules, and error handling. This means your controller has multiple jobs at once: accepting requests, querying the database, applying business logic, and formatting responses.
For example, consider a controller method that retrieves orders for a customer. It might need to validate the customer ID, fetch orders and order items, calculate totals, handle exceptions, and format data for the client. As you add more features, these methods grow longer and more complex, mixing unrelated tasks together.
This violates the Single Responsibility Principle, a fundamental design guideline that says a class should have only one reason to change. When your controller has too many responsibilities, it becomes harder to read, maintain, and debug. Making a change to the data access part risks breaking the request handling part, and vice versa.
Repeated Code and Lost Opportunities for Reuse
Imagine you have multiple controllers, say one for customers, one for products, and one for orders. Many of these controllers will implement similar functionality: fetching data with filtering, sorting, pagination, or validating entities before updates.
Without a centralized place to put this logic, each controller must reinvent these common operations on its own. For example, pagination might be implemented slightly differently in the products controller versus the orders controller. One controller might forget to check for invalid page numbers, leading to bugs.
This repetition wastes development effort, increases the chance of inconsistencies, and slows down bug fixes. If you want to change the pagination logic, you need to update every controller where it’s duplicated, which is error-prone and time-consuming.
Difficulty Adding Cross-Cutting Features
As your application matures, you may need to add features that affect many parts of the system, such as caching to improve performance, logging to track usage and errors, or transaction management to ensure data consistency.
If your data access logic is split across many controllers, you must modify each one to integrate these features. For example, to add caching, you have to split caching code throughout all controller methods that fetch data. This leads to complex controllers full of unrelated concerns, making the code harder to understand and maintain.
Also, because these changes touch so many places, you risk introducing bugs or inconsistencies. The more places you have to edit, the higher the chance that something breaks or behaves unexpectedly.
Challenges with Testing and Future Maintenance
Finally, tightly coupling controllers with EF Core’s DbContext makes unit testing challenging. Mocking complex EF Core objects or setting up in-memory databases adds complexity to our tests. Without proper abstractions, we can’t easily test controllers in isolation, reducing test reliability and developer confidence.
Moreover, suppose in the future you want to switch from EF Core to another data access technology like Dapper, or move to a microservices architecture with separate data stores. With data access logic embedded in controllers, this change will require rewriting large portions of your codebase, slowing down development and increasing risk.
Example: The Busy Waiter Who Also Cooks and Cleans
Imagine a small café where the waiter takes orders, cooks the food, cleans the tables, and manages payments, basically doing everything. At first, when the café is small and only a few customers come in, this works fine. The waiter can handle all these tasks. But as more customers arrive, the waiter gets overwhelmed managing all these roles.
- Mistakes happen: orders get mixed up, tables don’t get cleaned on time, and customers wait longer.
- It becomes difficult to train a new waiter because they also need to learn to cook, clean, and take payments.
- If the café wants to improve by adding a new payment system or special menu, the waiter must learn and update all parts, which slows everything down.
This is like a controller directly using DbContext: The controller does everything, handling requests and managing database operations. At first, it’s simple, but as complexity grows, it becomes inefficient, error-prone, and hard to maintain.
Example: The One-Person Handyman Fixing Everything
Imagine you hire a handyman who fixes plumbing, electrical wiring, and carpentry in your house, all by himself. For small jobs, one person doing it all saves coordination time and seems convenient. But when your house needs more complex repairs or renovations, the handyman can’t keep up with all the specialized tasks.
- If you want to upgrade the electrical system or install smart devices, the handyman might not have the skills or tools.
- Plus, you can’t get multiple tasks done at once because he works sequentially.
- You also risk delays or mistakes if he has to manage everything alone.
This is like your controller tightly coupled to DbContext: It tries to handle all aspects of data management itself, without specialized layers to take over. When the project grows or requirements change, the controller can’t adapt easily or handle the load, making progress slow and error-prone.
What is a better alternative?
Just like a good restaurant hires specialized chefs, waiters, and cleaners, or a homeowner hires separate experts for plumbing, electrical, and carpentry, software projects benefit greatly from separating concerns into distinct layers:
- Controllers focus solely on handling HTTP requests and user interactions, acting as the entry point to the application.
- Services contain business rules and application logic, coordinating between controllers and repositories.
- Repositories abstract and encapsulate all data access logic, interacting directly with the database or ORM.
This layered approach is exactly what the Repository Pattern implements. The Repository Pattern creates a dedicated data access layer with well-defined interfaces that hide the details of database operations from the rest of the application. By doing so, it decouples business logic from data storage specifics, making the system more scalable, maintainable, and easier to evolve over time.
With repositories in place, changes to the data source or queries are managed in the repository classes without impacting controllers or services. This improves testability by allowing mocking of repositories during unit testing. It also simplifies adding features like caching, logging, or transactions within the repository layer, without cluttering controllers.
Next, we will explore how to implement the Repository Pattern in our application step-by-step, starting with defining repository interfaces, concrete implementations using EF Core, and modifying controllers to use these repositories for clean, maintainable data access.
In the next article, I will discuss implementing the Non-Generic Repository Pattern in ASP.NET Core Web API Applications. In this article, I explain Without Using the Repository Pattern in an ASP.NET Core Web API Application with Examples. I hope you enjoy this article on Without Using Repository Pattern in ASP.NET Core Web API.
About the Author: Pranaya Rout
Pranaya Rout has published more than 3,000 articles in his 11-year career. Pranaya Rout has very good experience with Microsoft Technologies, Including C#, VB, ASP.NET MVC, ASP.NET Web API, EF, EF Core, ADO.NET, LINQ, SQL Server, MYSQL, Oracle, ASP.NET Core, Cloud Computing, Microservices, Design Patterns and still learning new technologies.