8d3783cfec
- Make CORS policy environment-aware: allow any origin in development, restrict to configured origins in production. - Add detailed comments in CatalogService.cs and ICatalogRepository.cs discussing generic CRUD services, CQRS with MediatR, and repository interface placement, including both Copilot's and Hakan's perspectives. - No functional changes to service or repository logic.
47 lines
2.9 KiB
C#
47 lines
2.9 KiB
C#
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. */
|
||
|
||
|
||
/* Hakan's Response:
|
||
* I think it still makes sense. An execute SQL method can be added to repository. The relevant SQL can be executed in the application layer.
|
||
* Because the application layer is no longer dependent on a method like CreateAsync. It is now directly dependent on that procedure.
|
||
*/
|
||
|
||
// 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. */
|
||
|
||
/* Hakan's Response:
|
||
* I don't think there's any point in keeping repository interfaces in the domain layer. These interfaces will be used in the application layer, not the domain layer.
|
||
* Furthermore, this is how they are used in the most popular clean architecture pattern.
|
||
* See: https://github.com/jasontaylordev/CleanArchitecture/blob/main/src/Infrastructure/Identity/IdentityService.cs
|
||
*/
|
||
|
||
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, CatalogUpdateProcedure procedure, CancellationToken cancellationToken = default);
|
||
Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default);
|
||
}
|