Citat:
Det är inte jag som tänker mig, att lösa data access med någon form av repository är i stort sett standardförfarande.
Citat:
Det var vi överens om redan tidigare. Databasanrop ska absolut inte ligga i modellen. Angående var, så är svaret: i ditt data access layer. I sin enklaste form består det av enbart en repository.
Citat:
Båda dessa är en enkel form av repositories. Alternativ två skulle snabbt bli hopplöst om du inte menar att det är en generisk klass. Men även generiska klasser blir ganska snabbt ohållbara.
Skulle jag göra för tillfället så skulle jag till varje modell som innehåller en klass skapa en fil med funktioner med databasanrop som hanterar information om denna klassen. Alternativt om det är få databasanrop ha en enda separat fil med funktioner eventuellt som kommer göra alla databasanrop.
Citat:
Ja, din data access har absolut inget med MVCs komponenter att göra. Den hör inte hemma i någon av delarna.Du ville ha en generell diskussion hur man hanterar databasanrop i MVC. Man gör det i ett data access layer som i sin enklaste form består av en enda, vanligtvis då generisk, repository. Eventuellt finns ett service layer ovanpå.
Dina anrop sker då från controller -> ... -> data access layer som returnerar data tillbaka till controllern. Hur exakt det ska implementeras i ditt fall beror på vilket språk du väljer, vilken databas, om du använder en ORM och i så fall vilken, hur pass omfattande din applikation kan tänkas bli etc etc. Därför kan jag inte skriva något i stil med
"Skapa upp en klass för varje modell, i dessa klasser skriver du sedan kod som gör förslagsvis:
Kod:
"GetAll(); GetById(int id); Add(Foo entitiy) Update(Foo entity); Delete(int id); Delete(Foo entitiy);
Du kan ju åtminstone googla och läsa på, det är för omfattande område för att jag ska skriva ner det åt dig. Har du mer specifika frågor för en specifik situation (om än hypotetisk) så kan jag svara. Men frågan "var ska denna repository ligga" har inget svar.