Webbserverprogrammering 1 · område 6

Projekt 1 – Datadriven webbapplikation

Din applikation ska gå att förvalta utan att någon öppnar en kodfil. Den som är inloggad ska kunna lägga till, ändra och ta bort poster, och varje post hör till en kategori i en egen tabell. Den som inte är inloggad ska kunna läsa, men inte komma åt något som ändrar.

20 jan Etapp 1: projektplanen committad Innan du börjat koda. Git visar datumet.
9 feb Etapp 2: milstolpe 1 Kategorin, relationen och migrationen.
24 feb Etapp 3: milstolpe 2 Alla fyra CRUD-operationerna, och sidorna skyddade.
2 mars Etapp 4: avstämning Tre minuter med läraren, en och en.
8 mars Etapp 5: deadline kl 23:59 Repots adress lämnas i itslearning. Prov 4 dagen efter.

Det som bedöms tyngst är att lagren håller

Komponenterna visar, tjänsterna gör arbetet, och databasen nås bara genom tjänsterna. Det är det du byggt upp under hela hösten, och nu ska det bära en hel applikation.

Det här är också vårens första projekt, och det första där processen bedöms, inte bara koden. Du skriver en projektplan innan du bygger, och en uppföljning mot den när du är klar.

1. Uppdraget

Du börjar inte om. Samma domän, samma entitet, samma tjänst som i område 5. Du får med dig fyra saker:

Guiden, som bygger Filmarkivet i 26 steg med all kod och en översättningstabell. Den är uppdelad efter lektionerna.
Referensprojektet Filmarkivet, färdigt att köra, läsa och logga in i. Inloggningsuppgifterna står i dess README.md.
Lektionerna 36–43, en genomgång per del av guiden.
Arbetspassen 42 och 44–47, med handledning.

2. Tidsplanen

Datum	Pass	Vad ska vara klart
ons 13/1	35	Uppgiften delas ut och läses tillsammans
ons 20/1	37	Etapp 1: projektplanen committad
tis 9/2	42	Etapp 2, milstolpe 1: kategorin, relationen och migrationen
ons 10/2	43	Sportlov veckan efter
ons 24/2	45	Etapp 3, milstolpe 2: alla fyra CRUD-operationerna, och sidorna skyddade
tis 2/3	46	Etapp 4: avstämning med läraren, en och en
ons 3/3	47	Sista arbetspasset
mån 8/3	–	Etapp 5: deadline kl 23:59
tis 9/3	48	Prov 4

Milstolparna lämnas inte in. De är till för att du och jag ska se i tid om något halkar efter. Är du inte vid milstolpe 1 den 9/2 har du tre veckor kvar och det mesta av arbetet framför dig. Säg till då, inte den 3/3.

3. Så är uppgiften uppdelad

Projektet går i fem etapper. Varje etapp har ett datum, en kontroll du gör själv, och de krav som hör till den – på alla tre nivåerna.

Nivå	Vad som skiljer den
E	Applikationen fungerar, och lagren finns. En E-applikation gör det guiden gör
C	Valen är dina och motiverade. Du gör det av skäl du kan redovisa, och du har kontrollerat att det håller
A	Du går längre än guiden på egen hand, och ser svagheter i ditt eget arbete innan någon annan gör det

C-kraven gäller utöver E-kraven, och A-kraven utöver C-kraven – i alla etapper. En etapp är klar när kontrollen går igenom, inte när alla kryss är satta. Det som inte blev klart i en etapp tar du med dig till nästa, och skriver om det i uppföljningen.

Kryssen sparas i din webbläsare, så du kan bocka av allteftersom.

4. Etapp 1 – Projektplanen

Klar onsdag 20/1 · pass 35–37

En fil i repots rot: PROJEKTPLAN.md. Den ska vara committad innan du börjat koda. Git visar när den kom in, och det är poängen.

Den ska svara på fem frågor:

