Talk:Poial: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Akalev (talk | contribs)
No edit summary
Kkruus (talk | contribs)
 
Line 28: Line 28:


Kokkuvõttes võib jääda tehtud tööga rahule, aga mõningaid asju saaks kindlalt teha paremini.
Kokkuvõttes võib jääda tehtud tööga rahule, aga mõningaid asju saaks kindlalt teha paremini.
== Teenuse ja klientrakenduse retsensioon Meeskonna "Ostunimekiri"("MeilEiOleGrupinime" alam-meeskond)  poolt ==
== Teenuse retsensioon ==
Meeskond Pöial on loonud WPF-rakenduse nimega "Plaadipood", mis võimaldab kasutajal osta erinevate artistide muusikat. Veebiteenusena on kasutatatud ASP.NET Web.API teenust.
Kohe pärast projekti avamist on näha, et rakendus koosneb kahest projektist, mistõttu peab olema avatud kaks Visual Studio akent. Jääb selgusetuks, miks ei loodud WPF klientrakendust samas projektis vaid otstustati kahe erineva projekti kasuks.
Kasutatud on code-first lähenemist ning on loodud Entity Framework'i tarvis andmemudelid. Andmemuselid on kokku kuus, mis oli ka nõuetes olev minimaalne tabelite arv. Mudelite puhul on kasutatud annotatsioone, kuid seda vaid mõnede mudelite puhul, osades puuduvad need täiesti. Samuti ei ole piiratud sõnepikkusi, mistõttu on võimalik sisestada baasi lõpmatu pikkusega kirjeid. Kahju, et pole kasutatud ASP.NET IdentityUserit ning on loodud enda tabel kasutajad, mis ei taga kasutaja andmetele sarnast turvalisust. On kahte tüüpi kasutajad, tavakasutaja ning admin, neid eristatakse tabelis „User“ oleva boolean väljaga. Lähemal vaatlusel selgub, et baas koosneb kahest eraldiseisvast osast, mida pole omavahel kokku viidud. Kirjesse on võimalik sisestada albumeid ja artiste,keda baasis ei eksisteerigi.Tabelite "Order" ja "Cart", mis tähistavad ostukorvi ja tellimust, puhul tuleb plaadialbumi nimetus ning laulja sisestada käsitsi, mis tähendab, et andmebaasi loogika on valesti koostatud. Seda on võimalik parandada, kui nõuab teenuse poole peal liigselt sekkumist ning tekitab liiga palju peavalu ning segadust.
Andmebaasi Contexti loomiseks on loodud eraldi class-library PlaadiPood.DAL, mis muudab selle osa hallatavamaks. Kasutatud on repositooriume ning transpordimudeleid ja -loogikat. Repositooriumites on lisatud EFRepository klassi uus meetod UpdateOldToNew, mis uuendab tabeli väärtuseid. Meetodi puhul tekitab küsimusi, miks pole kasutatud klassis olemasolevat Update-meetodit, mis uuendab valitud kirjes kõik muutunud väljad etteantud objekti alusel, vaid on loodud uus meetod, mis võtab sisendisse kaks objekti, mis tähistavad uut ja vana kirjet. Loodud transpordimudelid on asjakohased ning väljastavad piisava koguse infot, seotud tabelite puhul kasutatakse samuti transpordimudeleid, mis tähendab, et ka nende puhul ei väljastata liigselt infot, mis muudaks teenuse aeglasemaks. Kasutatatud on ka ModelFactory’t, millega luuakse kõik vastavad transpordimudelid etteantud andmemudelite põhjal. Transpordiloogika on samuti päris hästi tehtud, mõnes kohas võib märgata kasutamata jäänud koodi ning tühje meetodeid. Web.API poolel on kontrollerites kasutatud veahaldust ning vea korral väljastatakse vastav teade ning antakse tagasi vastav veakood. Meetodite päistes on olemas annotatsioonid, millise CRUD-meetodiga on antud hetkel tegu. On näha, et on üritatud luua BaseApiControllerit,  kuid on sellest hiljem sellest loobutud, seal leidub ainult üks meetod, mis tagastab Albumrepo, teised väljad on välja kommenteeritud. Suuremaks miinuseks on liigne LINQ kasutamine kontrollerites, paljudes kohtades on koodiosi, mida oleks võinud realiseerida transpordiloogika poole peal. Praegusel juhul muutub koodi haldamine keeruliseks ning tekitab segadust. Administraatori ja tavakasutaja sisselogimisel saadetakse teele erinevad tagastuskoodid, samas kui kliendi poolel oleks võimalik lihtsalt võrrelda vastavat boolean välja.
Kokkuvõtvalt võib öelda, et teenuse repositooriumite ning tranpordimudelite ja -loogikaga tegelev osa on koostatud üldiselt hästi ning tegu on suhteliselt puhta koodiga. WEB.API tagastab vea korral vastava veakoodi ning veateate. Samas on kontrollerites kasutatud liigselt koodi, mis peaks asuma transpordiloogika kihis. Suurim miinus on andmebaasi loogikas esinev suur viga eraldiseisvate tabelite näol, mis tähendab et teenus on pikemas perspektiivis kasutuskõlbmatu ning nõuab parandamist.
== Klientrakenduse retsensioon ==
Klientrakendusena on realiseeritud WPF-rakendus, mis suhtleb eraldi projektis oleva teenusega. Rakendus ei võimalda uusi albumeid ja artiste lisada, selle jaoks on loodud konsoolirakendus, millega on võimalik andmebaasi tabelid täita. Sisuliselt võrdub see andmebaasi käsitsi täitmisega.
Rakenduse käivitamisel avatakse süsimust aken mille keskel asub pisike sisselogimisvorm. Registeerimisnupu vajutamisel tekib vormi alla uus vorm ning sisselogimispaneel muutub ebaaktiivseks. Andmete sisestamisel on olemas teatud validatsioon, kuid see asub vaate xaml.cs failis ning on koostatud suure else if plokkide jadana. Samas ei kontrollita kõiki juhtumeid, näiteks kui kasutajanimi ja parool on kolm tühikut. Sisselogimisel on näha kolm erineva paigutusega kasti, millest vasakpoolsemas kuvatakse albumite žanrid,mis tuleb käsitsi baasi sisestada. Käsitsi tuleb sisestada nii žanrid, albumid kui ka lauljad, mis on küllaltki tüliks, isegi testimise puhul.
Listist žanri valimisel ei uuendata sellega seotud albumite tabelit kohe, vaid tuleb vajutada pisikest nuppu „Show“, mida ei pruugi esimesel kasutamisel kohe ära tabada. Leidub ka kast, mis on ilmselt mõeldud albumite seas otsingu sooritamiseks, kuid millel funktsionaalsus puudub, ainult kustutatakse kõik listis olevad albumid. Albumile klikates kuvatakse paremal albumiga seotud info ning on võimalik lisada seda enda ostukorvi. Samas lisamisel ostukorvi ühtegi toodet ei lisandu, mistõttu ei ole võimalik tooteid ei osta ega ostukorvist eemaldada, listi värskendatakse ning tagasitulev list on tühi. Samuti ei õnnestunud logida sisse kirjelduses toodud admini konto kasutajanime ja parooliga, mistõttu ei olnud võimalik vaadata üle admini poole funktsionaalsust.
Koodi poole pealt on teenusega ühildumine tehtud väga hästi, kasutatakse BaseService klassi, mis muudab päringute tegemise lihtsamaks. Teenuse aadressid on toodud Constants klassis, kus on võimalik neid kiiresti muuta. Samas on toodud teenuse poole pealt kaasa andmemudelid, mis on tingitud projekti kaheks jagamisest, kui oleks loodud kogu projekt ühes lahenduses, oleks olnud võimalik luua viide teenuse andmemudelitele ning kasutada neid. Vaatemudelid on samuti korralikud ja tegu on puhta koodiga, samuti on kasutatud regioone paremaks halduseks. Vaates olev kood on samas kehvema kvaliteediga, palju asju toimub otse vaates, suure osa neist oleks võimalik lahendada bindingute abil vaatemudelites. Paneelide nähtavust, värvust ja aktiivsust/ebaaktiivust muudetakse vaates pikkade jadadena, kus seatske  suurele hulgale UIElementide vastavaid väärtuseid. Selle asemel oleks võinud ning luua konverteri, mis implementeerib IValueConverter liidest ning on bindingu abil seotud vaatemudelis defineeritud väärtusega. Kujundusele ja kasutusmugavusele pole eriti rõhku pööratud, testimisel tekkisid sellega seose mõningad probleemid, sest ma ei teadnud, et listist elemendi valimisel tuleb vajutada nuppu, et vastava žanri albumeid vaadata. Selle oleks võinud lahendada SelectionChanged event’ga.
Klientrakenduse üldmulje ei ole kõige parem, vaates on kasutatud palju ebavajalikku koodi ning mitmed funktsionaalsused ei tööta. Kasutusmugavus ja kujundus on samuti kehv, see tekitas probleeme ka testimise ajal. Samas on koodi poolel teenusega ühildumise ja vaatemudelite klassid hästi tehtud ning tegu on puhta ja arusaadava koodiga.

