Remove CatalogService and ICatalogService implementations
Eliminated the catalog service layer by deleting both CatalogService.cs and ICatalogService.cs. This removes all catalog-related CRUD operations, mapping logic, repository interactions, and domain-specific checks. Also removed related comments and TODOs regarding generic services and CQRS.
This commit is contained in:
@@ -1,78 +0,0 @@
|
||||
using AutoMapper;
|
||||
using DbFirst.Application.Repositories;
|
||||
using DbFirst.Domain.Entities;
|
||||
using DbFirst.Domain;
|
||||
|
||||
namespace DbFirst.Application.Catalogs;
|
||||
|
||||
//TODO: create generic service to reduce code duplication
|
||||
//TODO (TR): kod tekrar?n? azaltmak için generic bir servis/basit CRUD altyap?s? ekleyin
|
||||
//TODO: implement CQRS pattern with MediatR
|
||||
//TODO (TR): CQRS desenini MediatR ile uygulay?n
|
||||
public class CatalogService : ICatalogService
|
||||
{
|
||||
private readonly ICatalogRepository _repository;
|
||||
private readonly IMapper _mapper;
|
||||
|
||||
public CatalogService(ICatalogRepository repository, IMapper mapper)
|
||||
{
|
||||
_repository = repository;
|
||||
_mapper = mapper;
|
||||
}
|
||||
|
||||
public async Task<List<CatalogReadDto>> GetAllAsync(CancellationToken cancellationToken = default)
|
||||
{
|
||||
var items = await _repository.GetAllAsync(cancellationToken);
|
||||
return _mapper.Map<List<CatalogReadDto>>(items);
|
||||
}
|
||||
|
||||
public async Task<CatalogReadDto?> GetByIdAsync(int id, CancellationToken cancellationToken = default)
|
||||
{
|
||||
var item = await _repository.GetByIdAsync(id, cancellationToken);
|
||||
return item == null ? null : _mapper.Map<CatalogReadDto>(item);
|
||||
}
|
||||
|
||||
public async Task<CatalogReadDto?> CreateAsync(CatalogWriteDto dto, CancellationToken cancellationToken = default)
|
||||
{
|
||||
var existing = await _repository.GetByTitleAsync(dto.CatTitle, cancellationToken);
|
||||
if (existing != null)
|
||||
{
|
||||
return null;
|
||||
}
|
||||
|
||||
var entity = _mapper.Map<VwmyCatalog>(dto);
|
||||
entity.AddedWho = "system";
|
||||
entity.AddedWhen = DateTime.UtcNow;
|
||||
entity.ChangedWho = "system";
|
||||
entity.ChangedWhen = DateTime.UtcNow;
|
||||
|
||||
var created = await _repository.InsertAsync(entity, cancellationToken);
|
||||
return _mapper.Map<CatalogReadDto>(created);
|
||||
}
|
||||
|
||||
public async Task<CatalogReadDto?> UpdateAsync(int id, CatalogWriteDto dto, CancellationToken cancellationToken = default)
|
||||
{
|
||||
var existing = await _repository.GetByIdAsync(id, cancellationToken);
|
||||
if (existing == null)
|
||||
{
|
||||
return null;
|
||||
}
|
||||
|
||||
var entity = _mapper.Map<VwmyCatalog>(dto);
|
||||
entity.Guid = id;
|
||||
entity.CatTitle = dto.UpdateProcedure == CatalogUpdateProcedure.Update ? existing.CatTitle : dto.CatTitle;
|
||||
entity.AddedWho = existing.AddedWho;
|
||||
entity.AddedWhen = existing.AddedWhen;
|
||||
entity.ChangedWho = "system";
|
||||
entity.ChangedWhen = DateTime.UtcNow;
|
||||
|
||||
var procedure = dto.UpdateProcedure;
|
||||
var updated = await _repository.UpdateAsync(id, entity, procedure, cancellationToken);
|
||||
return updated == null ? null : _mapper.Map<CatalogReadDto>(updated);
|
||||
}
|
||||
|
||||
public async Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default)
|
||||
{
|
||||
return await _repository.DeleteAsync(id, cancellationToken);
|
||||
}
|
||||
}
|
||||
@@ -1,27 +0,0 @@
|
||||
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);
|
||||
}
|
||||
Reference in New Issue
Block a user