Talk:TÜC2

XML failide retsensioon meeskonna "Kipsplaat" poolt

Meeskonna TÜC2 poolt tehtud failid on jalgrattapoest. Kõik nõuded (XML fail, XSD fail, 2 XSLT faili) ja nende reeglid on täidetud.

XML andmefail on hästi loetav, meeskond võtnud kasutasele ka <![CDATA[]]> tagi õigetes kohtades, aga esinevad väikesed puudused.

Spetsifikatsioonid oleks mõistlikum lisada <spetsifikatsioonid> tagi sisse. Samuti XML peaks olema natuke universaalsem. Näiteks kui me tahame lisada uut spetsifikatsiooni, näiteks esihark või rehvid, siis meil tekib konflikt XML faili skeemiga. Kui me tahame võib-olla tulevikus hakata müüma ka jalgratta hooldusvahendeid või muud sellist, siis meil on vaja muuta kogu XML faili ja ka skeemifaili ning hiljem peab redigeerima ka transformatsiooni failid, sest teisel juhul võib kõik katki minna.

XSD (XML skeemifail) on korrektne.

XSLT (transformatsioonid) failidega on kõik hästi ja nad teevad seda mis nad ikka peavad tegema.

Kokkuvõteks, tegemist on hea tööga vaatamata väikesele puudusele. Kommentaariumide ning dokumentatsiooni puudumine sel juhul ei ole kritiiline, sest tegemist on väikese tööga ja kood on loetav ning arusaadav ilma ülalmainitute abivahenditeta.

XML failide retsensioon meeskonna "Kirves" poolt

Meeskond TÜC on oma töö aluseks võtnud jalgrattapoe. Loodud on .xml fail andmetega, skeemifail ning kaks .xsl faili, mis mõlemad loovad .xml failist .html faili. Xml fail sisaldab nelja loogilist dimensiooni, kuid hetkel pole täidetud nõue, et kolmel dimensioonil oleks atribuut, mis on enamat kui ID. Xml fail on arusaadav ja loetav, valideerub skeemifaili vastu ning kasutatud on ka CDATA välju. Meeskond on viitsinud otsida ka pildid ning tootjate veebilehed, et jalgrataste hinnakirja elavamaks muuta.

Kood on ilusti trepitud, kuid dimensioonide vahel võiks kasutada tühje ridu, et näha, kus üks algab ja teine lõpeb. See muudaks koodistruktuuri paremini loetavaks.

Skeemifailis on mõeldud ka andmetüüpide peale, näiteks on käikude arvuks kasutatud tüüpi unsignedByte. Muus osas on skeemifail mõistagi automaatselt genereeritud.

Transformatsioonidest üks on lihtsama teostusega ning teine tunduvalt keerulisem. Lisaks tavapärasele elementide ja atribuutide väärtuste kuvamisele on kasutatud ka for-each tsükleid ja vahemuutujaid.

Üldiselt võib öelda, et meeskond on oma töö läbi mõelnud ning mõnest väiksest puudusest hoolimata on aru saada, et on viitsitud vaeva näha. XML fail, skeemifail ja transformatsioonifailid on loogilise ülesehitusega. Soovituseks võiks tuua, et nii .xml-i kui muud koodi kirjutates võiks kasutada inglise keelt, mis jätab koodi poolt terviklikuma mulje, kuna funktsioonid ja muud parameetrid on juba nagunii inglise keeles.

XML failide retsensioon meeskonna "MeilEiOleGrupinime" poolt

Koostatud XML kujutab endast jalgrataste andmebaasi, kus on kõik mida näiteks kodulehel kuivamiseks vaja. Töö vastab nõuetele, dimensioone on täpselt neli. Atribuute on kasutatud, kuid vähe. CDATA-t on kasutatud (on vaieldav kas oleks võinud seda teha rohkemates kohtades).

Meeldiv oli näha, et on kasutatud kategooriaid (tag „Kategooria“ kus sees olid erinevad jalgrataste liigid). Seda kasutatakse XSLT juures, kus otsitakse ja sorteeritakse kategooriate järgi. Tegelikult oleks sama võinud teha ka värvustega.
Eespool sai mainutud, et atribuute on vähe kasutatud. Ühe oleks saanud pildi lingiga, kuna seda on vaid üks. Võimalik, et ka tootja oleks saanud panna atribuudiks. Seda seepärast, et ühe ühe jalgratta puhul oli see puudu ning seepärast võiks see ka olla valikuline atribuut. Samuti oleks võinud panna atribuudina mudeli nime ning seisukord tag asendada booleaniga „onUus“.

