AppStd/DbFirst
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add comments on generic repo pattern limitations

Browse Source 
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.
This commit is contained in:
OlgunR
2026-01-19 09:07:41 +01:00
parent ef76599bce
commit 9387db9824
2 changed files with 16 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
DbFirst.Domain/Repositories/ICatalogRepository.cs
View File

@@ -3,6 +3,14 @@ using DbFirst.Domain.Entities;
namespace DbFirst.Domain.Repositories; namespace DbFirst.Domain.Repositories;
// TODO: instead of creating interface per entity, consider using generic repository pattern (eg. IRepository<T>) to reduce code duplication. // TODO: instead of creating interface per entity, consider using generic repository pattern (eg. IRepository<T>) to reduce code duplication.
/* Copilot's Response:
A generic Repository<T> 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 // TODO: move to application layer as a part of clean architecture
public interface ICatalogRepository public interface ICatalogRepository
{ {

8
DbFirst.Infrastructure/Repositories/CatalogRepository.cs
View File

@@ -6,6 +6,7 @@ using Microsoft.EntityFrameworkCore;
using System; using System;
using System.Collections.Generic; using System.Collections.Generic;
using System.Data; using System.Data;
using System.Diagnostics.Metrics;
using System.Text; using System.Text;
using System.Threading.Channels; using System.Threading.Channels;
using static Microsoft.EntityFrameworkCore.DbLoggerCategory; 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<T>) to reduce code duplication. // TODO: instead of creating implementation of repository per entity, consider using generic repository pattern (eg. Repository<T>) to reduce code duplication.
/* Copilot's Response:
A generic Repository<T> 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 public class CatalogRepository : ICatalogRepository
{ {
private readonly ApplicationDbContext _db; private readonly ApplicationDbContext _db;