Vad ska byggas? Din domän, din huvudentitet och din kategori. Fyll i översättningstabellen ur guiden och klistra in den här.
Vilka krav siktar du på? E, C eller A, och vilka punkter i kravlistan du ser som svårast för dig.
Vad ingår inte? Minst en sak du medvetet väljer bort, och varför.
När ska vad vara klart? Din egen tidsplan mot etapperna, pass för pass. Den får vara grövre än tabellen, men den ska vara din.
Vad kan gå fel? Minst två risker, och vad du gör om de inträffar.

Rubrikerna att utgå från. Blocket går att kopiera – det är en mall, inte kod att öva på:

# Projektplan – <din applikation>

## Vad ska byggas?

| Filmarkivet | Mitt projekt |
|---|---|
| `Film` | … |
| `Genre` | … |

## Vilka krav siktar jag på?

## Vad ingår inte?

## När ska vad vara klart?

| Pass | Datum | Vad jag gör |
|---|---|---|

## Vad kan gå fel?

| Risk | Vad jag gör om den inträffar |
|---|---|

En projektplan är inte ett löfte. Det är en gissning som du sedan jämför med vad som hände. Ändrar du planen under arbetet gör du det i filen, med ett datum och ett skäl, och committar. Då syns både den gamla och den nya planen i historiken.

Kontrollen

Filen finns på github.com, och commiten är daterad senast 20/1.

Etapp 1 · krav för E

PROJEKTPLAN.md i repots rot, committad senast 20/1, med svar på alla fem frågorna

5. Etapp 2 – Datamodellen

Milstolpe 1 · klar tisdag 9/2 · pass 37, 40 och 42 · guidens steg 5–9 och 17

Din kategori får en egen tabell, och varje post hör till en kategori. Identity lägger till användartabellerna i pass 40, och det är en migration till. Det som kommer sedan – formulären, sökningen, inloggningen – bygger på att datamodellen står.

Kontrollen – fyra saker, i den här ordningen

dotnet ef migrations list visar minst tre migrationer – den från område 5, relationen och Identity – och ingen står som (Pending).
dotnet ef migrations script innehåller FOREIGN KEY och ON DELETE CASCADE i relationens migration.
Detaljsidan visar postens kategori.
Kategorisidan visar sina poster.

Klarar du alla fyra är du vid milstolpe 1. Faller någon är den nästa sak du gör, före allt annat.

dotnet ef migrations list
dotnet ef migrations script

Etapp 2 · krav för E

Din huvudentitet från område 5 och en kategorientitet med minst namn och beskrivning. Identitys tabeller räknas inte
En en-till-många-relation: främmande nyckel och navigationsegenskap på huvudentiteten, en lista åt andra hållet på kategorin
En migration för relationen, som gick igenom på din databas med egna rader
Frödata för minst tre kategorier, och varje post i frödatan har en kategori
En sida för en kategori som visar dess poster, hämtade med Include

Etapp 2 · krav för C — utöver E

Du har hittat ON DELETE CASCADE i dotnet ef migrations script och tagit ställning i README.md: vad ska hända med posterna när en kategori tas bort, och hur har du sett till att det blir så?

Etapp 2 · krav för A — utöver C

En tredje entitet i en relation som guiden inte visar – en till en-till-många åt ett annat håll, eller en mång-till-mång. Den ska synas i en egen migration, och i minst en vy
Ett medvetet val av DeleteBehavior för minst en relation, gjort i OnModelCreating och motiverat i README.md

6. Etapp 3 – Operationerna

Milstolpe 2 · klar onsdag 24/2 · pass 36, 38–40, 44 och 45 · guidens steg 1–4 och 9–23

Alla fyra operationerna, hela vägen genom tjänstelagret. En sökning som görs i databasen. Validering av tre sorter. Och inloggning, med varje sida som ändrar data skyddad.

Operationerna gicks igenom i pass 36, före relationen. Har du byggt dem då, lägger du till rullistan för kategorin nu – guidens steg 9.

Kontrollen – med någon annan vid tangentbordet

Du säger vad som ska göras, den andra gör det. Du vet var man ska klicka och vad man ska undvika – det vet inte den andra.