XSD failis vigu ei märka. Kõik on paistab olema korralik ning andmetüüpe on kasutatud mõistlikult.

Nõutud oli kaks XSLT faili ning need on ka olemas. Esimeses tuuakse välja kõik jalgrattad koos mudeli nimega ja kirjeldusega. Kaasa on pandud ka pilt. Teises oli kasutatud kategooriaid. Kõik kategooriad ja kui mõni jalgratas on selle kategooriaga siis on seal all tema link. Kui lingile vajutada siis minnakse selle täpsema informatsiooni juurde. Võib öelda, et XSLT-d on väga hästi tehtud.

Hoolimata mõnest väikesmast veast on tehtud töö korralik.
Meeskond "MeilEiOleGrupinime"

Teenuse ja klientrakenduse retsensioon meeskonna "Vargamäe" poolt

Meeskond TÜC on loonud veebiteenuse ja klientrakendused süsteemile, mis kannab nime Kyyt. Süsteemi eesmärk on lasta autoga Eestis reisivatel inimestel postitada kuulutusi, otsimaks auto peale kaassõitjaid, kellega kulutusi jagada. Ühele sõidukuulutusele on võimalik märkida, kust kuhu sõidetakse, millal ajal seda tehakse, kui palju on autos vabu kohti ning mis on ühe koha hinnaks. Samal ajal kui ühes otsivad kaassõitjaid, on süsteemil ka teine oluline kasutajaskond: inimesed, kes otsivad küüti.

Teenus

Süsteemi Kyyt Web API tehnoloogiat kasutades loodud teenus vastab kõigile projektikirjelduses teenusele esitatud nõudmistele.

Esimese asjana meeskonna TÜC solution’it avades, hakkab silma hästi struktureeritud kihiline arhitektuur. Nimelt on järgitud koolis õpetatud häid tavasid hoida eraldi projektides äriloogika mudeleid, andmebaasikihti (DAL), repositooriume, transpordiloogikat ja transpordimudeleid.

Kood üldiselt on kirjutatud loetavalt ja hästi struktureeritult (treppides). Kommentaare on retsenseerijate arvates kirjutatud piisavalt ja vajalikud meetodid on ka dokumenteeritud. Eriti tõstaks esile eeskujulikult kommenteeritud äriloogika mudelid, mida on lihtne lugeda ja mõista.

Sügavamalt transpordimudeleid uurides, võib näha, et tehtud on eraldi mudeleid erinevat liiki andmete liigutamise jaoks, mis on kindlasti mõistlik lahendus. Näiteks kuulutse objekti kohta on olemas kolm andmete liigutamiseks mõeldud klassi (DTO’d), üks detailse kuulutuse saatmiseks teenusest välja, üks saatmiseks tervet hulka (listi) kuulutusi teenusest välja ja veel üks võtmaks vastu kliendi poolt teenusele saadetavat kuulutust. Selline lähenemine on hea, kuna optimeerib pidevalt üle võrgu saadetavat andmehulka, pannes kaasa iga operatsiooni juures ainult neid andmeid, mida võiks vaja minna.

Teenuse kontrollereid lähemalt vaadates, selgub, et iga kontrolleri juures on realiseeritud küll kõik CRUD operatsioonid ja ka erinevaid süsteemi funktsioneerimiseks vajalikke kohandatud operatsioone, kuid ükski neist ei tagasta kunagi mingit teavet kliendile operatsiooni õnnestumise või luhtumise kohta. Nii on võimalik teenust probleemideta kasutada eeldusel, et kõik teenuse pihta tehtavad päringud on korrektsed ja mingeid vigu esineda ei tohi. See asjaolu teeb teenusele kliendi kirjutamise oluliselt keerulisemaks, kuna mitmesuguseid erandeid, mis operatsioonide käigus võivad juhtuda, ei tagastata päringu teele saatnud kliendile. See tähendab, et kui näiteks mõne objekti uuendamisel juhtub viga (näiteks seda objekti ei leita andmebaasist), siis kontrolleri meetod tagastustüübiga void ei teavita päringu teele pannud klienti ebaõnnestumisest ja kliendi arendaja peab leidma mingi viisi, kuidas kontrollida, kas plaanitud objekti uuendamine päriselt ka läbi läks. Selleks, et hõlbustada teenust kasutava kliendi kirjutamist, tuleks kontrolleri meetodid kirjutada selliselt, et need tagastaks ka veateateid ja ka teateid õnnestumiste kohta HttpResult vormis. Nii on kliendi poolt võimalik kontrollida teenuselt tagastatud vastust ja selle põhjal teha järeldusi, kuidas programmi tööd jätkata.

