Talk:Bomory

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