From 9387db98240d630848516102420ea7a049934d95 Mon Sep 17 00:00:00 2001 From: OlgunR Date: Mon, 19 Jan 2026 09:07:41 +0100 Subject: [PATCH] Add comments on generic repo pattern limitations Added Copilot comments explaining why a generic repository is unsuitable due to stored procedure complexities and asymmetric CRUD operations. Suggested keeping specialized repositories and extracting helpers for reuse. Also added a TODO to move the interface to the application layer for clean architecture. --- DbFirst.Domain/Repositories/ICatalogRepository.cs | 8 ++++++++ DbFirst.Infrastructure/Repositories/CatalogRepository.cs | 8 ++++++++ 2 files changed, 16 insertions(+) diff --git a/DbFirst.Domain/Repositories/ICatalogRepository.cs b/DbFirst.Domain/Repositories/ICatalogRepository.cs index f968a01..020353f 100644 --- a/DbFirst.Domain/Repositories/ICatalogRepository.cs +++ b/DbFirst.Domain/Repositories/ICatalogRepository.cs @@ -3,6 +3,14 @@ using DbFirst.Domain.Entities; namespace DbFirst.Domain.Repositories; // TODO: instead of creating interface per entity, consider using generic repository pattern (eg. IRepository) to reduce code duplication. + +/* Copilot's Response: + +A generic Repository isn’t really worthwhile here: + • Reads from the view are generic, but inserts/updates/deletes go through stored procedures with special parameters/output GUIDs.You’d need lots of exceptions/overrides—little gain. + • Operations aren’t symmetric (separate procs for insert/update/delete with output handling and reload), so a one-size-fits-all CRUD pattern doesn’t fit well. + • Better to keep the specialized repo.If you want reuse, extract small helpers (e.g., for proc calls/output parameters/reload) instead of forcing a generic repository. */ + // TODO: move to application layer as a part of clean architecture public interface ICatalogRepository { diff --git a/DbFirst.Infrastructure/Repositories/CatalogRepository.cs b/DbFirst.Infrastructure/Repositories/CatalogRepository.cs index ae2d299..d80d5db 100644 --- a/DbFirst.Infrastructure/Repositories/CatalogRepository.cs +++ b/DbFirst.Infrastructure/Repositories/CatalogRepository.cs @@ -6,6 +6,7 @@ using Microsoft.EntityFrameworkCore; using System; using System.Collections.Generic; using System.Data; +using System.Diagnostics.Metrics; using System.Text; using System.Threading.Channels; using static Microsoft.EntityFrameworkCore.DbLoggerCategory; @@ -15,6 +16,13 @@ namespace DbFirst.Infrastructure.Repositories; // TODO: instead of creating implementation of repository per entity, consider using generic repository pattern (eg. Repository) to reduce code duplication. +/* Copilot's Response: + +A generic Repository isn’t really worthwhile here: + • Reads from the view are generic, but inserts/updates/deletes go through stored procedures with special parameters/output GUIDs.You’d need lots of exceptions/overrides—little gain. + • Operations aren’t symmetric (separate procs for insert/update/delete with output handling and reload), so a one-size-fits-all CRUD pattern doesn’t fit well. + • Better to keep the specialized repo.If you want reuse, extract small helpers (e.g., for proc calls/output parameters/reload) instead of forcing a generic repository. */ + public class CatalogRepository : ICatalogRepository { private readonly ApplicationDbContext _db;