Klient

TÜC tiimi wikilehel oli küll kirjas, et teenusele on tehtud 2 klienti, WPF ja Web API vaated, kuid retsensiooni kirjutamise ajal tundus WPF projekti seis olevat poolik (või täpsemini alles alustamisel), seega järgnev tekst on kirjutatud Web API vaadete (MVC) kohta.

Kliendi kood on kirjutatud loetavalt – vaated, vaatemudelid ja kontrollerid on arusaadavad. Küll aga ei ole kliendi poolt kommenteeritud päris niisama hästi kui seda oli tehtud teenuse puhul, aga retsenseerijaid see ei häiri.

Kõik klientrakenduse kontrollerid pärinevad ühest baaskontrollerist, kuhu on kirjutatud sisuliselt baasteenus, mille meetodeid kasutades tehakse päringuid veebiteenuse pihta. Kontrolleritega samas kaustas on veel ka klass nimega Constants, milles hoitakse konstantsete muutujatena erinevate teenuste aadresse. Nende kasulikkus jääb pisut arusaamatuks, kuna eraldi muutujasse on salvestatud baasaadress ning erinevate teenuste aadressid nii, et teenuste aadressid on kõik ka üks haaval ise pikalt välja kirjutatud ja ei sõltu baasaadressist, seega kui baasaadress peaks muutuma, tuleb lisaks sellele vastava konstandi väärtuse muutmisele muuta veel ka iga teenuse jaoks eraldi olevat aadressi. Erinevate teenuste aadressid võiksid olla vabalt lühemad ja nende kasutamisel mõnes muus failis võiks täis-pika aadressi saamiseks neid lihtsalt „kleepida“ baasaadressile otsa, nii oleks koodi hallatavuse mõttes kasulikum. Samas on konstantide klassi salvestatud ka üks aadress kuulutuste kohta käiva teenuse jaoks, mida kusagil rakenduses ei kasutata. Hoolimata sellest, et aadressid on eraldi salvestatud teise faili, on rakenduse kõige põhilisema kontrolleri (AdvertController) konstruktorisse kirjutatud teenuse aadress ilma konstanti kasutamata. Klient küll toimib nii, nagu ta hetkel on, aga konstantide kasutamine võiks olla efektiivsem.

Nagu juba varasemalt mainitud, toimub klientrakenduse põhilise funktsionaalsuse juhtimine kuulutuse kontrolleris (AdvertController), kus igale action’ile on olemas vastav vaade ja kõik vaated on tugevalt tüübitud, st põhinevad vaatemudelitel. Klient tuleb hästi toime andmete küsimisega teenuselt ja ka nende posti päringute abil teenusele saatmisega. Sõidukuulutus märgitakse automaatselt vanaks, kui hetkeaeg on möödas kuulutusele kirjutatud väljasõiduajast. Küll aga jääb küsitavaks kommenteerimise osa – nimelt ei õnnestunud leida kliendilt kohta, kust saaks kuulutuse alla kommentaare jätta. Manuaalselt andmebaasi kommentaaride tabelisse ridu lisades, võis näha, et kuulutuse all kommentaaride kuvamine töötab, aga klienti kasutades neid lisada ei õnnestunud.

Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt

