Talk:Tab

XML andmefaili retsensioon meeskonna Taandarendajad poolt

Esmalt sai kontrollitud XML koodi W3 validaatoriga ning kõik oli korras. Meeskond on loonud nõutud arvu dimensioone. Täpselt kolmel elemendil on kasutatud unikaalseid atribuute, mis on enamat kui ID. Sellest ei saa täpselt aru, miks on loojaId eraldi element, kui ta võiks olla looja elemendi atribuut. Elementide info on kenasti pandud kõik CDATA vahele. Samuti tundub, et XSD failiga on kõik korras ning igal elemendil ja atribuudil on õiged andmetüübid.

Esimese transformatsiooni faili juures on kasutatud edukalt atribuuti privaatne, mis kuvab false väärtuse korral toa html koodis. Teises transformatsiooni failis on korrektselt loodud tabel kahe tulbaga. Kolmandas failis luuakse edukalt uus XML fail.Peale struktuuri muutmist on veel kokku loetud kasutajate arv ning see eraldi elemendina edastatud.

Kokkuvõttes on meeskond Tab lahendanud esimese ülesande väga oskuslikult. Hea oli näha, et oli ka transformatsiooniga loodud uus XML fail, sest tunnis me seda osa läbi töötada ei jõudnud. Esialgse XML faili maht oli hea ning kõik kriteeriumid said ka neil täidetud.

Veebiteenuse retsensioon meeskonna Taandarendajad poolt

Lisaks Identity mudelitele on meeskond loonud 4 tükki veel ise. Mis kohe silma hakkab on see, et kõik atribuudid algavad väikese algustähega. See ei ole väga suur viga ma usun, aga visual studio ise ka karjub iga rea peal, et atribuudid peaks algama suure algustähega. Ära on ise määratud isegi primary key-d ja foreign key-d. See on väga tore, aga entity framework peaks ise ka sellega hästi toime tulema. Hea on näha, et kõikide stringide pikkused on ka ära piiratud. Meeskond on ka oma kasutaja mudeli teinud lisaks Identity omale. See on arvatavasti tingitud sellest, et me ei saanud teise aine raames väga head ülevaadet sellest Identity projektist, et seda täielikult ära kasutada. Kokkuvõttes on mudelid põhjalikud ning hästi läbi mõeldud.

DataBaseContexti vaadates tunnen kohe ära, et meeskond on sama probleemi otsa sattunud nagu mina ise. Nimelt mitmete foreign key kasutamisel tekkis selline olukord, kus ühe sissekirje kustutamisel tabelist oleks mujalt tabelitest ka info kaduma läinud. Selle vastu aitas WillCascadeOnDelete väärtuse muutmine false-iks. Hea on ka näha seda, et samas failis toimub administraatori kasutaja loomine. Meeskond on kasutanud interface-e, reposid ja uow-d, nagu nõutud oli.

Veebiteenuse juures on ka kasutusele võetud BLL projekt, kuhu on kogu äriloogika paigutatud. DTO-d on huvitavalt tehtud. Iga mudeli jaoks on kaks DTO-d, kus üks tuleb ilma virtuaalsete listideta ja teine koos nendega. Kahju on näha, et service kaustas on tegeletud ainult tervete andmebaasitabelite tagastamisegal. Ei toimu mitte mingit sorteerimist. Väikese mahuga andmebaasiga pole sellest hullu, aga kui tegemist oleks mingi väga populaarse teenusega, siis muutuks päringute tegemine väga aeglaseks. Sellist sorteerimist oleks tahtnud näha DAL-is, aga seal ei olnud mitte ühtegi custom meetodit.