Latest revision as of 10:28, 17 June 2014

XML retsensioon meeskonna "Hashtag" poolt

Tiim Pöial lõi XMLi teemal e-riietepood.XML pole kuigi mahukas,sisaldades näiteks vähem näiteandmeid kui on riieteliikides näha on, kuid loomulikult saab sinna vajadusel hiljem lisainfot lisada, sest veebipoed ei pea alati kõiki riideliike müüma ühel hetkel.

XML andmefaili struktuur on väga konkreetne ja hästi ära jagatud neljaks lihtsasti loetavaks sektsiooniks: poe kohta käiv info,kategooriad,liigid,tooted.

Veebipoe kontaktides on väike viga, nimelt telefoni tüübi all on emaili info ja emaili lahtris telefon.

Xml-i kohta käivad nõuded on täidetud: olemas on 4 loogilist dimensiooni ja 5-l elemendil on ka kasutatud muid elemente kui id.

Veel üks positiivne punkt XML-s on et tooted on liikide järgi ära jaotatud, mis teeb XSL-s toodete lahterdamise ja otsimise mugavamaks.Liikide nimekiri on eraldi välja toodud ning iga toote elemendi juures on atribuut Liik.

XML skeemifailis on tähele panna, et toote element hind on arv, kuid see on piiritletud andmetüübiga xs:unsignedByte, mis võimaldab hinda sisestada numbreid 0-st 255-ni. See võib aga tekitada hiljem probleeme kui tahetakse müüa kallimat toodet kui 255 vastavat valuutat. Sama asja võib näha toote koguse juures,mis võib samamoodi tekitada probleeme kui tahetakse müüa suuremaid koguseid.

