Talk:JRT

Hinnang meeskonna JRT esitatud XML-failidele

Koostaja: Team SPOT

Meeskond JRT on esitanud XML-faili, skeemifaili ja kaks XSLT-faili andmete transformeerimiseks HTML- ja XML-formaati. Transformatsioonid sisaldavad enam kui ühte for-each-klauslit. HTML-väljundiga transformatsioonis on kasutatud nelja for-eachi ja kolme if-tingimust. XML-väljundiga transformatsioonis on kasutatud viite for-eachi ja kolme if-tingimust. XML valideerub ja loogilisi dimensioone on viis. Neljal dimensioonil on kasutatud atribuute, mis on enam kui lihtsalt ID. Töö põhinõuded on täidetud.

Märkused XMLi/XSD kohta:

• elemendi <user> id-atribuudi väärtuse unikaalsus ei ole tagatud
• elemendile <user> saab lisada piiramatul arvul sama alamelementi: <firstName>, <lastName>, <born>, <sex>, …
• elemendil <user> on kõigi <subscription>-elementide type määratud kõige ülemisel tasemel status-atribuudiga, aga see võiks olla <subscription>-tasemel, et võimaldada rohkem paindlikkust
• atribuuti id (unikaalset) võiks kasutada ka teiste “liigielementide” puhul, sest:
  • elemente <subscription> saab sama name-atribuudiga lisada piiramatul arvul
  • elemendi <subscription> alla saab lisada piiramatul arvul <price>-elemente samade type- ja currency-atribuutide väärtustega
• elemendi <subscription> name-atribuudiga võib tekkida probleeme, kui atribuuti pandud nimi sisaldaks erimärke, seega oleks mõistlikum name-atribuut asendada eraldi alamelemendiga <name></name>, kus saaks kasutada CDATAt.

Tööga on nähtud vaeva, XSLTd on koostatud arusaadavalt, kuid XSD ja XML vajaksid täiendamist, et vältida võimalikke ohukohti andmete saatmisel. Vastasel korral võivad ka transformatsioonid ootamatusi toota (vt näidet). Põhiline oleks XSDs ära märkida, kui palju mingit elementi esineda võib ning tagada ka id-atribuudi unikaalsus. XMLi koostamise puhul tuleks läbi mõelda kas atribuudid on mõistlikult valitud või saaks neid esitada paremini alamelementidena.

Näide:

Name: Peeter Banaan
Member status: gold
Workouts and prices:

• Balance: 39.99EUR
• Balance: 39.99EUR
• Balance: 39.99EUR
• Gym: 69.99EUR
• Yoga: 39.99EURYoga: 39.99EURYoga: 39.99EUR

JRT esitatud töö asub siin.

Hinnang meeskonna JRT esitatud veebiteenusele

Koostaja: Team SPOT

JRT veebiteenus on mõeldud jõusaali külastajale, kes näevad erinevatele kehaosadele mõeldud harjutusi, treeningukavasid ning ja saavad üles märkida oma saavutusi. Projekti realiseerimiseks on kasutatud REST arhitektuuri ja ASP.NET MVC Web API tehnoloogiat. Andmebaas luuakse Entity Frameworki abil. Lahendusele on lisatud Asp.Net Identity (Individual User Accounts) funktsionaalsuse võimalus.

Teenuse lähtekood on jagatud kihtidesse: BL (äriloogika, andmeobjektid, teenused), DAL (suhtlus andmebaasiga, repositooriumid), Domain (olemid), Web (kontrollerid), eraldi teek on ka liidestele (Interfaces). Samuti on kasutatud sõltuvuste süstimist (Ninject) ning repositooriumide puhul Factory ja UOW mustrit. Web projektis on koos, aga eraldi kaustades, nii teenuse API kontrollerid kui ka veebikliendi MVC kontrollerid ja AngularJS kontrollerid.

