166acea8b1
Added a generic IRepository<T> interface for common CRUD operations and updated ICatalogRepository to inherit from it, removing redundant methods. Updated CatalogRepository to implement the new interface. Cleaned up DbFirst.Domain.csproj by removing an unused folder reference. These changes improve code reuse and align with clean architecture practices.
42 lines
2.6 KiB
C#
42 lines
2.6 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. */
|
||
|
||
|
||
/* 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 : IRepository<VwmyCatalog>
|
||
{
|
||
Task<VwmyCatalog?> GetByTitleAsync(string title, CancellationToken cancellationToken = default);
|
||
Task<VwmyCatalog?> UpdateAsync(int id, VwmyCatalog catalog, CatalogUpdateProcedure procedure, CancellationToken cancellationToken = default);
|
||
}
|