From 45e532714813614e3de285907ab0c9ce32f14880 Mon Sep 17 00:00:00 2001 From: OlgunR Date: Mon, 19 Jan 2026 09:12:16 +0100 Subject: [PATCH] Add ICatalogRepository interface and design comments Added ICatalogRepository with async catalog retrieval methods. Included detailed comments on repository design patterns and clean architecture layer placement, recommending interface stays in Domain. Fixed file encoding (added BOM). --- .../Repositories/ICatalogRepository.cs | 20 ++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/DbFirst.Domain/Repositories/ICatalogRepository.cs b/DbFirst.Domain/Repositories/ICatalogRepository.cs index 020353f..bd50be8 100644 --- a/DbFirst.Domain/Repositories/ICatalogRepository.cs +++ b/DbFirst.Domain/Repositories/ICatalogRepository.cs @@ -1,4 +1,4 @@ -using DbFirst.Domain.Entities; +using DbFirst.Domain.Entities; namespace DbFirst.Domain.Repositories; @@ -6,12 +6,22 @@ namespace DbFirst.Domain.Repositories; /* 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. */ +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 + +/* Copilot's Response: + + • Common: Keep the interface in the Domain layer, implementation in Infrastructure. Domain defines the data access contract, Infrastructure provides the implementation. + That matches typical DDD/Clean Architecture. + • Alternative: Move the interface to the Application layer. Then only Application depends on Infrastructure, Domain stays isolated from infra contracts. + Pro: Domain contains only models/rules. + Con: If Domain logic needs repos, it would depend on Application, weakening the layer separation. + Recommendation: Keep the interface in Domain. It’s conventional, clean, and avoids a Domain -> Application dependency. Implementation stays in Infrastructure. */ + public interface ICatalogRepository { Task> GetAllAsync(CancellationToken cancellationToken = default);