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.Repositories;
|
||||
using Microsoft.Data.SqlClient;
|
||||
using Microsoft.EntityFrameworkCore;
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
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;
|
||||
|
||||
// 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
|
||||
{
|
||||
private readonly ApplicationDbContext _db;
|
||||
|
||||
Reference in New Issue
Block a user