9387db9824
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.
24 lines
1.5 KiB
C#
24 lines
1.5 KiB
C#
using DbFirst.Domain.Entities;
|
||
|
||
namespace DbFirst.Domain.Repositories;
|
||
|
||
// 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
|
||
public interface ICatalogRepository
|
||
{
|
||
Task<List<VwmyCatalog>> GetAllAsync(CancellationToken cancellationToken = default);
|
||
Task<VwmyCatalog?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
|
||
Task<VwmyCatalog?> GetByTitleAsync(string title, CancellationToken cancellationToken = default);
|
||
Task<VwmyCatalog> InsertAsync(VwmyCatalog catalog, CancellationToken cancellationToken = default);
|
||
Task<VwmyCatalog?> UpdateAsync(int id, VwmyCatalog catalog, CancellationToken cancellationToken = default);
|
||
Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default);
|
||
}
|