Talk:TÜC2 - Revision history

Jkangsep at 00:23, 17 June 2014

2014-06-17T00:23:53Z

← Older revision		Revision as of 03:23, 17 June 2014
Line 159:		Line 159:
	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.		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.		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.

Smaeots: /* Klient: */

2014-06-16T21:33:22Z

Klient:

← Older revision		Revision as of 00:33, 17 June 2014
Line 158:		Line 158:
	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.		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.		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.		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.

Smaeots at 21:23, 16 June 2014

2014-06-16T21:23:14Z

← Older revision		Revision as of 00:23, 17 June 2014
Line 151:		Line 151:
	Ü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.		Ü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:==

	~~==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.

Smaeots at 21:02, 16 June 2014

2014-06-16T21:02:18Z

← Older revision		Revision as of 00:02, 17 June 2014
Line 150:		Line 150:
	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.		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.		Ü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:==

Smaeots: /* Teenus: */

2014-06-16T19:34:11Z

Teenus:

← Older revision		Revision as of 22:34, 16 June 2014
Line 148:		Line 148:
	==Teenus:==		==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.		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 ~~eraldi seisvate~~ 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 ~~olemas olevast~~ mudelist andmebaas. ~~Transpordi loogika~~ 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 ~~üht~~ 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 ~~cliendi~~ poole pealt ~~mugavam tegutseda~~. Teenusest ~~väljastatkse~~ Json formaadis infot, mis on väga hea, sest seda on ~~llihtne~~ edaspidi kliendis kasutada.		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õtetuid~~ andmeid. Suured pluss punktid api disainile ja projekti loogilisele ülesehitusele.		Ü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.

Smaeots at 19:23, 16 June 2014

2014-06-16T19:23:19Z

← Older revision		Revision as of 22:23, 16 June 2014
Line 142:		Line 142:

	Ü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.		Ü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.


			==Teenuse ja kliendi retsensioonid meeskonna "Pöial" poolt==

			==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 eraldi seisvate 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 olemas olevast mudelist andmebaas. Transpordi loogika 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 üht 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 cliendi poole pealt mugavam tegutseda. Teenusest väljastatkse Json formaadis infot, mis on väga hea, sest seda on llihtne 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õtetuid andmeid. Suured pluss punktid api disainile ja projekti loogilisele ülesehitusele.

Poras: /* Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt */

2014-06-05T13:00:58Z

Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt

← Older revision		Revision as of 16:00, 5 June 2014
Line 77:		Line 77:
	Klientrakendus:		Klientrakendus:

	TÜC tegi klientrakendusi kaks Web.API ning WPF rakenduse, mis tundus veidi poolik ja vähem tähelepanu saanud, kui Web.Api, mille vaated teenuselt infot pärivad.		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 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.		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.		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.

Aluuri at 18:09, 31 May 2014

2014-05-31T18:09:23Z

← Older revision		Revision as of 21:09, 31 May 2014
Line 87:		Line 87:

	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.		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.

Poras: /* Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt */

2014-05-31T16:56:35Z

Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt

@@ Line 66: / Line 66: @@
 ==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.
@@ Line 74: / Line 74: @@
 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.

Rmaripuu at 13:01, 31 May 2014

2014-05-31T13:01:28Z

← Older revision		Revision as of 16:01, 31 May 2014
Line 63:		Line 63:

	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.		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==

			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.