Skapa en post med en kategori. Den syns i listan.
Läsa: detaljsidan visar kategorin, kategorisidan visar posten.
Ändra posten. Listan visar ändringen – inte en post till.
Ta bort posten. Bekräftelsesidan visas först, och posten finns kvar tills man bekräftar.
Skicka formuläret utan kategori. Ett svenskt felmeddelande.
Logga ut, och skriv varje sida som ändrar data direkt i adressfältet. Du ska hamna på inloggningen varje gång.
git grep DbContext -- Components ger ingen träff.

git grep DbContext -- Components

Etapp 3 · krav för C — utöver E

Listvyn sorterar på minst tre kolumner och delar in i sidor, via frågesträngen. ?sida=99 och ?sida=abc ger en sida som finns
Ändringssidan hämtar posten med ??=, och du kan förklara vad som händer med =
SQL-loggningen är påslagen i appsettings.Development.json
I README.md: var görs sökningen, och var görs sorteringen, och varför? Jämför de två varianterna med din egen data, och säg vad som händer med Å, Ä och Ö i ditt sökfält
Alla tre sorternas validering, var och en med en regel som hör till din domän: ett eget attribut, en regel över två fält med IValidatableObject, och en regel som kräver databasen
Regeln mot databasen fungerar också när en post ändras, utan att posten krockar med sig själv
En tabell i README.md över varje adress i applikationen: kräver den inloggning eller inte, och vad svarar den när du är utloggad? Fyll i den genom att prova, inte genom att läsa koden
Inloggningssidan ger samma meddelande för fel adress och fel lösenord
tillbaka följs bara till adresser på den egna sajten

Etapp 3 · krav för A — utöver C

Ett formulär som skickas med en kategori som inte finns – ändrat i DevTools – ger ett begripligt felmeddelande, inte en 500. Felet loggas till utvecklaren i tjänstelagret
Regeln mot databasen är inte känslig för skiftläge och mellanslag, eller så har du motiverat varför den ska vara det
En svaghet i inloggningen som guiden lämnar öppen – den i guidens steg 20, eller en du hittat själv – beskriven i README.md: hur den kan utnyttjas, och antingen hur du åtgärdat den eller varför du inte gjort det

7. Etapp 4 – Kvaliteten

Avstämning · tisdag 2/3 · pass 41, 43 och 46 · guidens steg 24–26

Applikationen fungerar. Nu ska den gå att läsa, och du ska veta att den håller.

Granskningen, pass 41

Någon annan går igenom din kod mot kodningsstandarden, och du går igenom någon annans. Den som granskar fyller i:

Antal varningar från dotnet build
Namn: PascalCase, camelCase, _ på privata fält, Async och I där de hör hemma
En klass per fil, i en mapp som säger vilket lager den hör till
Den längsta metoden, och om den gör två saker
En kommentar som säger vad och inte varför – och ett ställe där en varför-kommentar saknas
Om README.md går att följa från en ren klon

Spara granskningen. Det den hittade ska vara åtgärdat vid deadline, eller motiverat i uppföljningen. Tabellen över konventionerna står i guidens steg 24.

Självgranskningen, pass 46

Svara skriftligt, och spara svaren – de blir underlag till uppföljningen:

Vilken milstolpe nådde du i tid, och vilken inte?
Vad tog längre tid än du planerade? Varför?
Vilka tre krav för din nivå är inte klara i dag?
Vilket av dem gör du först?
Finns det något du inte kommer att hinna? Skriv det nu, och varför.

Kontrollen – avstämningen, tre minuter

Du visar fyra saker, i den här ordningen:

Radera .db-filen, kör dotnet ef database update, starta och logga in. Kategorierna, posterna och användaren finns.
git grep DbContext -- Components ger ingen träff.
Logga ut och skriv en skyddad adress. Du hamnar på inloggningen.
PROJEKTPLAN.md – finns den, och har den ändrats?

Etapp 4 · krav för E

Projektet startar med dotnet run utan fel och renderar statiskt – inget @rendermode

Etapp 4 · krav för C — utöver E