Transformatsioonifail kujutab XML-s olevaid tooteid veebipoena. Tooted käiakse tsükliga läbi ja jagatakse ID järgi, kuvatakse toote nimi,järjest tulevad atribuudid nendes oleva infoga, toote pilt ja tabelina kirjeldus, hind ja suurus. Tähelepanekuna võib ära tuua et kõik kuvatud eestikeelseid täpitähti sisaldavate nimede täpitähed kuvatakse HTML-s küsimärkidena.

Üldiselt on meeskond oma ülesandega toime tulnud, kuigi XML on küllaltki minimaalne, esinevad mõned vead ning loodud on vaid 1 tranformatsioon,kuigi soovitatud oli paar kolm transformatsiooni andmete nii HTML kui ka XML kujul kuvamiseks.

XML retsensioon meeskonna "AM" poolt

Meeskonna "Pöial" XML fail on tehtud riiete veebipoe näitel, kus on informatsiooni toodete kohta. Veebipoes peab kindlasti olema kategooriad (näiteks särgid, püksid jne), mis on ilusti ka olemas. Samas on ära jaotatud, kas toode on mõeldud naistele või meestele.

XML fail on nõuete kohaselt loodud, sest pidi olema 4 loogilist dimensiooni, 3-el dimensioonil attribuute, mis on enamat kui ID. Mõningad kohad vajavad kindlasti muutmist või parandamist. Näiteks veebipoe kontakt telefon on riided@mail.ee ja e-maili aadress on 55544422. Toodete kohta võib välja tuua suuruse, sest jäi arusaamatuks, kas suurus on Euroopa standardi järgi või hoopis Hiina standardi järgi.

XSD failist saab välja tuua kohad, kus on numbri väärtuse juures kasutatud string tüüpi. Näiteks koguse attribuuti juures on kasutatud unsignedByte, mille vahemik on 0 kuni 255. Mis juhtub siis, kui üks päev kogus tõuseb üle 255?

XSLT faile pidi olema paar kolm, aga leidus ainult 1. XSLT transformatsiooni fail on loodud korrektselt, kuigi mõnes kohas tekst ja mõningad elemendid (näiteks nupp) on äärejoonega liiga külg-külje vastas, mis muudab loetavuse või leidmise raskemaks.

Kokkuvõttes võib jääda tehtud tööga rahule, aga mõningaid asju saaks kindlalt teha paremini.