Meeskonna lehel avaldatud veebiteenuse analüüsis endale eesmärgiks seatud kohustuslike funktsionaalsuste hulka kuuluvad: kasutajagrupid, konto loomise võimalus, isiklike andmete ja kavade salvestamise võimalus, treenerite info ja kontaktandmed. Lisavõimalusena sooviti luua ka kasutusstatistika ja -analüüsi tuge ning administraatori liidest.

Praeguse seisuga esitatud teenuse kohta pole meeskond kommentaare lisanud, mistõttu on keeruline kõigest ülevaadet saada ja tehtut adekvaatselt hinnata. Andmebaasi skeemi juures võiks olla ka tabelite kirjeldused ja olemite omavaheliste seoste selgitused. Esimese hooga on raske skeemi loogikast aru saada.

Eelnevalt mainitud põhifunktsionaalsused on ühel või teisel kujul ka realiseeritud: teenusest on võimalik kätte saada infot erinevatele kehaosadele mõeldud harjutuste, erinevate treeningühikute, treeningkavade ja päevaplaanide kohta, samuti kasutajate andmeid. Ka uute kasutajate lisamine on võimalik. Täiendavate funktsionaalsuste realiseerimiseni pole jõutud.

Andmebaasi migratsioone pole projekti selles faasis lisatud. Andmebaasi kustutamise või olemites tehtud muudatuste korral luuakse uus andmebaas, mis populeeritakse DAL kihis asuva DBInitializer klassi Seed() meetodis olevate andmetega.

Küsimusi tekitab kasutajate haldus. Nimelt on tehtud andmebaasi teenuse kasutajatele eraldi olem AppUser, kuhu saab lisada kasutajaid ilma Asp.Net Identity funktsionaalsust kasutamata. Sealt on ilma autentimiseta võimalik kätte saada kõigi kasutajate isikuandmeid. Paralleelselt on alles jäetud ka UserInt olem, kuhu saab samuti kasutajaid lisada, viimaseid on võimalik autentida läbi Web projektis asuva Account kontrolleri. AppUserit on võimalik siduda UserInt olemiga, aga see ei kajastu meeskonna lehel esitatud andmebaasi skeemis.

Account mudelid on samas ümber kolitud BL kihis asuvasse DTO-de kausta. Kas see on ikka õige koht? Pigem võiks need ju asuda Web projektis, kus asub vastav kontroller ja kus autentimine ja autoriseerimine tegelikult peaks toimuma. Silma jäi seegi, et nii Asp.Net Identity kui ka mõned teised paketid (näiteks Ninject) on lisatud alamprojektidesse, kus neid vaja ei lähe.

Asp.Net Identity funktsionaalsust tegelikult siiski kuskil ei kasutatagi. Autentimist pole üheski kontrolleris peale AccountControlleri rakendatud, aga see pole praegu muu teenusega seotud. Kõigile andmetele pääseb takistusteta ligi otse brauserist. Samuti on võimalik näiteks Fiddleri abil andmeid muuta ja kustutada.

Andmebaasiga suhtlemine käib läbi DAL kihis asuvate repositooriumide, kuid kasutusel on ainult standardsed meetodid: All(), Find() / GetById(), Remove(), Add(), Update(), SaveChanges(). Ühtegi kohandatud viisi andmete kättesaamiseks või muutmiseks pole repositooriumidesse lisatud - need on kõik tühjad. Sama lugu on ka BL Services kihiga.

Web projekti kontrollerites pole hetkel samuti ühtegi kohandatud IHttpActionResult meetodit realiseeritud. Ka on puudu mõned tavapärased meetodid. Bodyparts ja RoutineWorkouts kontrollerid ei võimalda ID järgi objekti kätte saada. Konkreetse objekti selekteerimine on nende andmete puhul seega jäetud kliendi mureks.

Nagu juba eelnevalt mainitud, siis ühegi kontrolleri kasutamist pole praegu autentimisega piiratud ja kasutajarolle ei rakendata.

