1

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.

Kristina Hammer
  • 31
  • 1
  • 3
  • You don't want your business layer to depend on the models (entities) in the data layer. So, I'd say the main purpose of your repository is to abstract away from the data layer so your business logic doesn't change if you decide to structure your database differently. – Xerillio Oct 02 '21 at 17:18
  • This is opinionated and hence off-topic. However, the 3-layer architecture is quite outdated, move to something cleaner and more flexible like the onion architecture – Camilo Terevinto Oct 02 '21 at 17:19
  • @Xerillio I am not sure what you mean, do you mean to do the mapping in the business layer? – Kristina Hammer Oct 02 '21 at 20:56

3 Answers3

0

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.

Ermiya Eskandary
  • 15,323
  • 3
  • 31
  • 44
0

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.

SJ17
  • 1
0

The cause of this confusion is this architecture contains 2 different responsibilities in BLL layer. These are application logic and domain logic.

If you separate these responsibilities in your architecture, you should put the mappings in the application layer. see

1 - In your architecture, you shouldn't keep the mappings in DAL, because DAL is just a layer about how to access data.

2 - Keep the API layer as minimal as possible because this provides flexibility about the presentation technology. So you can change the presentation technology from WebApi to MVC, Blazor, WPF, WinForm etc. easily.

3 - You can create the mappings in BLL but you should not forget that the mappings and the domain logic are completely different responsibilities. Your BLL will grow and its cohesion will decrease.

I recommend Clean Architecture instead of this architecture. There is a sample project in this link

Tolga Cakir
  • 725
  • 1
  • 7
  • 13