Expand usings; add note on generic vs per-entity repos
Expanded using directives to support additional dependencies in CatalogRepository.cs. Added a detailed comment explaining why per-entity repository implementations are preferred over a generic CRUD base service in this context, due to unique domain logic and stored procedure requirements. No functional code changes were made.
This commit is contained in:
@@ -1,12 +1,35 @@
|
|||||||
using DbFirst.Domain.Repositories;
|
using Azure;
|
||||||
using DbFirst.Domain.Entities;
|
using DbFirst.Domain.Entities;
|
||||||
|
using DbFirst.Domain.Repositories;
|
||||||
using Microsoft.Data.SqlClient;
|
using Microsoft.Data.SqlClient;
|
||||||
using Microsoft.EntityFrameworkCore;
|
using Microsoft.EntityFrameworkCore;
|
||||||
|
using System;
|
||||||
|
using System.Collections.Generic;
|
||||||
using System.Data;
|
using System.Data;
|
||||||
|
using System.Text;
|
||||||
|
using System.Threading.Channels;
|
||||||
|
using static Microsoft.EntityFrameworkCore.DbLoggerCategory;
|
||||||
|
using static System.Runtime.InteropServices.JavaScript.JSType;
|
||||||
|
|
||||||
namespace DbFirst.Infrastructure.Repositories;
|
namespace DbFirst.Infrastructure.Repositories;
|
||||||
|
|
||||||
// TODO: instead of creating implementation of repository per entity, consider using generic repository pattern (eg. Repository<T>) to reduce code duplication.
|
// TODO: instead of creating implementation of repository per entity, consider using generic repository pattern (eg. Repository<T>) 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 class CatalogRepository : ICatalogRepository
|
public class CatalogRepository : ICatalogRepository
|
||||||
{
|
{
|
||||||
private readonly ApplicationDbContext _db;
|
private readonly ApplicationDbContext _db;
|
||||||
|
|||||||
Reference in New Issue
Block a user