Talk:Team SPOT
Retsensioonid
Retsensioon meeskonnalt Ticketer
XML fail
Faili üldstruktuur on projekti wiki lehel hästi lahti kirjutatud (norida saab selle kallal, et kõiki tekstis viidatud linke wiki lehel ei ole). XML-fail vastab kirjeldusele. Failis selgitavad kommentaarid puuduvad. Samas on fail loogiliselt struktureeritud ja kergesti arusaadav. Elementide nimed on loogilised. Elementide ja atribuutide nimedes on kasutatud ühtset stiili.
Võib-olla tasuks märkida treenerite juures välja tuua, millise treeningstiili treeninguid iga treener teeb / saab läbi viia.
Andmete paigutus atribuutidesse ja elementidesse tundub mõistlik. Võimalik, et litsentside info võiks eraldi elemendina olla. Kui tähte närida, siis toimumiskoha atribuudis määramine välistab treeningud, mis toimuvad mitmes ruumis.
Kirjeldusi ja nimesid sisaldavate elementide sisu on näitefailis esitatud ohutult CDATA lõikudena.
Näidisfail valideerub ning vastab struktuuri keerukuskirteeriumitele - on vähemalt neli loogilist dimensiooni; vähemalt kolmel dimensioonil on kasutatud ID-st informatiivsemaid atribuute.
XML schema
Näidisfail vastab schema tingimustele. Andmetüübid vastavad andmete sisule ja eeldatavale kasutusele.
Mõnes kohas tundub, et elementide ja atribuutide kohustuslikuks tegemisega on liialdatud. Vaieldav, kas treeneri reiting, treeningut kirjeldav video või treeningu kirjeldus peavad kindlasti kohustuslikud olema. Samuti pole lubatud ilma ühegi scheduledItemita treeningud.
Transformatsioonid
XML -> HTML transformatsioon
Transformatsioon vastab esitatud keerukuse tingimustele. Kasutatud on mitut foreach tsüklit, tingimuste kontrolli, stringitöötlust, defineeritud muutujaid.
Andmed on esitatud loogiliselt ja arusaadavalt. HTML on keerukam kui XML-st välja nopitud teksti listis välja kuvamine. Kujunduses on kasutatud CSS-i. Andmete esitamiseks on kasutatud tabeleid ja iframe’e.
XSLT fail valideerub. Väljundiks olev HTML annab W3C validaatoris kaks errorit (“no document type declaration; implying "<!DOCTYPE HTML SYSTEM>” ja “required attribute "TYPE" not specified <style>”)
XML -> XML transformatsioon
Transformatsioon on piisavalt keerukas (nested foreache’id; tingimuskontrollid jne). Transformatsioon vastab kirjeldusele ning on teostatud korrektselt.
Nii XLST fail kui väljundiks olev XML fail valideeruvad.
Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud.
Retsensioon meeskonna Team SPOT veebiteenusele
Retsensioon meeskonna Team_SPOT veebiteenusele meeskonna A$unik poolt.
Taaskord (nagu meeskonna Ticketer klientrakenduse retsensiooni tehes) jäi esimese asjana silma rakendust alla laadides see, et pole eemaldatud obj ja bin faile. See teeb lähtekoodi paki mõttetult suureks: antud rakenduse puhul ~200MB. Lihtne variant oleks need kaustad välistada (GIT korral) .gitignore failis ja siis linkida repo kloonimiseks.
Veebiteenuse eesmärgiks on väljastada ning vastu võtta andmeid treeningute kohta. Järgnevas retsensioonis lähtutakse SPOT meeskonna lehel olevast analüüsist, projekti koodi vaatamisest ning Postman-iga tehtud päringutest teenuse vastu, et hinnata tehtut (vähesel määral sai ka klientrakenduse abil brauseri võrguliikluse kaudu veebiteenusele tehtavaid päringuid uuritud).
„Peaks olema“ sektsiooni analüüs vaadates veebiteenuse koodi
Implementeeritud on:
1. kasutajate loomine;
2. autentimine;
3. klubide, treenerite ja treeningute info väljastamine;
4. tunniplaani info väljastamine;
5. treeningutesse registreerimine;
6. registreeringu tühistamine;
7. piirangute haldamine (autoriseerimise näol – heites aga kiire pilgu klientrakendusse, siis seda ei kasutatud seal või siis polnud realiseeritud selles funktsionaalsusi, mis seda vajaks).
Puudu on:
1. teenuse poole pöördumiste arvu piiramine (sellega seotult on küll määratud IdentityConfig.cs failis MaxFailedAccessAttemptsBeforeLockout muutuja, kuid detailsemaid kontrolle selle nõude lahendamiseks ei märganud).
Enam-vähem olemas:
1. kasutajate ja kasutusstatistika logimine – kasutusstatistikat saab vahetabelitest kätte küll, aga seal on abiks olevaid välju, mida ei kasutata (nt CancelledAtDt, CancelledBy, CreatedBy jne).
Veebiteenuses on lisaks jõutud implementeerida ka „Võiks olla“ sektsioonist funktsionaalsusi nagu:
1. klubide, treenerite, treeningute lisamine ja muutmine;
2. tunniplaanis treeningute tühistamine.
Praktiline teenuse testimine ja avastatud vead:
Klientrakenduse põhjal ja brauseri tööriistade alt päringuid vaadates selgus, et GET päringud töötavad ning töötab ka sisselogimine ja registreerimine (viimased kaks on muidugi peamiselt Identity templiitidega juba realiseeritud funktsionaalsus). Püüdes Postman-iga POST, PUT, DELETE päringuid teha õnnestusid enamused neist, mis on hea. Mõned vead siiski avastatud sai TrainersController-is ja RegistrationsController-is.
1. POST /api/trainers ehk treeneri loomine ebaõnnestub. Andmebaasi kirje küll luuakse, aga DTO tagastamisel tundub, et mapping on vigane.
2. PUT /api/trainers/:id küll töötab täis andmekomplekti korral, kuid JSON-ist trainerId eemaldamisel taaskord tagastatav Dto mapping ei arvesta sellega ja server tagastab staatuse 500.
3. PUT/DELETE api/registration – siin võiks olla lisaks GetByIdForUser kontrollile "admin" rolli kontroll, kes saaks siis nii või teisiti neid andmeid muuta. Lisaks, kui GetByIdForUser on mõeldud selleks, et kasutaja saaks ainult omi andmeid muuta, siis miks siin teenus lubab muuta userId välja, mis tähendab, et üks kasutaja saab registreerimise määrata endalt teisele kasutajale.
See tähendab, et puudu on pisut veahaldust, kui kõik ei toimu nö happy path viisil, kus tuleb täpselt oodatud andmekogum kontrollerisse. Üldmulje praktilisest testimisest on aga hea. Kontrollerite järgi sai hästi pildi ette, mis andmeid nad ootavad ja mida kontrollitakse nende juures ning neid polnud raske Postman-iga tööle saada.
Projekti struktuur, koodi ülesehitus ja kasutatud mustrid
Positiivsed aspektid:
Projekti üldine struktuur on loogiline. On eraldi projektid põhiosade jaoks - DAL, Domain, Identity, WebApi, DTO-ga seonduv projektis BL. Kasutatud on dependency injection-it Ninject näol. Andmebaasiga suhtlus kontrollerites toimub Service ning UOW objektide abil. UOW-s on defineeritud ilusti kõik vajalikud repositooriumid. Repositooriumites on kohati ka lisameetodeid ja mitte kasutatud ainult neid, mis tulevad projektipõhjaga kaasa. Kasutatakse liideseid objekti tüübina ja mitte implementatsiooni ennast. Kontrollerites võetakse vastu ja tagastatakse DTO-sid, mitte otse andmebaasi minevaid objekte. Olemitel „Domain“ projektis on kasutatud valideerivaid annotatsioone. Neid võinuks ehk lihtsalt rohkem olla.
Oleks võinud parem olla:
Äkki oleks võimalik see MVC projekt, mis WebApi sees on ja mõeldud API dokumenteerimiseks, tõsta eraldi kausta? See on tõenäoliselt lihtsalt templiidiga loodud, aga teeb taolisel kujul WebApi projekti struktuuri segaseks. Eriti häirib seejuures need MVC poolt kasutatavad frontend faile hoidvad kaustad nagu „Content“, „Views“ ja „Scripts“.
Domain, Interfaces ja DAL projektis võiks kasutada objektide kaustadesse jaotamist, et tekiks ülevaade seotud funktsionaalsusega klassidest. Lisaks on mõnel pool jäänud sisse palju väljakommenteeritud koodi (ja need pole TODO-d, mida kunagi ehk hakatakse kasutama). Siin oleks näiteks (tõenäoliselt A. Käveri projektipõhja jäänuk) DataBaseContext.cs, kus võinuks eemaldada „PK – string“ versioonis Identity olemite sektsioonid. Lisaks leidus pisemaid tähelepanematusi nagu DAL all on üks tühi klass ServiceMap.cs ning klassides on palju mittevajalikke „using“ direktiive – nende ebavajalike asjade eemaldamisel aitab tavaliselt IDE mõni tööriist.
Kokkuvõte
Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.
