Implement API-Endpoint for invoiced hours

[timo2o1o]

Umsetzung als ASP.Net Core-Web-API mit folgender Konfiguration:

Route: /employees/{email}/invoiced/?from=YYYY-MM?to=YYYY-MM

Alternatively (to get the data for the user which is logged in:
/employees/current/invoiced/?from=YYYY-MM?to=YYYY-MM

Datamodel:

{
  [
    {
      "month": "2022-01",
      "project": "Doom",
      "customer": "Apogee",
      "hours_count": 140.75
    },
    {
      "month": "2022-01",
      "project": "Commander Keen",
      "customer": "Softdisk",
      "hours_count": 20
    }
  ]
}

Architecture:
HTTP GET -> DoePaAdminWebAPI.EmployeeController -> DoePaAdminViewModel.ReceiveMitarbeiterPerformanceViewModel -> DoePaAdminViewModel.Services.DoePaAdminService

[Jusdon]

Hi @timo2o1o which naming do we want to use for the API project? Can you give me one?

[timo2o1o]

Hi @timo2o1o which naming do we want to use for the API project? Can you give me one?

I would suggest DoePaAdminWebAPI.EmployeeController for the project and the Controller

[Jusdon]

Hi @timo2o1o :),
I just ran into a little problem.
When I refer to the abstract class "Rechnungsposition" as well as "Rechnung", I get an error "The entity type 'Rechnungsposition' requires a primary key to be defined". This is of course logical, as no primary key has been defined in the abstract classes.
Can I rebuild the abstract classes so that the "primary keys" are in the abstract base class?

[timo2o1o]

Hi @timo2o1o :), I just ran into a little problem. When I refer to the abstract class "Rechnungsposition" as well as "Rechnung", I get an error "The entity type 'Rechnungsposition' requires a primary key to be defined". This is of course logical, as no primary key has been defined in the abstract classes. Can I rebuild the abstract classes so that the "primary keys" are in the abstract base class?

Hi @Jusdon,
I don't know any way to make this possible. Because that would make entity framework to create the abstract classes as tables on the db.

[Jusdon]

I thought that there would be a "central primary key", e.g. "RechnungsId" or "RechnungspositionsId", which could then be abstracted from the "Eingangs" and "Ausgangs" classes.

Do you understand what I mean? @timo2o1o

[timo2o1o]

I thought that there would be a "central primary key", e.g. "RechnungsId" or "RechnungspositionsId", which could then be abstracted from the "Eingangs" and "Ausgangs" classes.

I thought that there would be a "central primary key", e.g. "InvoiceId" or "InvoiceItemId", which could then be abstracted from the "Inbound" and "Outbound" classes.

Do you understand what I mean? @timo2o1o

I think I understand... Because that is how I modelled the Rechnungspositionen at first and had to remodel it after it did not work with entity framework. I try to call you this afternoon, so we can discuss it.