Teenus: Lahendus on jaotatud erinevatesse projektidesse vastavalt aine käigus õpitule, mis annab selge ülevaate selle ülesehitusest ja võimaluse mooduleid tulevikus mujal lahendustes kasutusele võtta. Eraldatud on mudelid, andmekiht, repositooriumid, transpordimudelid, transpordiloogika ja teenus. Veebiteenuses on kasutusel 7 olemit, andmebaas on loodud “code first” põhimõttel kasutades ‘entity framework”-i. Repositooriumid on jaotatud eraldi failidesse, erimeetodeid üheski kasutatud ei ole. Transpordiloogika on piisaval määral kommenteeritud – üheselt mõistetavalt on aru saada, mida iga meetod teeb. Veebiteenus on loodud .NET 4.5 raamistikus, autentimine on implementeeritud, kuigi testimisel ei töötanud (võib-olla andmebaasi seadistamise viga). Andmed tagastatakse json kujul (korralikult joondatud). Veebiteenuse api lehekülg on osaliselt kommenteeritud, kuigi võiks olla põhjalikumalt, et teenuse kasutajatele oleks kasutamine lihtsam. Leida ei õnnestunud statistika osa, paistab, et see on jäänud versioon 2-e. Idee on ärilise poole pealt hea, Eesti turg jääb väikseks, aga suurema rahvaarvuga keskmise arenguga riigis annaks seda ehk kasumlikult turustada. Kood ise on korralikult joondatud ja enamjaolt kommenteeritud, kasutatud on kursuse käigus õpitud mustreid – see kõik teeb koodi lugemise ja ülesehituse lihtsaks ja arusaadavaks. Soovitaks pohjalikumalt API dokumentatsiooni kommenteerida.

Klientrakendus:

TÜC tegi klientrakendusi kaks Web.API MVC vaated ning WPF rakenduse, mis tundus veidi poolik ja vähem tähelepanu saanud, kui Web.Api, mille vaated teenuselt infot pärivad. Kirjeldades neid kahte erinevat klientrakendust, siis Web.Api MVC vaadete puhul on võimalik nii sisselogitud kui ka mittelogitud kasutajaga lehelt infot pärida. Web.API projektis lisab kontoga kasutajale võimaluse ka ise kuulutusi lisada, kustutada ning muuta. WPF projekt on sarnane, kuid lisandväärtusena on kalender.

Kood on kirjutatud klientrakendustele järgides häid arendusmustreid ning ka arusaadavalt. Olulist rõhku on pandud ka vaadete - vaatemudelite kui ka controllerite eraldamisele ning nende loogika loomisele. Kood on kommenteeritud, et hõlbustada koodi arusaadavust ning meetodite tööpõhimõtet täpsustada.

Kontrollides päringuid, toimuvad need korrapäraselt ning üksi REST-päring ei ebaõnnestu.

Klientrakenduse kontrollerite loogika on lahendatud läbi ühe baaskontrolleri, millest infot päritakse. Enim funktsionaalsust kannab endas kuulutuse ( AdvertController ) kontroller, milles on actionid ning igaleühele neist on olemas ka vaade, mis on tugevalt tüübitud.

Põhifunktsionaalsus toimib ning võib öelda, et käesolev klientrakendus on loodud ning teostatud nõutud tasemel, olles eeskujulik nii koodi kui ka arendusmustri poolest.

Teenuse ja klientrakenduse retsensioon meeskonna "Kirves" poolt

Teenus:

Meeskond TÜC on loonud RESTFUL teenuse Web API 2.0 platvormile. Projektis on kasutatud erinevaid arendus mustreid, mis annab hea loetavuse ja struktuuri koodi poolelt.

Kasutatud on järgnevaid mustreid eraldi projektides:

• DAL – Data access layer
• Models – Code first lähenemisega loodud andmebaas
• Repositories – EF jaoks loodud tühjad konstruktorid
• Transport logic
• Transport models

DAL

Data access layeri alla on toodud ilusti kõik andmebaasi mudelid, olemas on DB name ning ära on siis kasutatud migratsioone. Migratsioone on küllaltki raske saada viisakalt tööle, seega on positiivne näha, et meeskond on sellega vaeva näinud.

Models

Projekti andmebaas on loodud code first lähenemisega, mis annab paindlikuse projekti arendamisele. Andmebaasi mudelites on loodud vajaminevad seosed. Kahjuks aga paraku jääb silma mõningad puudused. Tabeli olemitel on puudu stringi piirangud, ehk hetkel on kõik maksimaalsete väärtustega. Teiseks, mis jääb silma on topelt väärtustamine ForeignKey-le. Kui ma ei eksi kui tabelite vahel on korrektsed seosed siis selle väärtustamisega saab hakkama Entity Framework ise. Üldiselt aga on andmebaas korralik.

Repositories

Et projektis kaotada otsesed siduvused funktsionaalsete meetodiega on sisse toodud selline muster nagu repositories, mis võimaldab projekti edasi arengut teha paindlikumaks, et mitte kirjutada kõike oma projektist ümber vaid saab asju vahetada välja moodulitena. Väga positiivne lähenemine.

Transport logic

