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

Support selecting update procedure for catalog updates

Browse Source 
Added CatalogUpdateProcedure enum to domain. CatalogWriteDto now includes UpdateProcedure property in both application and BlazorWasm layers. Catalogs.razor form allows users to choose between PRTBMY_CATALOG_UPDATE and PRTBMY_CATALOG_SAVE when editing. Repository, service, and handler layers updated to pass and use the selected procedure. Default remains Update. Updated comments and TODOs for clarity and future refactoring.
This commit is contained in:
OlgunR
2026-01-19 11:10:19 +01:00
parent 45e5327148
commit 4fbcd0dc11
9 changed files with 43 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
DbFirst.Domain/CatalogUpdateProcedure.cs Normal file
View File

@@ -0,0 +1,7 @@
namespace DbFirst.Domain;
public enum CatalogUpdateProcedure
{
Update = 0,
Save = 1
}

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

@@ -1,33 +1,14 @@
using DbFirst.Domain.Entities;
using DbFirst.Domain;
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
/* 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<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<VwmyCatalog?> UpdateAsync(int id, VwmyCatalog catalog, CatalogUpdateProcedure procedure, CancellationToken cancellationToken = default);
Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default);
}