Backend file structure Proof Of Concept

[lbarraga]

Proof of Concept Mappenstructuur Backend

Deze PR presenteert een mogelijke mappenstructuur voor de backend, ingevuld met proof-of-concept-functionaliteit voor elke laag. De inhoud hier is niet bindend, maar dient als basis voor concrete discussies over de backend tijdens de vergadering.

De volgende lagen zijn aanwezig:

Databanklaag

Communicatie met de databank gebeurt direct via de SqlAlchemy-bibliotheek. In de databanklaag zijn specifieke SqlAlchemy-modellen gedefinieerd in de models map, waarin de relaties tussen de modellen vastgelegd zijn. Als voorbeeld zijn hier LesgeverModel en VakModel opgenomen. LesgeverModel ziet er bijvoorbeeld zo uit:

class LesgeverModel(db.Model):
    id: Mapped[int] = mapped_column(primary_key=True)
    naam: Mapped[str] = mapped_column()
    vakken: Mapped[list["VakModel"]] = relationship("VakModel", back_populates="lesgever")
    ...

Domeinlaag

Om niet rechtstreeks met SqlAlchemy-objecten te werken, zijn in de domeinlaag dataklassen gedefinieerd die 1-op-1 overeenkomen met de modellen uit de databanklaag. Het idee is om alle logica hier uit te voeren. Lesgever is bijvoorbeeld:

@dataclass()
class Lesgever(JsonRepresentable):
    naam: str
    id: int = None

Controle laag (routes)

In deze laag worden de routes van de API gedefinieerd. Er zijn al enkele proof-of-concept-routes voor het aanmaken en opvragen van een Lesgever, ...

Interface Databanklaag met Domeinlaag
Voor de abstractie tussen de databank- en domeinlaag kunnen DAO's (Data Access Objects) gebruikt worden. De domeinlaag maakt dan gebruik van een DAO voor databankoperaties, zonder dat deze laag in aanraking komt met de SqlAlchemy-databank. Zo geeft LesgeverDAO.getLesgever(id: int) bijvoorbeeld het Lesgever-model van de domeinlaag terug, maar worden achter de schermen SqlAlchemy-modellen gebruikt.

Interface Controllaag en Domeinlaag

Er is momenteel geen duidelijke interface tussen deze lagen gedefinieerd, en het is onduidelijk of dit nodig is. In de domeinlaag zijn echter enkele validator-klassen die helpen bij het omzetten van JSON naar een model uit de domeinlaag.

Testen

Er is een map voor tests waar al één test is gedefinieerd die enkele API-calls voor Lesgever test, bijvoorbeeld:

def test_create_lesgever_success(self):
    lesgever_data = {
        "naam": "Bart De Bruyn"
    }
    response = self.app.post('/lesgevers', data=json.dumps(lesgever_data), content_type='application/json')
    self.assertEqual(HTTPStatus.CREATED, response.status_code)

Bekende problemen / To-Do's

• De domeinlaag maakt nu direct gebruik van Sql...DAOs, wat het abstractiepunt enigszins ondermijnt. Idealiter zou er een klasse moeten zijn die dit abstractieproces beheert.
• Modellen moeten nog worden aangepast aan het daadwerkelijke ER-diagram.
• Momenteel staan alle modellen van de domeinlaag in één bestand.
• De databank-URI staat momenteel in index.py, maar zou beter in een configuratiebestand kunnen staan.
• Afgezien van de generieke DAO's is er weinig documentatie voor de bestanden (aangezien deze waarschijnlijk nog zullen veranderen).
• Er worden nog geen automatische linting checks uitgevoerd op de code.
• @msathieu heeft gewezen op het gebruik van verouderde SqlAlchemy-code.
• Er ontbreekt een script voor het lokaal opzetten van de databank.
• Niet alle databankfouten worden opgevangen in de API.