Teenuse ja klientrakenduse retsensioon Meeskonna "Ostunimekiri"("MeilEiOleGrupinime" alam-meeskond) poolt

Teenuse retsensioon

Meeskond Pöial on loonud WPF-rakenduse nimega "Plaadipood", mis võimaldab kasutajal osta erinevate artistide muusikat. Veebiteenusena on kasutatatud ASP.NET Web.API teenust. Kohe pärast projekti avamist on näha, et rakendus koosneb kahest projektist, mistõttu peab olema avatud kaks Visual Studio akent. Jääb selgusetuks, miks ei loodud WPF klientrakendust samas projektis vaid otstustati kahe erineva projekti kasuks. Kasutatud on code-first lähenemist ning on loodud Entity Framework'i tarvis andmemudelid. Andmemuselid on kokku kuus, mis oli ka nõuetes olev minimaalne tabelite arv. Mudelite puhul on kasutatud annotatsioone, kuid seda vaid mõnede mudelite puhul, osades puuduvad need täiesti. Samuti ei ole piiratud sõnepikkusi, mistõttu on võimalik sisestada baasi lõpmatu pikkusega kirjeid. Kahju, et pole kasutatud ASP.NET IdentityUserit ning on loodud enda tabel kasutajad, mis ei taga kasutaja andmetele sarnast turvalisust. On kahte tüüpi kasutajad, tavakasutaja ning admin, neid eristatakse tabelis „User“ oleva boolean väljaga. Lähemal vaatlusel selgub, et baas koosneb kahest eraldiseisvast osast, mida pole omavahel kokku viidud. Kirjesse on võimalik sisestada albumeid ja artiste,keda baasis ei eksisteerigi.Tabelite "Order" ja "Cart", mis tähistavad ostukorvi ja tellimust, puhul tuleb plaadialbumi nimetus ning laulja sisestada käsitsi, mis tähendab, et andmebaasi loogika on valesti koostatud. Seda on võimalik parandada, kui nõuab teenuse poole peal liigselt sekkumist ning tekitab liiga palju peavalu ning segadust. Andmebaasi Contexti loomiseks on loodud eraldi class-library PlaadiPood.DAL, mis muudab selle osa hallatavamaks. Kasutatud on repositooriume ning transpordimudeleid ja -loogikat. Repositooriumites on lisatud EFRepository klassi uus meetod UpdateOldToNew, mis uuendab tabeli väärtuseid. Meetodi puhul tekitab küsimusi, miks pole kasutatud klassis olemasolevat Update-meetodit, mis uuendab valitud kirjes kõik muutunud väljad etteantud objekti alusel, vaid on loodud uus meetod, mis võtab sisendisse kaks objekti, mis tähistavad uut ja vana kirjet. Loodud transpordimudelid on asjakohased ning väljastavad piisava koguse infot, seotud tabelite puhul kasutatakse samuti transpordimudeleid, mis tähendab, et ka nende puhul ei väljastata liigselt infot, mis muudaks teenuse aeglasemaks. Kasutatatud on ka ModelFactory’t, millega luuakse kõik vastavad transpordimudelid etteantud andmemudelite põhjal. Transpordiloogika on samuti päris hästi tehtud, mõnes kohas võib märgata kasutamata jäänud koodi ning tühje meetodeid. Web.API poolel on kontrollerites kasutatud veahaldust ning vea korral väljastatakse vastav teade ning antakse tagasi vastav veakood. Meetodite päistes on olemas annotatsioonid, millise CRUD-meetodiga on antud hetkel tegu. On näha, et on üritatud luua BaseApiControllerit, kuid on sellest hiljem sellest loobutud, seal leidub ainult üks meetod, mis tagastab Albumrepo, teised väljad on välja kommenteeritud. Suuremaks miinuseks on liigne LINQ kasutamine kontrollerites, paljudes kohtades on koodiosi, mida oleks võinud realiseerida transpordiloogika poole peal. Praegusel juhul muutub koodi haldamine keeruliseks ning tekitab segadust. Administraatori ja tavakasutaja sisselogimisel saadetakse teele erinevad tagastuskoodid, samas kui kliendi poolel oleks võimalik lihtsalt võrrelda vastavat boolean välja. Kokkuvõtvalt võib öelda, et teenuse repositooriumite ning tranpordimudelite ja -loogikaga tegelev osa on koostatud üldiselt hästi ning tegu on suhteliselt puhta koodiga. WEB.API tagastab vea korral vastava veakoodi ning veateate. Samas on kontrollerites kasutatud liigselt koodi, mis peaks asuma transpordiloogika kihis. Suurim miinus on andmebaasi loogikas esinev suur viga eraldiseisvate tabelite näol, mis tähendab et teenus on pikemas perspektiivis kasutuskõlbmatu ning nõuab parandamist.

