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 esitatud töö asub siin.