Is creating an entity in a database considered to be business logic?

Question

According to my (perhaps incorrect) understanding business logic includes saving/updating entities in the database, as well as connecting with any 3rd party API's or using services and should therefore reside in the Model in MVC architecture. The controller should call model methods, and is responsible for application-wide logic, like authentication, some global data validation and response to the client.

Because I'm developing in C# I read the official Microsoft article recommendation:

Business logic should reside in services and classes within the Models folder.

However, in another Microsoft sample .NET project creating an entity is done directly in the controller (PostTodoItem). So I'm wondering why isn't this code inside the model itself? In my opinion the model should contain the method AddTodoItem which inserts a new todo item in the database. In theory adding an entity can be quite complex like validation, updating other models that's why I thought this code shouldn't reside directly in the controller.

---

EDIT: according to the link which @Christophe shared the repository pattern indeed offers an abstraction over data access layer. So in the repository pattern one would have:

public Buyer Add(Buyer buyer)
{
    return _context.Buyers.Add(buyer).Entity;
}

where the controller would use the repository class Add() instead of directly calling entiry framework's Add(). The link also mentions that the repository pattern enables easier unit-testing because it's easier to mock repository methods than mock the context of entity framework. However, accessing context directly in the controller is also a valid option according to the same link.

Answer 1

Creating an entity in the database does not sound like business logic but like data access layer (or data source depending on your architectural reference model).

Answer 2

Generally the persistence of data into the data source, including creating an entity in the database should be the concern of the data access layer.

When thinking about Business logic, I tend to refer them as the "domain" information that business-people care about, separating it from mere technicalities like how we store entity in a database or how to render it on a screen. In other words, if I decide to change from using MySql to another database server, even a non-relational database, I will often need to update the data access layer, and ideally shouldn't have to update the business logic - because business logic shouldn't care about how you create the foreign key and save it into the database.

In the Microsoft sample you mentioned, seems they just skip adding a service layer for simplicity. Usually, you will have something like Controller -> Domain Service -> Data Access Layer and most of the business logic will reside in the Domain Service, not the Controller.

But having said that, if the app is very simple, it is totally fine to just have the Controller contain the business logic and call the Data Access layer directly.

Answer 3

As with most things, precision is key here.

The actual creation of the entity, as established in the currently accepted answer, is a DAL (data layer) responsibility.

However, the decision that an entity needs to be created, and the decision which data should be stored in this entity, those are indeed BLL (business layer) responsibilities.

To build a house, you both need a builder and a future house owner (who hires the builder and tells them what to build and where). Your BLL is the house owner, your DAL is the builder.