Mapping and querying the web api in service layer

Question

I am making a web api and have created several classes, the class controller and the service as well as the dto and the model. In the controller I have the methods for post and get and the business logic is in the service

My question is how can I make the queries from the model class and map the queries to the dto

Service Layer:

  public class GermanyService : IGermanyService
{
    public Task<IEnumerable<GermanyDto>> All()
    {
         
        throw new NotImplementedException();
    }

    public Task Create(GermanyDto germany)
    {
        throw new NotImplementedException();
    }
}

Controller:

    public class GermanyController
{
    private readonly IGermanyService _germanyService;

    public GermanyController(IGermanyService service)
    {
        _germanyService = service;
    }

    [HttpGet]
    public async Task<IEnumerable<GermanyDto>> Get(int id)
    {
        return await _germanyService.All();
    }

    [HttpPost]
    public async Task Post([FromBody]GermanyDto dto)
    {
        await _germanyService.Create(dto);
    }

Answer 1

Okay :)

Use an interface implementation ->

seggregate your business logic's interfaces, so you have many of them, split into their single responsibilities and then join them in one:

Example

public interface IStreetName {
     string StreetName{get;set;}
}


public interface IPostCode {
    string PostCode {get;set;} 
} 

... other implementations for an Address DTO f.x.

then

public interface IAddress : IPostCode, IStreetName, ...
{
    //should be empty
}

now you can Implement Iaddress on your DAL object, and not need an actual DTO -> because you ONLY reference the interface in your business logic.

etc. Obviously, you would have to rename the intefaces for the properties on your "GermanyDTO", which I don't know what looks like.

EDIT: Using mappers like "auto-mappers" or the like is usually a sign of 2 things.

1: You don't understand how to write effective mapping yourself. 2: Using a framework to accomplish something, doesn't absolve you from testing. And frameworks are notoriously difficult to test. (Because, following proper procedure, you would have to test the interface between your code and the framework, and by extension the code between framework and 3rd part component, failing to do so, will setup you up for risks, between what you THINK the framwork does, and what it ACTUALLY does)

So Yes, using something like "Automapper" is at best a supression of a symptom rather than a cure.

Because the root cause is failing to understand how interfaces solve mappings. And using a tool, to do something you can do cleaner yourself, and improve the structure of your entire system as a result? Is a no-brainer.

Just notice your own statement: "Do you think it is effective? Automapper solves some of my issues" You are seriously going to implement a direct dependency in your system, because of a framework? You are admitting to writing bad code, because a framework can take away ... what? A little bit of boiler plate?