Brokers structure

[Arnab-Developer]

The example which you provided in the Asynchronization Abstraction section is good, but I prefer the structure in a slightly different manner.

IStorageBroker.cs

public interface IStorageBroker<T>
{
    public Task InsertAsync(T newRecord);
    public Task UpdateAsync(T existingRecord);
    public Task DeleteAsync(int id);
    public Task<IEnumerable<T>> SelectAllAsync();
    public Task<T> SelectByIdAsync(int id);
}

IStudentStorageBroker.cs

public interface IStudentStorageBroker : IStorageBroker<Student>
{
}

StudentStorageBroker.cs

public class StudentStorageBroker(EfDbContext context) : IStudentStorageBroker
{
    private EfDbContext _context = context;

    public async Task InsertAsync(Student newRecord)
    {
        await _context.Students.AddAsync(newRecord);
        await _context.SaveChangesAsync();
    }

    public async Task UpdateAsync(Student existingRecord)
    {
        var student = await _context.Students.SingleAsync(s => s.Id == id);
        student.Name = existingRecord.Name;
        await _context.SaveChangesAsync();
    }

    public async Task DeleteAsync(int id)
    {
        var student = await SelectByIdAsync(id);
        _context.Students.Remove(student);
        await _context.SaveChangesAsync();
    }

    public async Task<IEnumerable<Student>> SelectAllAsync()
    {
        var students = await _context.Students.ToListAsync();
        return students;
    }

    public async Task<Student> SelectByIdAsync(int id)
    {
        var student = await _context.Students.SingleAsync(s => s.Id == id);
        return student;
    }
}

[glhays]

@Arnab-Developer Have you considered the effect your suggestion may cause on Foundations like the validation logic?
I am not sure your variable naming fits with being explicit Student => newRecord at least if it was newStudentRecord the explicitly is there. As far as documenting The Standard I feel being explicit needs to satisfy the whole not the individual preferences. Your welcome to name a variable what you want in your personal projects, but I think in a Standard review your naming may invite a change. Remember this is partial class that is dealing strictly with a Student.

[LBoullosa]

More considerations to add what @glhays explained,

1. this way of thinking is based on Repository Pattern. StorageBroker doesn´t follow exactly same principles than Repository Pattern.
   1.7.0 Is the Brokers Pattern the same as the Repository Pattern?

2. This approach assumes, all the entities should accept an insert, update, delete or select, which it hasn´t to be that way.

3. Brokers doesn´t allow sequencing or any other of algorithm, how do you test drive a broker? In The Standard, Brokers aren´t test driven, because they are abstraction to tie an external system in our system (aka local system)