Kodningsstandarden från lektion 41 är följd. Det som din granskare hittade är åtgärdat, eller motiverat i UPPFOLJNING.md
Minst en XML-kommentar på en metod i ett gränssnitt, där namnet inte säger allt
dotnet build ger noll varningar
Minst fem manuella tester i README.md, som en tabell: vad du gjorde, vad du väntade dig, vad som hände

Etapp 4 · krav för A — utöver C

Koden är kommenterad så att en ny läsare förstår varför, inte bara vad. Varje tjänst och varje sida som ändrar data har en kommentar överst som säger vad den ansvarar för
De manuella testerna täcker också det som inte ska gå: utloggad åtkomst, manipulerade formulär, felaktig inmatning i adressen

8. Etapp 5 – Leveransen

Deadline måndag 8/3 kl 23:59 · pass 47

Tre saker ska bli färdiga: README.md, UPPFOLJNING.md, och inlämningen.

README.md är skriven för den som aldrig sett projektet: vad som ska installeras, vilka kommandon som körs, och hur man loggar in. Till det kommer de texter som C- och A-kraven i de andra etapperna ber om.

UPPFOLJNING.md jämför planen med vad som hände. Rubrikerna att utgå från:

# Uppföljning

## Milstolpe för milstolpe

| Milstolpe | Planerat | Faktiskt | Varför skillnaden |
|---|---|---|---|
| Projektplan | 20/1 | … | … |
| 1: relationen | 9/2 | … | … |
| 2: CRUD | 24/2 | … | … |
| Deadline | 8/3 | … | … |

## Vad jag hann och inte hann

## Vad jag gör annorlunda i nästa projekt

## Förbättringsförslag

Förbättringsförslag är för A: minst tre egna förslag, och för vart och ett en uppskattning av vad det skulle kräva. Siktar du på E eller C kan rubriken stå tom.

"Allt gick bra" är inte en uppföljning

"Relationen tog en vecka längre, för att migrationen kraschade på min egen databas och jag inte förstod felet" är det. Använd svaren från självgranskningen.

Inlämningen

Kontrollera att projektet startar och att varje sida svarar.
Radera din .db-fil och kör dotnet ef database update igen. Starta, och kontrollera att kategorierna, posterna och användaren finns.
Logga in med uppgifterna i din egen README.md. Går det inte kommer det inte att gå för mig heller.
Logga ut och prova varje skyddad adress direkt i adressfältet.
Kör git grep DbContext -- Components. Ingen träff.
dotnet build. Läs varningarna, om det finns några.
Skriv klart UPPFOLJNING.md, och läs igenom README.md som om du aldrig sett projektet.
Gå igenom kraven i alla fem etapperna för den nivå du siktar på.
git add ., git commit -m "…", git push
Öppna ditt repo på github.com och kontrollera att Migrations/, PROJEKTPLAN.md och UPPFOLJNING.md finns där – och att .db-filen inte gör det.
Klistra in repots adress i inlämningsrutan i itslearning.

Prov 4 är dagen efter, tisdag 9 mars, och det frågar om sådant du byggt i projektet.

Etapp 5 · krav för E

dotnet ef database update bygger hela databasen från noll, och när applikationen startar finns användaren
README.md med installationsanvisning: vad som ska installeras, vilka kommandon som körs, och hur man loggar in
UPPFOLJNING.md: vad som blev som planerat och vad som inte blev det
Commits på minst åtta olika dagar, med begripliga meddelanden

Etapp 5 · krav för C — utöver E

Projektplanen har ändrats minst en gång under arbetet, med datum och skäl
UPPFOLJNING.md jämför planen med utfallet milstolpe för milstolpe, och säger vad du gör annorlunda i nästa projekt

Etapp 5 · krav för A — utöver C

UPPFOLJNING.md avslutas med minst tre egna förbättringsförslag, med en uppskattning av vad varje förslag skulle kräva

9. Så bedöms den

Projekt 1 prövar fler av kursens betygskriterier än någon inlämning under hösten.

