I know there are thousands articles about it and I read many of them but I am still not sure what to do it my specific case.

I am writing a .NET Core 5 application and have 3 project layers:

1. API - REST, interacts with the client-side code, gets & returns DTOs.
2. BLL - Business logic - most code is here.
3. DAL - Repository pattern => Calls the SQL Server database. Works with entities.

I am using entities in my DAL layer and map them later to DTO models which are returned in the API to the API caller.

If I write in Google "In which layer to map from entity to DTO?" I get the answer:

In that case, the service layer maps domain entities to data contracts (DTO's).

The problem is that I don't have a service layer and I don't want to create it.

The question is, in which layer in my layers structure should I do the mapping from entity to DTO?

In my structure I guess I can do it in 2 places (I am not sure which one is better and why):

1. In the BLL - instead of returning an entity, I can map it to a DTO (using an AutoMapper) and return the DTO to the API layer.

2. In the API - Receiving an Entity from the BLL and then mapping it to a DTO (using an AutoMapper or ResultFilter) and returning it to the API caller.

CodePudding user response：

Your BLL seems to be the service layer & if it isn't, you should ultimately have one.

The responsibility for mapping database objects to something that the API consumer understands is with the service/business logic layer.

I would go with the BLL layer as if anything, it definitely doesn't belong to the handler level (API level) nor the data repository level.

CodePudding user response：

In my personal opinion based on your situation. I would suggest option two. Here is a well sourced answer from a similar question that expands on the why.

Essentially since the need for the DTO comes from your application layer (or as you call it API layer) it should therefore be mapped in the API layer.