Service kihis tuleks üle vaadata Edit() meetodid, sest need ei tööta olemite puhul, millel on suubuvaid seoseid teiste olemitega. DTO klassides on tehtud osa atribuute kohustuslikeks, mistõttu on ka seotud olemite loomine ja muutmine läbi teenuse keerulisem kui ehk peaks. Lisaks id-atribuudile tuleb mõnel puhul kaasa anda ka objekti nimi. ProgramDTO puhul puudub aga näiteks id-atribuut sootuks.

Domeeni kihis on rohkem olemeid, kui praegu teenuses ära kasutatakse, aga kõiki funktsionaalsusi polegi jõutud veel realiseerida. Annotatsioonid on olemas. Vajalikud atribuudid on muudetud kohustuslikuks ning stringide pikkused piiratud. Küll on domeeni tasemel jäetud kohustuslikuks tegemata AppUseri ees- ja perenimi. Need piirangud on lisatud Account mudelites.

Üldkokkuvõttes võib siiski öelda, et kui autentimine ja autoriseerimine välja jätta, siis on nõutud põhifunktsionaalsused veebiteenuses lahendatud. Lahendus on jagatud kihtidesse ning äriloogika on kontrolleritest välja jäetud. Andmebaasis on olemeid piisavalt ja neid andmeid on võimalik läbi API kätte saada. Projekt on piisavalt keeruline ja selle lõplik realiseerimine nõuab ilmselt rohkem aega ja pühendumist, mida käesoleva aine sisu, mahtu ja ajakava arvesse võttes oleks ülekohtune nõuda.

JRT esitatud töö asub siin.

Hinnang meeskonna JRT esitatud klientrakendusele

Koostaja: Team SPOT

JRT veebiteenuse vastu töötava klientrakenduse loomisel on kasutatud Angular JS raamistikku koos Asp.Net MVC kontrollerite ja vaadetega (Razor). Angulari osa on eraldatud App kausta. Koodis on kasutatud ka jQueryt. MVC kontrollerid ja vaated on tekitatud scaffoldingiga. Seega pole pidanud eraldi vaeva nägema ruutimisega. Kuna klient on lisatud samasse projekti, kus asuvad ka API kontrollerid, siis pole pidanud kliendi jaoks eraldi salvestama teenuse baasaadressi, mille vastu päringuid tehakse.

Meeskonna lehel avaldatud teenuse analüüsis on välja toodud kaks liidest, mida soovitakse arendada. Administraatoriliideses peaks administraatoril olema võimalus hallata kõiki andmeid (näiteks lisada ja kustutada: kasutajaid, harjutusi, treenigukavasid jne). Kasutajaliideses peaks tavakasutaja saama sisestada oma keha kohta viimaseid andmeid, panna kirja infot viimase treeningu kohta ning lisada omale kontaktandmeid, valida treeningukavasid ja paigutada need soovitud päevadele.

Mingisuguseid kommentaare avaldatud klientrakenduse kohta meeskonna lehelt leida ei õnnestunud. Lisaks leidub lähtekoodis lõpuni realiseerimata osasid, mis tegelikult rakenduse tööd ei mõjuta. See tegi retsenseerimise keerulisemaks, aga üldjoontes on kõigest hoolimata võimalik lahenduse tööpõhimõttest aru saada, kui rakendust natuke testida ja lähtekoodi uurida.

Praeguse seisuga on veebikliendis osaliselt teostatud administraatorile mõeldud funktsionaalsus. Kasutajaid hallata veel ei saa, aga harjutusi ja treeningukavasid on võimalik lisada. Realiseerida on proovitud ka tokenipõhist autentimist, kuid see ei tööta, mis on arusaadav, kuna kasutajahaldus ja autentimine / autoriseerimine on jäänud praeguse seisuga realiseerimata ka teenuse API poolel. Ilmselgelt on näha, et töö jäi pooleli.

Angulari rakenduse kontrolleritega on veebikliendis tööle pandud neli vaadet: Exercises, Units, BodyParts, Routines. Neile pääseb ligi menüüribale lisatud linkide kaudu. Users vaade on ka olemas, aga ilma Angulari kontrollerita - andmeid ei laeta. Sellele vaatele pääseb ligi, kui lisada brauseri aadressiribal domeeni lõppu “/Users”. Tokenipõhise autentimise jaoks on tehtud ka MainAngular vaade (domeen/MainAngular), kuid see ei toimi.