Web API-st on näha, et ninject on ka kasutusele võetud nii nagu peab. Kontrollerites on näha, et igal pool on korrektselt ühendus loodud UoW-ga, mitte otse andmebaasiga. Siin on valdavalt näha ainult crud meetodeid ja igas kontrolleris on üks custom meetod, mis tagastab kõik kirjed andmebaasist. Oleks tahtnud näha veidi keerulisemaid meetodeid. Meeskond on ränka vaeva näinud hea BLL-i loomisega, aga crud meetodites tagastatakse ikka ainult domainis loodud mudeleid. Tekib küsimus, et mille jaoks siis üldse BLL loodud sai.

Kokkuvõttes on veebiteenuse loomisega hästi hakkama saadud. Domain on hästi loodud, arendusmustreid on järgitud, BLL on olemas ja toimib. Arvatavasti on mõndade asjade puudumine põhjendatud sellega, et lihtsalt tekkis ajapuudus semestri lõpus. Hea töö!

Veebirakenduse retsensioon meeskonna Taandarendajad poolt

Meeskond on loonud ASP.NET veebirakenduse enda poolt arendatud veebiteenusele. Välimuse ja UI poole pealt on nagu paljude teistegi tudengiprojektide puhul tegemist Visual Studio poolt pakutava baaskujundusega. Küll aga on meeskond korralikult eemaldanud üleliigsed elemendid ja viinud sisse muudatused, et veebirakenduse disain vastaks meeskonna loodud rakenduse sisule. Küll aga oleks võinud mõnes kohas muuta genereeritud lahenduse tekste (nt. roomTypeID). Samuti oli veidi segane see, kui rakendus küsib ruumi loomisel parooli sisestamist isegi siis, kui ruumile paroolinõuet ei lisata. Üldiselt on aga rakenduse visuaalne ning kasutatavuse pool piisavalt korralikult ja mõistlikult lahendatud.

Veebirakendus kasutab ootuspäraselt peaaegu täielikult ära veebiteenuse poole peal loodud domain projekti koos endas sisalduvate mudelitega. Hea on näha, et veebiteenuse ja veebirakenduse domain projektid ei kattu üks-ühele, vaid mudelite kasutus on tehtud sobivaks vastavalt eesmärgile – veebirakenduses olevad mudelid omavad puhtalt MVC projekti jaoks mõeldud lisavälju/atribuute. Mingis mõttes tekitab selline lähenemine, kus kahes erinevas kohas on sisuliselt samad asjad, mõningasi kahtlusi arendustöö käigu mõistlikkuses ja efektiivsuses. Muutus ühel pool tähendab ka samasuguse muutuse sisseviimist teisel pool ning hetkel tundub, et mõttekam lähenemine oleks võinud olla ühe domeeniprojekti kasutamine nii veebiteenuse kui ka rakenduse jaoks. Nagu ka veebiteenuse retsensioonis mainitud sai, võib veidi viriseda selle üle, et vaatamata loodud BLL projektile tundub kogu andmevahetus olevat siiski üles ehitatud andmebaasi mudelitele. Samas on tegemist väga väikesemahulise projektiga ning seetõttu võib juba varem loodud mudelite ärakasutamist igati aktsepteerida.

Ka rakenduse poolel on kenasti ära kasutatud DAL projekti, mis hõlmab endas UOW ja repo mustrite kasutamist, nii nagu kursuse vältel õpitud ja nõutud. Küll aga oleks siinkohal repode puhul näha tahtnud mingisugust lisafunktsionaalsust custom päringute näol teenusest, mille meeskond ise on loonud. Hetkel on piirdutud pea täielikult õppejõult saadud out of the box lahendusega, millele on enda mudelite kasutamiseks vajalikud täiendused juurde pandud.

MVC rakenduses kasutatakse loodud uow-d ära. Kontrollerites ja vaadetes kasutatakse segu nõrgast ja tugevast tüüpimisest. Üldiselt soovitatakse pigem kasutada tugevalt tüübitud vaateid (ASP.NET aines oli see isegi nõutud). Mingi hulga viewmodeleid on meeskond aga ära teinud ja kasutusele võtnud. Muus osas aga toimiv ka viisakas lahendus.

