Talk:Meeskond:Taandarendajad VR2

Veebiteenuse retsensioon meeskonna Tab poolt

Peale Identity mudelitele on meeskonnal veel 6 olemit. Olemites olevad stringid on ilusasti piiratud ning isegi datetime'd on annotatsiooniga tüüp paika pandud, kuid selleks on imelikul kombel Date mitte DateTime. Vea sõnumid on ka kirjutatud. Oma olemitele on enamus ridadele peale kirjutatud Display name, mis teeb rakenduses olemite kujutamise kergemaks.

Veebiteenuse DAL on ehitatud nõuetekohaselt. Olemas on helper'd, interface'd ja repo'd, milles mõnel on kirjutatud vajaminevaid päringuid DbSeti vastu. Probleeme võib tekitada WebAppEFContext, kus meeskond on oma tabelite cascade kustutamised maha võtnud. See tähendab, et iga kirje kustutamisel tuleb teha ise kontrolli, kas teistes tabelites on vastava id-ga objekt enne kustutatud või kuidagi asendatud, et ei tekiks andmebaasis probleeme.

BLL-is on ära kirjeldatud ka treeningutele DTO, kuid see tagastab täies mahus sama treeningu, mis sinna sisse pandi. Sellest võib järeldada, et kõik info, mis saadetakse veebiteenusest klienti, on üldjuhul pikkade graafidena.Väikeste andmemahtudega see tõenäoliselt ei tekita ebameeldivusi. Probleem tekib olukorras, kus kirjeid tuleb palju. Kui päritakse kasutaja siis sellega tuleb kaasa ka kasutajatüüp ning sellega ka list kõikidest kasutajatest, kellel on see tüüp. See võib tekitada tulevikus probleeme.

Kasutajate tuvastamiseks ning haldamiseks kasutasin nende klientrakendust, mis neil on ehitatud sama veebiteenuse poole ja üllatuseks leidsin, et kasutajatele ei panda rolle külge. Lähemalt uurides leidsin, et kliendil on olemas kogu kasutaja ja ta rollide muutmise võimalus, kuid see on lihtsalt välja kommenteeritud layout-st.

Lõpptulemuseks on see, et kuigi kasutajad on olemas ning neid on võimalik hallata, siis õigusi pole kasutatud. Rääkimata turvalisuse poole pealt, et kas kasutajal on õigus midagi muuta. Veebiteenuse poole pealt pole mingeid erilisi kontrolle, et kas on õigus andmeid vaadata või mitte. Võib lihtsalt api lahti teha ning hakata andmeid vaatama.

Statistikat ei peeta, mis teeb ka päringute piiramise võimatuks. Logimine on tehtud NLog loggeriga kohtades, mis on automaatselt loodud. Meeskonna enda poolt pole dokumentatsiooni ega loggimist.

Kokkuvõtteks võiks öelda, et meeskond on hästi kasutanud raamistikku. Probleemiks on aga nende äriloogika.

Klientrakenduse retsensioon meeskonna Tab poolt

Meeskonna klientrakenduseks on treeningutele registreerimise rakendus. Rakendus on ehitatud nende poolt loodud veebiteenusele.

Treeninguid saab luua ning nendele saab registreerida. Lisaks on rakendusel sotsiaalmeediale vastav pool, kus kasutajaid saab jälgida, mille tulemusel tekib pealehele nende poolt koostatud treeningud. Kasutajad saavad üksteisele tagasisidet jätta ning neid saab ka blokeerida, mille tulemusena blokeeritud kasutajad ei saa blokeerija treeningutele registreerida.Oleks võinud ka jälgimist ja tagasiside andmist piirata ning üldse peita kasutaja ilmnemist blokeeritud kasutajast, kuid neid võimalusi pole.

Koodi poole pealt on kasutatud korralikult UOW raamistikku: repo'd, interface'd. Huvitav on märgata, et UOW-s on baseurl, mille poole pöördutakse, klassi peal. Tore on näha, et on üritatud seda eraldada ülejäänust. See võimaldab kerget muutust olukorras, kui veebiteenus on kuskil mujal. Selel asukoht oleks võinud olla eraldi konfiguratsioonis. Vaatemudeleid on küllaga kasutatud, meeskonna enda koodis pole viewbag-e näha.

Tokenid töötavad korralikult. Kasutajaga peab uuesti sisse logima, kui projekt taaskäivitatakse.

Järgnevalt tulevad probleemsed kohad.

Sisse logides väära emailiga jookseb leht kokku kollase surmalehega. See näitab, et html response’d pole päris korralikult tehtud.

Oma andmeid pole võimalik muuta. Sarnase sotsiaalmeedia taustaga rakenduses võiks vähemalt olla nime lahter, millega on parem kasutajaid tuvastada.

Kasutajate ja rollide haldus on olemas, kuid see on välja kommenteeritud. Tehniliselt kasutajate haldus ka töötab, kuid kuna cascate kustutamine on veebiteenusest maha võetud, siis jookseb leht kokku, kui kasutajal on vähemalt 1 seos millegiga. Lisaks näitab kasutajate muutmisel securitystampi ja passwordhashi, mis on loomulikult halb. Meeskonna enda tabelite kustutamisel pole probleemi, sest äriloogikas on see käsitsi ära tehtud, kuid neid kahjuks ei saa jällegi kuidagi muuta, sest see on välja kommenteeritud. Kommenteerimise maha võttes muutmine jällegi jooksutab lehe kokku.

Kokkuvõtteks võiks öelda, et näidati ainult neid omadusi, mis töötasid. Kõik ülejäänud kommenteeriti välja. Meeskond kasutas raamistikku hästi ära. Probleemiks jäi äriloogika, kus ei realiseeritud kõike olemasolevat.