API Controller Design - How much business logic is too much logic? Checking for user in database before inserting a new record

Question

I'm writing a REST API using ASP.NET Core & Entity Framework Core. My controllers so far have minimal logic, typically deferring to a service layer that handles the usual database operations.

My API will be consumed by a Discord bot, and I want to be able to automatically register users in my database when they issue a command that would essentially end up inserting a new record into one of the database tables:

[HttpPost]
public async Task<ActionResult<recordDto>> CreateRecord(CreateRecordDto recordDto)
{
    var record = new Record
    {
        Name = recordDto.Name,
        Alias = recordDto.Alias,
        UserId = recordDto.UserId,
        ServerId = recordDto.ServerId,
    };
    
    try
    {
        await _service.CreateRecord(record);
    }
    catch (status.ConflictException)
    {
        return Conflict();
    }
    catch (DbUpdateException)
    {
        throw new Exception("Error adding record.");
    }

    return CreatedAtAction("Test", new { id = record.Id }, record);
}

Prior to that, however I need to check whether the user is even present in the database. That's easy, as I have another service I can use to check for that condition. However I'm hesitant to place this logic into the controller as it would increase the dependencies my controller requires, and introduce more business logic which I understand the controller shouldn't be handling. Am I over thinking my design? Where exactly should this logic be handled?

Answer 1

Whilst I do not know what business this API is intended for, what you're showing and describing seems more like a CRUD API. I do not see any business logic here, unless you are automating a process where a business rule is something like "A user cannot be added twice" .

But this doesn't take away from your question. You worry about too many dependencies and where the correct place is this logic should be handled.

It is important to understand why there are certain rules. Developers worry that if there are too many dependencies, a class has too many responsibilities and therefore becomes inflexible, difficult to test and difficult to change. This is a valid concern, but always ask yourself if it applies to your situation; will your API ever do anything else than this? Does it, therefore, need to be flexible? The adding of an extra layer does not come for free, so a simple design could be kept simple (even when breaking the "rules").

In your case I indeed think you are overthinking your design considering the dependencies. If I could give you a tip: handle the error handling somewhere else (in a filter attribute or something), so you don't have to copy that in every endpoint. But, only if you intend to have more than one!