Kokkuvõtvalt võib öelda, et nii nagu veebiteenusega, on ka veebirakenduse loomisega tehtud teenuse peale hästi hakkama saadud. Meeskond on vormistanud mõistliku ülesehitusega lahenduse ja jälginud arendusmustreid. Suures plaanis on ülesandepüstituses nõutu rakenduses olemas. Vingumist väärib ainult see, et meeskond oleks võinud projektidesse standardlahenduste kõrvale juurde teha ka huvitavat ja enda poolt loodud lisafunktsionaalsust.

Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon

KLIENTRAKENDUS:

Üldine:

Tab meeskonna loodud lehel olid olemas vajalikud XML-id, mis olid loodud projekti kohaselt. Samuti oli olemas projekti analüüs, kus on välja toodud nii „Must Have“ kui ka „Nice to Have“. See annab parema ülevaate projektist ning selle ettenähtud ning planeeritud funktsioonidest. Esimese asjana oli märgata, et klientrakendus üksi tööle ei lähe, kuna see oli juba Web-Apiga ühendatud. Algul jäi segaseks, kus Web-Api täpsemalt asub, kuna see ei olnud samas kaustas. See probleem sai lahendatud kui sai avatud teine Visual Studio, kus tuli avada teises kaustas olev Web-Api.

Kood:

Vaadates projekti ülesehitust, oli näha, et kasutatud oli MVC loogikat, kus eraldi olid paigutatud mudelid, andmebaasi andmed/loomine ning projekt ja projekti osad. Mudelite all oli märgata 4 olemit: ruumid, ruumide tüübid, kasutajad ja kasutajate tüübid. Kuigi nõuetes oli kirjas, et projektis peaks olema vähemalt 6 olemit (mille alla ei kuulu Identity olemid), siis ei ole teada, kas neid tuleb projekti edasi arendades veel juurde. Samuti, kui kogu projekt töötab ka ilusti 4 olemiga, ei pea neid ilmtingimata juurde vaja. Olemi klassides oli kasutatud andmetüüpide täpsustusi, vajalikust ning ka sisestuspikkuste kontrolle. Muutjate nimed olid ilusti kõik inglise keeles. Siiski, oli lähemal vaatusel märgata nimede vahelisi erinevusi. Näiteks „RoomUser“ all oli kirjes olemas „RoomId“. Samas „Room“ klassi all oli kirjas see kui „roomID“. Kuigi see otseselt funktsionaalsusele ei mõju, oleks hea kui need oleks ühtemoodi kirjeldatud, sest see võib koodi lugemist ning arusaamist raskemaks muuta.

Igas loodud controlleris oli kasutatud hästi „Unit of Work“ printsiipe. Kõiki controllereid oli ka vastavalt projekti vajadustele muudetud. Eemaldatud olid üleliigsed meetodid ning funktsioonid. Kasutatud oli autoriseerimist. Seda oli tehtud niisama kasutajate autoriseerimisega kui ka meeldivalt rollide põhiselt. See tähendab, et tavakasutajad ei saa ligipääsu sinna, kuhu neil asja ei ole.

Paljude controllerite kohta on loodud ka ViewModelid. Küll aga oli näha, et kõigi kohta neid loodud ei oldud ning mõned vaated olid otse vastu andmebaasi. See võib olla turvarisk. Mõnes ViewModelis, kus seda vaja oli, oli kasutatud ka andmetüüpide ja pikkuste täpsustusi.

Testimine:

