ef76599bce
Added detailed comments in CatalogService and ICatalogService explaining why a generic CRUD base service or repository is not suitable for this solution, due to entity-specific domain logic and stored procedure usage. Removed the previous Copilot comment from CatalogRepository. No functional changes; updates are for architectural clarity.
28 lines
1.5 KiB
C#
28 lines
1.5 KiB
C#
namespace DbFirst.Application.Catalogs;
|
||
|
||
//TODO: create generic service to reduce code duplication
|
||
|
||
/* Copilot's Response:
|
||
A generic CRUD base service adds little value in your case:
|
||
|
||
Pros:
|
||
• Less boilerplate for simple entities without special logic.
|
||
• Uniform CRUD signatures.
|
||
|
||
Cons/Practical here:
|
||
• Domain logic differs per entity(unique title check, setting audit fields, forbidding title changes, stored procs with output GUID).
|
||
• Generic services tend to be diluted by virtual methods/hooks for special cases—ending up with per-entity overrides and little real gain.
|
||
• With stored procedures and output parameters, the pattern doesn’t fit cleanly because operations aren’t symmetric (separate procs for insert/update/delete).
|
||
|
||
Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
|
||
you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
|
||
|
||
public interface ICatalogService
|
||
{
|
||
Task<List<CatalogReadDto>> GetAllAsync(CancellationToken cancellationToken = default);
|
||
Task<CatalogReadDto?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
|
||
Task<CatalogReadDto?> CreateAsync(CatalogWriteDto dto, CancellationToken cancellationToken = default);
|
||
Task<CatalogReadDto?> UpdateAsync(int id, CatalogWriteDto dto, CancellationToken cancellationToken = default);
|
||
Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default);
|
||
}
|