Transpordi loogika kihti on kirjutatud kogu funktsionaalsus, mida soovitakse saada andmebaasit ja edastada teenusena. Samuti ka selline lähenemine annab paindlikuse edasi arenguks. Mugav on ühest kohast muuta koodi või vahetada lihtsalt mingisugune loogika klass välja uuema vastu. Meeskond on väga edukalt selle kihi realiseerinud.

Transport models

Et transpordi loogika saaks toimida on vaja sellele kihile mudeleid. Antud hetkel on ilusti eraldi realiseeritud Class projekti transpordi mudelid, mida loogika kiht kasutab. Kasutatakse ka ära Factory loogikat. Eduakalt realiseeritud.

Web API 2.0

Meeskond kasutas oma teenuse loomiseks Web API 2 tehnoloogiat, mis on väga hea idee, kuna selle peale on selliseid teenuseid mugav luua. Teenus kasutab ilusti ära eelnevalt loodud kihte ja seda õiges järjekorras, ehk siis teenus töötab ilusti.

Teenusel on implementeeritud api endapoolne kasutajate autentimine. Teenus annab välja nõudmise peale tokeni, mida saab hiljem kasutada klientrakenduse poolel. Kontrollerid teenusel on ilusad ja puhtad. Puudub üleliigne sodi ja suurt loogika tööd neis ei tehta, mis on väga positiivne tava.

Teenuse infona antakse välja Jsoni, mis on väga hea, kuna seda on klientrakenduse poolel lihdne töödelda. Samuti võtab teenus vastu ka Jsoni. Kontrollerites on realiseeritud kõik põhi funktsioonid, Get, Post, Put ja delete. See annab paindliku lahenduse klientrakendustele. Üleüldiselt on meeskond TÜC teinud tublit tööd. Projektis olid olemas kõik vahekihid, mida me selle aineraames läbisime ning oli korralikult implementeeritud. Kogu funktsionaalsus teenuse poolt toimib ilusti ja seda on piisavalt. Edasine käik kuidas seda teenust kasutatakse ja mis mahus on juba klientrakenduse ülesanne ja kui mahukalt seda realiseeritakse.

Tooks ka välja, et kood on hästi kommenteeritud ning teenuse enda api dokumentatsiooni on veebis võimalik vaadata. Sealt leiab kiirelt, mis meetodid on olemas ning näha on ka koodi, mis neis kaustatud. See on suur boonus projekti läbiviimisel. Väga hea töö teenuse ehitusel. Tublid!

Klient:

Klientrakendusi on teostatud kaks, neist üks on teenusega samas projektis, teine teostatud eraldi WPF-rakendusena. Selles retsensioonis on keskendutud neist esimesele. Esmalt rääkides rakenduse disainist, peab tunnustama silmale üsna meeldiva kujunduse eest. See tundub baseeruvat juba Visual Studios olemasoleval template’i, kuid kõike ei peagi ise tegema ning valmislahendus võib kodukootud disainist tihti parem olla. Klientrakendust käivitades pakutakse avalehel võimalust vaadata olemasolevaid kuulutusi, sisse logida või registreeruda kasutajaks (trükiviga esilehe lingis :) Kõigepealt lähtungi kliendi retsenseerimisel pelgalt tavakasutajale kättesaadavast infost (black box testing).

Nii sisselogimise kui registreerumise lehel on kliendis kasutusel andmete valideerimine. Sama kehtib ka kuulutuste lisamise ja muutmise kohta. Paraku ei ole valideerimist näiteks selles osas, et sisestada ei saaks negatiivseid väärtuseid kohtade arvu või hinna lahtrisse. Juhul kui samale rakendusele lisada näiteks ka kohtade broneerimine ja maksmine, tuleks kasutada ka nende väärtuste täiendavat validatsiooni. On olemas ka töötav kuulutuste kustutamise funktsionaalsus (sisse loginud kasutajad saavad enda kuulutusi kustutada). Kui esimesel korral rakendust käivitada, võiks kohalikku baasi olla lisatud ka juba mingisugune asulate nimekiri. Hetkel ei ole näiteks võimalik kliendis lisada kohanimesid või aadresse. Valideerimisel on teatud puudujääke ka kuulutuste lisamisel. Näiteks lubatakse lisada kuulutust, kui valitud pole mitte ühtegi sihtkoha ega lähtepunkti nime, kuid selle kuulutuse muutmisel tuleb vastuseks stacktrace kuna sel hetkel kontrollitakse kuskil, et source- ja destinationID=null. Samuti kuvatakse taoliselt puuduva lähte-ja sihtkohaga lisatud kuulutusi valesti, puuduvad väljad jäetakse vahele ning neile järgnevad andmed nihutatakse ülespoole, andmeväljade nimetused ise vasakul pool jäävad aga paika, nii õnnestus kuvada kuulutus kujul “To 1.01.2015 0:00:00; Available seats 20”. Samuti on võimalik lisada kuulutust, millel on lähte-ja sihtkoht samad (seda muideks süsteem ka vaikimisi pakub). Samuti võiks hinnal olla märgitud ühikud. Positiivsena võiks märkida veel et kliendi kaudu on võimalik vaadata veebiteenuse (automaatselt genereeritud) dokumentatsiooni koos json formaadis päringute näidetega.