Rakendust tööle pannes on näha, et välimuselt paistab see klientrakendus olevat nagu teisedki „Out of the Box“ välimusega lehed. Vaateks oli seatud default välimus, mis asetatakse rakendusele kui rakendus esialgselt luuakse. See võis oleneda sellest, et projekt on tehtud A. Käveri poolt õpetatud ASP.NET aines valminud näidete põhjal. Kuigi see funktsionaalsuse poole pealt otseselt ei loe, oleks hea, kui rakendusel oleks nii funktsionaalsust kui silmailu. Meeskond Tab on siiski eemaldanud palju üleliiast ning ebavajalikku, mida loodud projekti puhul vaja ei olnud. Muudetud on ka footeri tekst, mis küll ei muuda palju, aga näitab, et lehte ei ole tahetud täiesti algeliseks jätta. Ära oli muudetud ka koduleht, kuhu oli meeldivalt välja toodud rakenduse kasutusstatistika. Muuta võiks veel rakenduse üleüldist välimust, pannes näiteks tausta ning muutes värve vaatajatele erksamaks.

Üritades kasutajaga sisse logides, oli näha, et ilusti näidatakse kasutajale veateateid kui midagi on valesti sisestatud. Alles oli jäetud aga Google kontoga logimine, mis ei töötanud. See tuleks kas korda teha või täielikult eemaldada.

Kasutajat registreerides kuvati samuti kõik vajalikud veateated. Kasutatud oli ka CheckBoxiga isiku soo küsimist, mis oli teiste meeskondade lahendustest erinev tunnus. Kasutaja sai edukalt registreeritud. Siinkohal aga mainiks, et lihtsa parooliga läbi lubamine (sisestuseks sai 123), võib tekitada turvariske kuna kasutajaid on lihtne lahti muukida.

Testimise käigus selgus, et kasutaja andmeid on võimalik muuta. Sinna on aga sisse jäetud ka funktsioonid, mis otseselt ei tööta ning mida võibolla vaja üldse ei lähe.

Esimese asjana sai testitud ruumide loomist. Märgata oli, et sisse on jäetud segased muutjate nimed. Näiteks oli alles veel „roomTypeId“. Samuti olid „description“ väikse tähega kuigi ruumi nimi oli kirja pandud suure tähega. Ruum loodi siiski edukalt. Koheselt tekkis kirje ka ruumide kokkuvõtte alla. Seega loomine töötas veatult.

Ruumide testimisel sai edukalt ruumidega liitutud. Kasutaja sisestatud laused edastatakse ilusti ekraanile edasi. Siiski võib ära märgata, et saata saab ka tühje stringe mis ei pruugi kõige parem lahendus olla. Sellele on aga kiire ning lihtne parandus.

Kokkuvõte:

Üleüldiselt tundus klientrakenduse pool olevat funktsionaalsuselt töötav ning piisav ka maksimum punktideks. Küll aga võiks soovitada lehe välimust natuke paremaks teha.

VEEBITEENUS:

Üldine:

Kuna veebiteenuse pool ei väljendu otseselt läbi vaate, vaid ainult koodi, siis Web-Api-t tuleb uurida rohkem koodi poole pealt. Keskendatud on projekti üldisele ülesehitusele ning koodi puhtusele ja professionaalsusele. Nagu eelnevalt mainitud, oleks hea kui veebiteenuse pool oleks koos klientrakenduse poolega, kuna see muudab kontrollimise ning vastavuse vaatamise tunduvalt lihtsamaks.

Üldiselt peale vaadates, on ka Web-Api ehitatud A. Käveri poolt õpetatud õppeaine ASP.NET-i jooksul valminud näidete põhjal. Kuna aga Web-Api on edukalt kohendatud vastavalt loodud projektile (klientrakendus töötas ilusti), siis näitab see, et meeskond on materjalidest ning põhimõtetest aru saanud. Nagu klientrakenduseski, on siin kasutatud: Domain (mudelid), DAL (andmebaas), Identity (kasutajahaldus), BLL/DTO (äriloogika) ning WebApi projekti ja projekti osasid.