Klientrakenduse retsensioon

Klientrakendusena on realiseeritud WPF-rakendus, mis suhtleb eraldi projektis oleva teenusega. Rakendus ei võimalda uusi albumeid ja artiste lisada, selle jaoks on loodud konsoolirakendus, millega on võimalik andmebaasi tabelid täita. Sisuliselt võrdub see andmebaasi käsitsi täitmisega. Rakenduse käivitamisel avatakse süsimust aken mille keskel asub pisike sisselogimisvorm. Registeerimisnupu vajutamisel tekib vormi alla uus vorm ning sisselogimispaneel muutub ebaaktiivseks. Andmete sisestamisel on olemas teatud validatsioon, kuid see asub vaate xaml.cs failis ning on koostatud suure else if plokkide jadana. Samas ei kontrollita kõiki juhtumeid, näiteks kui kasutajanimi ja parool on kolm tühikut. Sisselogimisel on näha kolm erineva paigutusega kasti, millest vasakpoolsemas kuvatakse albumite žanrid,mis tuleb käsitsi baasi sisestada. Käsitsi tuleb sisestada nii žanrid, albumid kui ka lauljad, mis on küllaltki tüliks, isegi testimise puhul. Listist žanri valimisel ei uuendata sellega seotud albumite tabelit kohe, vaid tuleb vajutada pisikest nuppu „Show“, mida ei pruugi esimesel kasutamisel kohe ära tabada. Leidub ka kast, mis on ilmselt mõeldud albumite seas otsingu sooritamiseks, kuid millel funktsionaalsus puudub, ainult kustutatakse kõik listis olevad albumid. Albumile klikates kuvatakse paremal albumiga seotud info ning on võimalik lisada seda enda ostukorvi. Samas lisamisel ostukorvi ühtegi toodet ei lisandu, mistõttu ei ole võimalik tooteid ei osta ega ostukorvist eemaldada, listi värskendatakse ning tagasitulev list on tühi. Samuti ei õnnestunud logida sisse kirjelduses toodud admini konto kasutajanime ja parooliga, mistõttu ei olnud võimalik vaadata üle admini poole funktsionaalsust. Koodi poole pealt on teenusega ühildumine tehtud väga hästi, kasutatakse BaseService klassi, mis muudab päringute tegemise lihtsamaks. Teenuse aadressid on toodud Constants klassis, kus on võimalik neid kiiresti muuta. Samas on toodud teenuse poole pealt kaasa andmemudelid, mis on tingitud projekti kaheks jagamisest, kui oleks loodud kogu projekt ühes lahenduses, oleks olnud võimalik luua viide teenuse andmemudelitele ning kasutada neid. Vaatemudelid on samuti korralikud ja tegu on puhta koodiga, samuti on kasutatud regioone paremaks halduseks. Vaates olev kood on samas kehvema kvaliteediga, palju asju toimub otse vaates, suure osa neist oleks võimalik lahendada bindingute abil vaatemudelites. Paneelide nähtavust, värvust ja aktiivsust/ebaaktiivust muudetakse vaates pikkade jadadena, kus seatske suurele hulgale UIElementide vastavaid väärtuseid. Selle asemel oleks võinud ning luua konverteri, mis implementeerib IValueConverter liidest ning on bindingu abil seotud vaatemudelis defineeritud väärtusega. Kujundusele ja kasutusmugavusele pole eriti rõhku pööratud, testimisel tekkisid sellega seose mõningad probleemid, sest ma ei teadnud, et listist elemendi valimisel tuleb vajutada nuppu, et vastava žanri albumeid vaadata. Selle oleks võinud lahendada SelectionChanged event’ga. Klientrakenduse üldmulje ei ole kõige parem, vaates on kasutatud palju ebavajalikku koodi ning mitmed funktsionaalsused ei tööta. Kasutusmugavus ja kujundus on samuti kehv, see tekitas probleeme ka testimise ajal. Samas on koodi poolel teenusega ühildumise ja vaatemudelite klassid hästi tehtud ning tegu on puhta ja arusaadava koodiga.