Kriterium	Vad det betyder här
Datalagring i relationsdatabas	På E en databas med två relaterade tabeller som byggs ur migrationer. På A en lösning av viss komplexitet: fler entiteter, egen validering och genomtänkta regler för vad som händer när data tas bort.
Applikationsarkitektur och separation av olika slags logik	På E är presentationslagret i någon utsträckning skilt från resten. På C är det tydligt skilt: ingen komponent vet att det finns en databas.
Utvecklingsprocessen: planering och uppföljning	Projektplanen och uppföljningen. På E finns de. På C är planen genomarbetad och justerad, och uppföljningen är nyanserad.
Kodning och dokumentation enligt vedertagen praxis	Kodningsstandarden, kommentarerna och `README.md`.
Säkerhet	På E skyddade sidor och hashade lösenord. På C har du prövat skyddet och dokumenterat det. På A har du hittat en svaghet själv.

Jag klonar repot, kör det och läser koden. Fyra saker väger tyngst – samma fyra som i avstämningen:

Att databasen byggs från noll. Jag kör dotnet ef database update på en ren klon. Får jag inte din databas med dina kategorier, dina poster och din användare är E-kravet inte uppfyllt. Det är det lättaste av alla krav att kontrollera själv.
Att lagren håller. Jag kör git grep DbContext -- Components. En enda träff är ett underkänt E-krav, hur bra resten än är.
Att sidorna är skyddade. Jag loggar ut och skriver varje adress som ändrar data direkt i adressfältet. Kommer jag in är kravet inte uppfyllt, oavsett vad menyn visar.
Att uppföljningen är ärlig. En uppföljning där allt gick enligt plan är nästan alltid fel. Det som bedöms är att du ser skillnaden mellan planen och utfallet och kan säga något om varför. Att du hann allt bedöms inte.

10. Vanliga misstag

Det här är det som gör att projektet underkänns i onödan.

Misstag	Vad som händer	Undvik det så här
Projektplanen skrivs sist	Git visar det, och uppföljningen jämför inte med något	Committa den senast 20/1. Den får vara kort
Uppföljningen säger att allt gick bra	Den bedöms som ytlig, hur välskriven den än är	Jämför milstolpe för milstolpe. Vad tog längre tid, och varför?
`DbContext` injicerat i en komponent för att det gick fortare	Underkänt E-krav	Lägg metoden i tjänsten. Det är hela poängen med höstens område 4
Bara menylänken dold	Vem som helst kan ändra data via adressfältet	`[Authorize]` på varje sida som ändrar. Prova utloggad
Utloggningens endpoint utan kontroll av token	Vilken sajt som helst kan logga ut dina besökare	`IsRequestValidAsync`. Guidens steg 23
Ta bort med en länk	En GET ändrar data, och det finns inget skydd mot andra sajter	Bekräftelsesida och formulär med POST
Migrationen kraschar på FOREIGN KEY constraint failed	Din databas har rader utan kategori	`HasDefaultValue` med id:t på en kategori som finns. Guidens steg 6
Kategorin syns inte, inget fel	`Include` saknas	Den ska beställas i varje fråga som behöver den. Guidens steg 7
Ändringen blir en ny post	Det dolda fältet för `Id` saknas	Guidens steg 3
Ändringen sparas inte	`=` i stället för `??=`	Guidens steg 3
Lösenordet går inte att logga in med	`CreateAsync` misslyckades tyst, lösenordet var för kort	Minst åtta tecken. Kontrollera efter en ren `database update`
Inloggningsuppgifterna saknas i `README.md`	Jag kan inte bedöma det som ligger bakom inloggningen	Skriv dem. Det är en övningsapplikation
`@rendermode` i projektet	Livscykeln körs två gånger, och projektet är inte längre statiskt	Demot från lektion 43 hör hemma i ett testprojekt
Guidens regler med nya namn	Titeln finns redan blir Namnet finns redan, och översättningen visar ingenting	Hitta regler som hör till din domän. Det är du som känner den
Allt committat sista helgen	Historiken visar inte arbetet, och kravet på åtta dagar faller	Committa efter varje pass