Kui vaadata loodud klienti koodi poole pealt, on kasutatud MVC5 raamistikku ning scaffoldingi, et tekitada vaated poolautomaatselt. Vaatekontrollerites on kasutatud HttpClienti’t ning asünkroonseid meetodeid, et suhelda eelnevalt loodud veebiteenusega. Samuti on kliendi poolel realiseeritud autentimiseks vajalik baasklass, mille vaatekontrollerid pärivad. Ehkki klient on realiseeritud samas projektis veebiteenusega, on kummalgi täiesti iseseisev koodibaas. Ka kliendi jaoks on eraldi realiseeritud vaatemudelid ning on kasutatud ka annotatsioone andmete paremaks kuvamiseks (näiteks Display(Name = "Label")). Nagu teenuse retsensioonis mainitud, toimub autentimine standardselt token’ i ning cookie baasil. Kliendi poole peal oleks kood võinud olla veidi paremini kommenteeritud, kuid ka siin ei ole erilist põhjust nurisemiseks.

Üldkokkuvõttes on meeskond teinud tublit tööd ning realiseerinud MVC5 raamistikul baseeruva ja töötava klientrakenduse, mis kasutab veebiteenusega suhtlemiseks ära autentimist. Rakendust saaks tunduvalt edasi arendada (selleks vajalikud endpoint’id on olemas ka veebiteenuses), esinevad puudused ei ole tõsised, nende kõrvaldamisel ja funktsionaalsuste lisamisel võiks tegu olla reaalselt kasutusel oleva teenusega.

Teenus:

API käivitamisel algul ei saanud aru, kas sai API või klient käivitatud, sest harjumuspärase web-api asemel oli tegemist millegi muuga. Igaljuhul oli avanenud teenuse vaade meeldivalt disainitud ning api dokumentatsioon kiirelt kättesaadav ja api meetodite väljundid olid json formaadis hästi vormistatud kujul. Projekt on viisakalt vormistatud eraldiseisvate kihtidena, mis on igati mõistlik, sest tulevaste muudatuste sisseviimine ja koodi mõistmine on kõvasti lihtsustatud. Kasutatud vahekihid on: data access layer, models, TransportLogic, TransportModels ja web-api. Kihtide vaheline suhtlus on mõistlik ja õiges järjekorras, kasutatud on ka baas klasse, mis aitab koodi korrapärasena hoida. Mudel on koostatud loogilisena, kõik vajalikud propertid on välja toodud. Kasutatud on ka laiska väärtustamist läbi virtualide ja navigeerimiseks on kasutatud liste teistest mudelitest. Andmebaasi mudelites on loodud vajaminevad seosed. Läbi mudelite andmebaasi andmete sisestamine on tehtud Code first lähenemisega, EntityFrameworki abiga, kasutades migratsioone ja repositooriume. Migratsioonide kasutamine on kaval ja aegasäästev, sest luuakse olemasolevast mudelist andmebaas. Transpordiloogika on kenasti dokumenteeritud ja igati loogiline, kõikide vajalike andmebaasi päringutega, mida on hea hiljem kontrollerites kasutada, siin peitub kogu teenuse loogika. Web-apis on loodud kõik vajalikud kontrollerid, milles on kõik vajalikud meetodid(get,put,post,delete), kõik meetodid on korralikult dokumenteeritud, ainult useri tegevustega seotud dokumentatsioon on puudu. Kontrollerid on eraldi loodud, mitte ei ole ühte nö peakontrollerit, see teeb koodi lugemise mugavaks. Kontrollerid on puhtad, ei sisalda äriloogikat. Crudi meetodite puhul pole väljundit, kui operatsioon ebaõnnestub, kuid eks läbi debugimise on ka võimalik vigu tuvastada, kuid veateadete kasutamine tundub mõistlikumana ja muudab kliendi poole pealt tegutsemise mugavamaks. Teenusest väljastatakse Json formaadis infot, mis on väga hea, sest seda on lihtne edaspidi kliendis kasutada. Üldiselt jäi igati positiivne mulje TÜC-i teenusest, sest kasutatud oli praktikumides läbi käidu ning peamised nõuded olid täidetud. Projekt on loogiliselt formuleeritud, klasside sisu on loogiline, ei sisalda mõttetuid andmeid. Suured pluss punktid api disainile ja projekti loogilisele ülesehitusele.