Alustades DAList ehk Data Access Layerist, on näha, et kasutatud on kõike vajalikke osasid: Config, Interfaces, Repositories ning andmebaasi enda loomiseks mõeldud DataBaseContext-i. DataBaseContextis on ka näha, et andmebaasi luues, seeditakse ehk siestatakse algselt ka mõned väärtused automaatselt. Ruumitüüpide alla lisatakse kaks võimalust: „Adminnidele“ ning „Useritele“. Kuna neid eelneval testimisel ei olnud näha tüüpide lisamist ning klienrakenduses neid niisama lisada ei saanud, võib siinkohal öelda, et ruumitüüpide menüü piiramine ainult adminitele töötas meeskonnal edukalt. Andmebaasi lisatakse ka peamine admin account. Suureks veaks aga oli märgata, et kasutaja sisestatakse manuaalse ID, Password Hashi ning Security Stampiga. Neid on võimalik lasta genereerida andmebaasi loomisel. Siin kohal soovitaks meeskonnal uurida PasswordHasheri meetodit ning GUID loomist. Andmebaasi sisestatakse ka 2 peamist rolli: Admin ning User(tavakasutaja). Siin kohal peaks ära märkima, et otseselt ei ole User accounti vaja küll luua, kuna useriteks on tehtud tavakasutajad juba algselt. Küll aga on see projekti enda loojate mõelda kas seda on siiski vaja ning sellel võib veel olla mingi kindel eesmärk. Tore on ka näha, et lahti on saadud eelnevate retsenseerijate mainitud CascadeOnDelete meetodist. See tähendab, et andmebaasi tabeli kirjed ei jää õhku hõljuma ning ei tekita ei kasutajatele ega rakenduse loojatele probleeme.

Web-Api poole pealt on samuti kõik mudelid ilusti ära tüübitud ning piiratud. Kuna need mudelid on tehtud aga üks-ühele vastavusse klientrakenduse poolega, siis on ka siin eelnevaltmainitud muutjate nimede ebakattuvus.

Väga meeldiv oli näha, et meeskond oli teinud ka äriloogika poole. Äriloogika oli loodud kõikide mudelite ning isegi kasutajate kohta. Kõik vajalikud osad tundusid olemas olevat ning kõik oli väga põhjalikult tehtud. Seega siin kiidaks meeskonna väga tublit tööd.

Web-Api enda projekti alamvaates olid olemas kõik vajalikud controllerid. Nendes oli samuti kasutatud ilusti UOW printsiipi ning sisse olid viidud vajalikud muudatused et seda kõike enda projektile vastavaks muuta.

Nõuete täitmine:

• Teenuse pakkumine – meeskonna lehel kirjeldatud teenus on täidetud peaaegu täielikult (analüüsis loodud must-have on peaaegu täielikult teostatud), seega saab väita et see nõutud punkt on täidetud.
• Teenuse kasutajate tuvastamist ning haldamist – kasutajaid on võimalik registreerida, nendega sisse logida ning oma andmeid muuta. Toad käivad samuti registreeritud nickname ehk hüüdnime järgi. Seega on ka see punkt meeskonna poolt täidetud.
• Teenuse kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes – pealehel on välja toodud palju statistikat, mida nõutud ja mida oleks vajalik näha.
• Teenuse poole pöördumiste arvu piiramist ja piirangute haldamist – paljud funktsioonid ning asjade loomised/muutmised on ainult admini poolsed. See tähendab, et piirangud on seatud ning tavakasutajal ei ole võimalik kõike teha.
• Loodav veebiteenus peab toetama mitme kasutaja võimalus – kuna ilma avaliku andmebaasita on mitme kasutaja korraga kasutust raske kontrollida, siis seda ei oska otseselt kommenteerida. Siiski on võimalik luua mitu kasutajat ning kõiki hoitakse üksteisest erinevalt.

Kokkuvõte:

Meeskonna veebiteenuse pool on väga suures osas täidetud ning seda ka täiesti edukalt. Olemas on kõik vajalik ning kindlasti väärib meeskond projekti eest rohkesti punkte. Küll aga võiks veel natuke välimust täiendada nii klientrakenduse kui veebiteenuse poole pealt, et nii kood kui rakenduse enda välimus oleks silmailu poolest väheke professionaalsem.