Talk:Bomory

From ICO wiki
Jump to navigationJump to search

Analüüsi retsensioon

Retsenseeris meeskond Kodune Raamatukogu.


Rakendust planeerides on mõeldud läbi väga paljud rakenduse kasutusvõimalused. Samas jääb lugedes veel arusaamatuks, kuidas plaanitakse funktsionaalsused rakenduse lehekülgedele jaotada ning kui palju erinevaid lehekülgi plaanitakse teha. Funktsionaalsusi on küllaltki palju ning mitmed neist on dubleeritud, kuna raamatute ja filmide kuvamiseks/lisamiseks on eraldi vaated. Väga meeldis mulle mõte võimaluse korral kasutada ära GoodReadsi ja IMDB APIsid ning oli positiivne, et oldi end kurssi viidud GoodReadsi kodulehel kuvatava info kasutamise nõuetega.


Andmebaasi annaks optimeerida ning tabelite arvu vähendada. Kuna tabelid Book ja Movie on peaaegu identsed, saaks need iseenesest kokku panna, lisades sinna ühe rea määramaks, kas tegu on raamatu või filmiga. See võimaldaks liita kokku ka omamisseose tabelid (UsersMovie ja UsersBook).


UsersBorrow tabel võiks välisvõtmete kaudu siduda omavahel tabelid User ja Book või User ja Movie, mida oleks jällegi veel lihtsam teostada, kui Book ja Movie oleksid koondatud samasse tabelisse. Hetkel UsersBorrow tabel suures osas dubleerib tabelite Book ja Movie andmeid. Samuti jääb UsersBorrow tabeli juures arusaamatuks, miks on kasutatud laenamisseoses kolme välja: BorrowedTo, BorrowedFrom ning UserId – tundub, et piisaks kahest (isiku Id, kes eset omab ning isiku Id, kes eseme laenutas).


Kokkuvõttes tundub rakendus väga ambitsioonikas paljude funktsionaalsuste kasutamise tõttu, mida on kindlasti lihtsam ellu viia, kui mõelda enne tegemist põhjalikult läbi kõik erinevad vaated ning millised funktsionaalsused saab panna samale leheküljele.


31.01.17

Lõpptoote retsensioon

Retsenseeris meeskond Kassarakendus.


Rakenduse kasutamise esmamulje

Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud. Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.


Koodi head omadused

Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik. Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.


Koodi puudused

Koodikirjutamise stiil on kohati ebaühtlane. Mõndades klassides kirjutati property-d nagu eelmises peatükkis kirjeldatud, teistes mitte. See muudab bindingute lugemise segasemaks. Kohati jäi mulje, et vaatemudelites on property-d või olemimuutujaid liiga palju. Bindimiseks saab kasutada ka ainult ühte objekti. Näiteks bindides kasutada property Title asmele Movie.Title. Vaadete elementide samad omadused on igas elemendis eraldi välja kirjutatud. Stiile oleks võinud grupeerida kas App.xaml failis või sama vaate PageResources elemendis. Elementide omadused oleks võinud kirjutada üksteise alla, mis oleks parandanud koodi loetavust. Tihti kastutakse meetodi parameetrina mingi objekti ID-d, selle asemel, et kasutada objekti ennast. Sellisel juhul jääks meetodis võimalus kasutada ka objekti teisi omadusi. Samuti on töös kasutatud segamini äriobjekte kui domeeniobjekte. Presentatsioonikihis võiks piirduda äriobjektidega, mis tähendab, et vajaduse korral peab ärikihis muutma domeeniobjektid äriobjektideks või vastupidi. Äriobjektides ja üksikutes teistes koodiosades kohtab põhjendamatut muutuja tüübi hardcode-mist, mis on arvatavasti seotud sellega, et andmebaasis lubatakse tühjasid väärtusid. Selline lähenemine pole väga hea stiil. Samuti on C#-s andmetüüpide kontrollimiseks paremad meetodid kui tavaline Try-Catch. Ei ole kasutatud erinevaid Try-Parse meetodeid. Enamustes äriteenuste meetodites, kus tagastatakse List, on ära unustatud LINQ meetod ToList(), mille asemel on kasutatud listi täitmiseks for-tsüklit. Samuti esineb töös mõttetut listide vahelist andmete ümber ladumist (listi andmete lisamine uude tühja listi). Andmeid eemaldatakse andmebaasi tabelitest Remove() meetodiga. Selles töös ei osutu see probleemiks, kuid andmete täieliku eelmaldamisel võib andmebaasis olevate seoste tõttu tekkida konflikt. Nii andmebaasis kui ka üleüldiselt oleks võinud filme ja raamatuid vaadata sama tüüpi objektidena. Kõik võiks olla ühes andmebaasitabelis.


Kokkuvõte

Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.


25.01.2016