Klient:

Meeskond tegi kaks klientrakendust. Esimene neist on API sisse ehitatud, mis tundus esialgu kummaline ja teine on WPF klient. Kuna WPF on väga minimalistlik ning tundub ,et ei ole veel lõpuni tehtud, siis retsenseerime esimest.

Kui käivitasime selle rakenduse, siis kohe nägime ilusat disainitud lehte. See on kindlasti suureks plussiks kasutajatele, sest disain ja välimus on ka tähtis. On olemas võimalus sisse logida ning registreerida. Inimene, kes on juba registreerinud, saab kuulutusi lisada, kustutada või muuta neid. On olemas selline nupp „Sisene anonüümselt“, ehk lehe sisu ja andmeid saavad näha ka kasutajad, kellel veel pole kontot. Kood on selge ja arusaadav, sellepärast et on olemas hea dokumentatsioon. Kasutatud valideerimise võimalusi. Aga kuulutusi on võimalik lisada ka juhul, kui ei ole valitud sihtkohta ehk lahtrid on tühjad, seega ei saa aru mis mõte sellisel kuulutusel oleks. Koodi poole pealt on põhiline loogika view kontrollerites ja silma jääb väga palju stringi liitmisi aadresside juures, selle oleks saanud kindlasti paremini realiseerida, aga muu koha pealt ei ole mõtet nuriseda. Kindlasti peaks veel lõpuni viima WPF klientrakenduse ja lisada täisustusi põhirakendusele. Aga üldiselt on tehtud suur töö ja põhifunktsionaalsus on realiseeritud ning lisaks aega jäänud veel disaini peale mõtlemiseks. Tublid.

Teenuse ja kliendi retsensioon meeskonna "HashTag" poolt

Avades projekti Visual Studios on näha, et on tegemist hästi struktureeritud koodiga, kus on kasutusele võetud vajalikud kihid:data access layer andmebaasiga suhtlemiseks, models andmebaasimudelite jaoks, repositooriumid andmebaasi andmetega manipuleerimise meetoditega, transportmodels struktureeritud andmete lihtsakujuliseks edastamiseks, transportlogic repositooriumi mustri rakendamise tõstmiseks ühtsesse kihti. Veel on positiivne, et terves lahenduses on kindlalt paika pandud läbiv keel, milleks on loomulikult inglise keel, sest sellega on mõeldud suurema kasutajabaasi peale. Lisaks sellele, on lihtsam lugeda meetodeid, muutujaid mis on ühes keeles. Kolmandana peaks mainima, et Kyyt projektis on teenusepool ja klientrakendus ühes koos, kuid loetavuse mõttes on võimalik kaustanimesid jälgides siiski aru saada, kus mis asub.

Teenus:

