Förslag önskas för lösning på ASP.NET MVC utmaning

Sitter under de regniga timmarna av sommaren och hackar lite på en ASP.NET MVC lösning för att lära mig mera och kanske till och med skapa något användbart. Det är en lösning för att planera evenemang typ CodeCamps och jag har kommit en bit på vägen men märker att jag hamnar åter och åter i samma mönster… Därför tänkte jag se vad du skulle rekommendera för lösning på det här “problemet”:

Jag har en objektmodell som ser ut så här (och det är bara en liten del av den hela modellen):

CodeCampModel Med andra ord, ett “event” består av ett eller flera “tracks” som i sin tur består av en eller flera “sessioner”. Jag använder mig av Entity Framework (så klart) för mappningen mot databasen och utmaningen som jag har är hur jag ska vandra “uppåt” i kedjan (från track till event) utan att behöva göra överdrivet många anrop till databasen.

Jag har nämligen skapat ett antal vyer, exempelvis listor över “tracks”, “events” och “sessioner”, samt vyer för att editera, föreslå nya osv. Men det jag märker är att jag behöver kontinuerligt spara undan ID’t på den överliggande strukturen. Alltså, vilket “event” som respektive “track” hör till och vilket “track” som respektive “session” hör till. Detta behövs för att kunna filtrera listorna på det aktuella evenemanget eller aktuella spåret efter editering osv.

Ännu mer förklaring:

När jag har en lista på evenemang så kan jag välja att titta på det evenemangets “tracks”. Den listan innehåller alltså en filtrerad lista av alla tracks som hör till det aktuella evenemanget. Om jag då väljer att exempelvis editera ett “track” så måste jag alltid skicka med “eventId” för att kunna komma tillbaka till rätt evenemang efter editering, eller så ska jag kontinuerligt hämta eventId för respektive spår vid anrop till databasen.¨

Vilket är det bästa alternativet? Som jag ser det har jag följande alternativ:

1) Vid varje anrop till databasen efter “track” använda .Include(“Event”) för att få tillbaka information om evenemanget också. Eventuellt göra överlagrade metoder på min TrackRepository som då skulle kunna vara: GetTracks(bool includeEventInResult) osv… Leder till ett ganska “tjatigt” repository, eller?

2) Behålla eventId som en parameter till alla anrop på TracksController-objektet. Vilket jag märker efter ett tag kan bli ohållbart eftersom det också kommer att resultera i att jag kommer att behöva skicka det ned till SessionsController-objektet också för att i efterhand kunna navigera tillbaka.

Är frågan tillräckligt luddigt ställd? Vad är din rekommendation?