Kõik olemasolevad vaated on sama ülesehitusega - kuvatakse nimekirja koos Edit ja Delete nuppudega. Filtreid andmete sorteerimiseks ei ole. Igal vaatel on olemas on ka Add New nupp. Andmete lisamiseks ja muutmiseks avaneb hüpikaken (modal), kuhu laetakse kõik objekti jaoks vajalikud input-väljad - ja seotud olemite puhul valiku tegemiseks ripploetelud. Objektide kustutamisel küsitakse kasutajalt kinnitust. Kõik pakutud funktsionaalsused paraku veel ei tööta. Probleeme on eeskätt teiste olemitega seotud olemite muutmise ja kustutamisega.

Funktsionaalsused vaadete kaupa:

• Units - andmete kuvamine, lisamine, muutmine ja kustutamine töötavad
• Exercises - andmete kuvamine, lisamine ja kustutamine töötavad, ent muutmine töötab ainult osaliselt: kui muuta harjutuse mõõtühikut, siis veast ei teavitata, aga muudatus andmebaasi ei jõua (Fiddleriga otse teenuse API poole pöördudes lisandus andmebaasi uus kirje)
• BodyParts - andmete kuvamine, lisamine ja kustutamine töötavad, aga muutmine ei õnnestu (ka Fiddleriga otse teenuse API poole pöördudes). Kui üritada muuta kehaosa alla kuuluvate harjutuste nimekirja, siis tuleb vastuseks Http staatus 400 (Bad request!)
• Routines - andmete kuvamine ja lisamine töötavad, muutmine (ReferenceError: bodyPart is not defined) ja kustutamine ei õnnestu (Bad request)!

Vaadete puhul võib nuriseda selle üle, et iga kontrolleri kohta on tehtud ainult Index vaatefail, mis sisaldab endas nii põhiakna kui ka hüpikakende html-koodi. Need oleks võinud parema arusaadavuse huvides ju lahutada, isegi kui andmete laadimine toimub läbi sama kontrolleri.

Lähtekoodist ilmneb veel, et iga töötava vaate jaoks on tehtud eraldi moodul oma kontrolleriga, mis registreeritakse vastavas vaates. Keskne moodul failis app.js ei tööta, see on mõeldud tokenipõhise autentimise realiseerimiseks ja eeldab üheleherakendust (ruutimisinfo on ka samas). Kõiki autentimise töölesaamiseks vajalikke mooduleid ei ole samas projekti lisatud (authService, authInterceptorService).

Praeguse lahenduse üheks puuduseks on veel see, et kõik Http-päringud veebiteenusele tehakse otse Angulari kontrolleritest, puudub vahepealne service-kiht. Selle tagajärjel on päringud ja vaadete loogika koodis läbisegi. Hüpikaknas objektide muutmiseks ei pärita andmeid uuesti teenusest, vaid muudetakse juba varem põhiaknasse laetud andmeid. Lisaks on Angulari raamistiku kõrval kasutatud ka tavalisi jQuery võtteid, mis teeb üldpildi võrdlemisi kirjuks. Mõned funktsioonid ei tööta korrektselt ja nii on üsna keeruline aru saada, kus viga täpselt asub: kontrolleris või teenuse API poolel.

Kokkuvõttes võib tõdeda, et olemasolevate vaadetega on siiski vaeva nähtud ja suhtlus teenusega tööle saadud, mis selle aine puhul on ilmselt peamine. Mõned funktsionaalsused vajavad veel viimistlemist, projekti üldine ülesehitus korrastamist. MVC kontrolleritega autentimise tööle saamiseks tuleks olemasolevad kontrollerid siduda keskse app-mooduliga ning see omakorda jagatud Layout vaatega, millele tuleks ka lisada eraldi kontroller.

JRT esitatud töö asub siin.