Kui tehtusse süveneda, siis tuleb välja et teenusetüübiks on ASP.NET Web API. Teenuse funktsionaalsusest aimu saamiseks leidsin kontrollerite kaustast klassid, mis pärivad klassilt apiController. Nagu aimata, kuna nii on tavaks et apikontrolleri klassid pannakse kontroller kausta, nii ongi tehtud, mis on positiivne, sest ühte funktsiooni täitvad klassid on tsentraliseeritud kohas. Kuna apikontroller klassid on need mis kirjeldavad kuidas ja millega teenus vastab päringutele, siis nende järgi saab kohe ära näha kui hästi on lahendus läbi mõeldud ja kuidas loogika on jagatud. Kiiresti kontrolleriklasse läbi sirvides on selgesti arusaadav millele projekt rõhku paneb. Selleks on kuulutuste ja kasutajatega toimetamine. Tänu sellele on igati asjakohane hoida kontoga tegelevas accountcontrolleris ja kuulutustega tegelevas advertkontrolleris suuremamahulist koodi, mis pakub kitsamat valminud rakendusele suunatud päringutega toimetamist ja ülejäänud kontrollerites tavapärast CRUD-i. Seda seepärast, et nii muutub lahendus tunduvalt taaskasutatavamaks ja võimaldab tulevikus paremini kohanduda kasutajavajadustele kui midagi on vaja muuta. Et muutmine toimub ühes spetsiifilises kohas, mitte igal pool laiali. Peale konto ja kasutaja kontrollerite on mitu kontrollerit, mis tegelevad sisuliselt sama asjaga – CRUD-ga ehk küsivad ja muudavad parameetriga täpsustatud kirjeid andmebaasis ning tagastavad neid. Kohe hakkab silma see, et kuigi on kenasti kasutatud loogika vahekihti et operatsioone teha, siis tagastatakse alati DTO-sid kuigi parem variant on alati tagastada HttpResponseMessage’sid,sest see väldib kliendi pool tekkivat segadust et ükskord saadetakse responsemessage’sid, teinekord JSON-t jms. Peale selle on koodi välimus väga puhas, ilusti kommenteeritud, kuigi kui väga kõvasti norida, siis leidub meetodeid, mis pole kommenteeritud. Kui edasi liikuda advercontroller klassi juurde, mis tegeleb kuulutustega, siis on jälgitud mugavuse mõttes ühte head nippi, et on kasutatud routeprefix ja route atribuute, mis teevad kliendi poolel pärimise mugavamaks, sest saab kirjutada lihtsamaid pathe. Liikudes transpordimudelite juurde on omapärane lahendus duplikeerida DTO-dena kliendipoolseid vaatemudeleid, et ju siis neid on lihtsam teenusel kliendile edastada ja hiljem parse’da. TransportLogic kihis on tähelepanuväärne ja hea mustriga see kuidas kõik meetodid kasutavad repositooriumimeetodeid ja töötlevad tulemusi kohe ümber DTO-deks. Repositooriumide kihis on kasutatud ühte baasrepositooriumi ja siis iga mudeli jaoks vastavat repositooriumi mis baasrepost pärineb. See on küll palju väga sarnast koodi, kuid funktsionaalsuse poolest pole ka midagi valesti tehtud. Üldjoontes on teenus hästi vormistatud.

Klient:

Klientrakendust tööle pannes paistab silma puhas ja lihtne välimus ning kui koodi lähemalt uurida, siis selgub et kasutatakse bootstrapi, millega on lihtne kujunduse poolt lahendada. Kui aga veel mõelda disaini peale kasutaja poolt vaadatuna, siis kui kasutaja pidevalt seda rakendust kasutaks, siis muutuks see disain pisut ühekülgseks või ka ühetooniliseks ja pika peale peletaks kasutaja siiski eemale. Kui klientrakenduse juures lehe funktsionaalsust vaadata, siis jääb pisut arusaamatuks, kuskohast tulevad asukohad, sest kasutaja ei saa ilma asukohtadeta kuulutusi leida. Suurem osa lehtede vahel liikumist käib vaadete vahel läbi actionlinkide, mis tähendab et kui millegiga lehel toimetada, siis leht laetakse uuesti ehk tegemist ei ole dünaamilise veebilehega, kuid arvestades lehe eesmärki, siis see polegi vajalik. Vaadete kontrollerid on kenasti jaotatud, sest on loodud üks baaskontroller mis teeb get,post,update,login päringuid ja spetsiifilisemad kontrollerid kuulutuste, konto ja kommentaaride jaoks. Veidi imelik tundub see et millegipärast on kommentaaride kontrolleris kood välja kommenteeritud, et see võib olla kas kogemata unustatud või mingil testimise eesmärgil nii jäetud.Positiivne on aga, et teenuseaadresse hoitakse ühes klassis, kus neid on hea muutmas käia juhul kui teenus peaks muutuma. Registreerumise koha pealt pole kuigi palju tähelepanu pööratud millisel kujul peab kasutaja parool olema, et kui turvaline see on. Siiski jälgitakse seda et parool oleks 6 tähemärki pikk. Üldjoontes on klientrakendus lihtne ja loogiline ehk kasutatud on standardseid vorme ja kommentaaride abil on võimalik kasutajatel isegi üksteisega suhelda. Miinuse poole pealt koodi vaadates ei leidnud ma kasutajastatistikaga seonduvad ega ka märki mingisugusest administraatori tegelasest.