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

Add ICatalogRepository interface and design comments

Browse Source 
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).
This commit is contained in:
OlgunR
2026-01-19 09:12:16 +01:00
parent 9387db9824
commit 45e5327148
1 changed files with 15 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,4 +1,4 @@
using DbFirst.Domain.Entities; using DbFirst.Domain.Entities;
namespace DbFirst.Domain.Repositories; namespace DbFirst.Domain.Repositories;
@@ -6,12 +6,22 @@ namespace DbFirst.Domain.Repositories;
/* Copilot's Response: /* Copilot's Response:
A generic Repository<T> isn’t really worthwhile here: 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. • 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. • 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. */ • 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
/* 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 public interface ICatalogRepository
{ {
Task<List<VwmyCatalog>> GetAllAsync(CancellationToken cancellationToken = default); Task<List<VwmyCatalog>> GetAllAsync(CancellationToken cancellationToken = default);